Dreamer not setting bed height correctly?

[G7KXZ]

Hi,
Great bit of code and chocolate was about to be sent but ;(
All working very well if I first print directly from Simplyfy3d directly via usb then swap usb lead to raspi and print via optoprint.

However if I start a fresh sending the G-code from Simplyfy3d to Octoprint the bed is at the wrong height. This is repeatable each time.

I am guessing that the initial setup information is not being sent or maybe incorrect?

Many thanks
Charlie

[Mrnt]

However if I start a fresh sending the G-code from Simplyfy3d to Octoprint the bed is at the wrong height.

Is that after turning the printer on or something else? Does it seem like it is not homing when printing via Ocotprint?

2. Are you testing by printing the exact same thing directly from Simplify3D and then sending the file to OctoPrint? If you could upload the file (or a sample file that exhibits the behavior) then that might be helpful.

3. I am not familiar with Simplify3D - is it possible that when you print directly from Simplify3D it sends some initialization g-code (home, etc) to the printer before sending the file but when you send the file to OctoPrint then the initialization is not happening?

4. When you send to OctoPrint are you sending it to the Printer SD card via OctoPrint or are you sending it to be printed directly from OctoPrint?

5. What printer are you using?

[Colboto]

I'm not the OP, but I'm also running into an issue with this. Controlling the printer works perfectly, but the Z axis has to be inverted in the profile. Printing directly from Octoprint to the printer works, it does land at the right spot on the Z axis for literally a second, then the Z "disengages" and it falls as the print starts.

Video of it happening

My files are generated using FlashPrint using the left extruder. I've attached my test .gx file. This works if I print it directly from the SD card of the printer, or if I submit it through FlashPrint via WiFi.

acrylic.zip

[KeltE]

Did you print "upload to SD card" via octoprint? Printing directly from octoprint at least on my Dreamer Nx doesn't work well.

[Colboto]

I just tested "upload to SD card" and it does in fact work perfectly using it that way. It seems that this issue only occurs with the "Load and Print" button.

[KeltE]

Yes. On my printer, the connection is lost when I start working with the "Load and Print" button, and probably the first lines that are loaded into memory are working. I also discovered that once printing has taken place, you can immediately start the job again by pressing the "print" button. Only that the nozzle is no longer waiting for the table to warm up. And the Octop connection to the printer must not be lost in the meantime. And I have reprinted the Gcodes inside Octop with the "File Manager" plugin and the "upload to Sd card" button.

[Mrnt]

@Colboto many thanks for the video - it almost looks like it is homing the z axis.

Since this is happening when doing the load and print (vs upload to SD) maybe one of the commands is being filtered out or altered incorrectly by the plugin.

[Mrnt]

@G7KXZ , @Colboto can you indicate which version of the Dreamer you are using?

[Mrnt]

@Colboto if you can also get a debug log from the plugin when printing acrylic.gx direct to the printer (just needs to be the beginning of the print where the z platform moves), the log will show if the g-code is being modified before being sent to the printer and should offer a clue. See the readme for how to turn on debug logging for the plugin.

[Colboto]

@Mrnt Will do, I'm at work right now but I'll get this data for you when I get back home. Is there a way to determine which version of the Dreamer I have?

[Mrnt]

@Colboto - Mostly trying to determine if you have the original Dreamer or Dreamer NX just in case there are some firmware specific issues.
A lot of the early printers seem to use much the same firmware, for example I have the PowerSpec Ultra 3D which can mostly take g-code sliced for the Dreamer in FlashPrint, however the newer Dremel printers are clearly a somewhat different beast...

[Colboto]

@Mrnt I have a standard Flashforge Dreamer, and I'm attaching my debug log here. I turned the printer off manually shortly after the platform fell so the log would cut off near that point.

octoprint.log

[JohnDR105]

@mint I have the same issue on two original Dreamers the Z plate stays at its zero location while the X & Y moves are as expected.

[fbb034]

Has this issue been resolved? I am having the same problem