Sending a file uploaded to octoprint via Prucaslic3r to the printer via the "Upload to SD" button.

[KeltE]

Hello! Sorry if maybe I'm posting in the wrong place. I'm very new here at Github. Couldn't find another place to write. I have a Dreamer NX connected to Octoprind and am using Prucasl3ser. Prucaslic3rist can send the g-code directly to OctoPi. Is it possible to select a G-code file directly from Octoprint with the "upload to SD card" button?

[Mrnt]

With this plug-in installed you should be able to use the "upload to SD card" button within OctoPrint to upload a gcode file to the Dreamer NX's sd card. I am not familiar with Prucasl3ser, but I suspect that if you are using it to slice and it will connect to OctoPrint, you might be able to send the output from Prucasl3ser directly to the printer's SD card via OctoPrint. It is possible to do exactly that from Cura to a FlashForge Finder and it seems to work fine.

[KeltE]

Prucaslic3ril has a "send to printer" button. It only sends to octoprint. Or, if you check the "start printing" box, the printer will go against the limit switches and start raising the temperature properly, but the printer will not start the printing process. And it doesn't load the g-code into the printer's memory either.
There is no way to send Octopi "stored locally" files to the printer.
printed files remain in octoprint after printing. They can also be reprinted other than re-selecting the file from the computer and uploading Octoprint again.
Is there any way that, for example, with the "Upload to SD" button or a separate button, only the selected files from the Octop SD card will do the same?

[Mrnt]

I downloaded and tested with PrusaSlicer. I was able to configure PrusaSlicer to connect with OctoPrint but (as you also found) when I sent the file to OctoPrint the file was loaded into OctoPrint memory rather than uploaded to the Printer's SD card/memory. There does not seem to be an option to send to the printer SD card which would be a function of the PrusaSlicer integration with OctoPrint.
Unfortunately right now you have to export the files from the slicer as gcode and then use the "upload to SD card" button within OctoPrint to upload a gcode file to printer which will start printing.

If I understand correctly you are asking if the following buttons in OctoPrint can be made to upload to the SD card?

Or are you asking for an additional button that would upload to the printer's sd card?

[KeltE]

At first I thought that one working solution exists and can be expanded a bit. Maybe somehow you can access the files inside the Octop, and do the same as selecting a file from your computer using the "upload to SD" button. Would it be maybe less effort and work?
Thank you for your efforts and time spent understanding me. :)

[Mrnt]

Thank you for clarifying. Let me think about it a bit. I need to finish some work on the plugin that is LONG overdue :)

[Mrnt]

@KeltE I just pushed a new release that should allow you to print g-code directly from OctoPrint without using the "Upload to SD card" button.

[KeltE]

Hello!
Many thanks. Now it no longer keeps the connection active but disconnects after a while. Could it be that I upgraded Octoprint?
I also add the Octoprint terminal lines and the octoprint.log file. maybe it will help.

Best Egon

_Changing monitoring state from "Offline" to "Detecting serial connection"
Performing autodetection with 7 port/baudrate candidates: FlashForge Dreamer NX 3D Printer@115200, FlashForge Dreamer NX 3D Printer@250000, FlashForge Dreamer NX 3D Printer@230400, FlashForge Dreamer NX 3D Printer@57600, FlashForge Dreamer NX 3D Printer@38400, FlashForge Dreamer NX 3D Printer@19200, FlashForge Dreamer NX 3D Printer@9600
Trying port FlashForge Dreamer NX 3D Printer, baudrate 115200
Handshake attempt #1 with timeout 2.0s
Connected to: <octoprint_flashforge.flashforge.FlashForge object at 0xab0dae70>, starting monitor
Send: M601 S0
Recv: CMD M601 Received.
Recv: Control Success.
Recv: ok
Changing monitoring state from "Detecting serial connection" to "Operational"
Send: M115
Recv: CMD M115 Received.
Recv: Machine Type: Flashforge Dreamer NX
Recv: Machine Name: My 3D Printer
Recv: FIRMWARE_NAME: FlashForge VER: V1.9 20191123
Recv: SN: 3a001a-524b5013-20323648
Recv: X: 230 Y: 150 Z: 140
Recv: Tool Count: 1
Recv: Cap:AUTOREPORT_TEMP:1
Recv: ok
Send: M155 S2
Recv: CMD M155 Received.
Recv: ok
No response from printer after 3 consecutive communication timeouts, considering it dead. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Changing monitoring state from "Operational" to "Offline (Error: Too many consecutive timeouts, printer still connected and alive?)"
Connection closed, closing down monitor
octoprint.log
_

[Mrnt]

Hi Egon, sorry it is not working. Can you turn on debugging for the plugin -

• Turn on debug messages for the plugin (Settings > Logging, under "Logging Levels" set octoprint.plugins.flashforge to "DEBUG" and then click the "+" sign next to it, then click "Save") to help troubleshoot connection issues.
• Make a fresh log by deleting the old one and then restart OctoPrint.
• Then upload it here.

Also please supply the settings for your serial connection preferably by uploading ~/.octoprint/config.yaml (remove any confidential information first).

Thanks!

[KeltE]

No need to apologize. I'm glad someone is bothering to deal with the problem :). I tried and did a new installation of octopi and got nicely connected now. the old way of "upload to SD" works beautifully. Since I have raspberryPi connected via Wifi and just the connection was lost then the printer went confused. Started printing something in the air: D. But I tried the "load and print" button and it starts printing, but doesn't activate the print on the print screen like the "load to SD card" button does.
I think it would be safer to just find a solution that would be able to easily download files from different places to the printer. Just like the "Print to SD card" button does Octoprint.
I have worked as a CNC lathe operator for 20 years and I can say for myself that what is inside the machine works well :).

All the best Egon

[Mrnt]

@KeltE Hi Egon,

I have worked as a CNC lathe operator for 20 years and I can say for myself that what is inside the machine works well :).

I bet you have some good stories!

I have an idea of what may be happening but it would be helpful if you can give me another log file with debugging for the plugin turned on like I suggested above - can you try:

• turning on debugging for the plugin - (Settings > Logging, under "Logging Levels" set octoprint.plugins.flashforge to "DEBUG" and then click the "+" sign next to it, then click "Save") to help troubleshoot connection issues.
• restarting your printer
• restarting OctoPrint
• try connecting again
• try the load and print button again
• then upload the new octoprint.log here

Thanks!

[KeltE]

Hello!

Sorry that the answer took so long. I looked at a very good table made with different printers.
I also tested the Motion, Temperature, Lights On / Off and Enclosure Fans On / Off (All tested with an idling printer). Everyone works as it should.
I also re-tested printing from a file uploaded via the Octoprint "upload" button. I then clicked the "Load" button under File and then the "print" button. The connection between Octoprint and the printer was now maintained and the program started correctly. However, when the temperatures were reached, printing began at a height of about 10-15 mm above the table. And about 10 seconds later, the printer started grind the filament. Oh and of course there is no print window in front of the printer when printing starts.

Best Egon
octoprint.log

[Mrnt]

Can you upload your g-code file as well?

re the front panel on the printer - you will not see anything on there except an indication that the printer has an active USB connection because the printer display only shows print progress when printing a file from the SD card or a USB thumb drive. You may be able to monitor temperatures and position using the "Status" screen under "Tools":

But you will not be able to control printing from the printer screen.

[KeltE]

Yes, as you describe.
I send the work used for the test.

Vooliku-hoidik_0.2mm_ABS_11m_Pause test.g.zip

I got a solution for how I can send the files inside the octoprint to the printer with the "upload to SD" button. I downloaded the "FileManager" plugin.
I tested a bit with the "Print" and "load and print" buttons.
Once the job is sent to the printer, it is possible to reprint so that the printer recognizes the start of printing and starts printing again. The only strange thing was that when you print for the second time, the printer does not wait for the table to warm up, but immediately starts to raise the temperature of the tool.
And if you want to cancel printing then you have to do it from the printer.
if you cancel the job from Octoprint, restarting will no longer work.

[KeltE]

Hello! Why does Octoprint occasionally send an M601 S0 request to the printer and disconnect the USB connection to the printer? Printed the same G code 7 times and happened 3 times during it. After the connection is lost, you must manually set the "serial port" to Auto and then you can connect again.
octoprint 16-10-2020.log

Vihmavee renni konks v15_0.2mm_ASA_7h22m.g.zip

[Mrnt]

This is really interesting. It looks like the connection was dropped around 6:29 am due to a USB error:

2020-10-16 06:29:15,717 - octoprint.plugins.flashforge - DEBUG - write() M119
~M27
2020-10-16 06:29:15,720 - octoprint.plugins.flashforge - DEBUG - readraw() returns: CMD M119 Received. | Endstop: X-max: 0 Y-max: 0 Z-min: 0 | MachineStatus: BUILDING_FROM_SD | MoveMode: MOVING | ok | 
2020-10-16 06:29:15,722 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-10-16 06:29:15,723 - octoprint.plugins.flashforge - DEBUG - readraw() called by thread: comm._monitor, timeout: 2000
2020-10-16 06:29:15,726 - octoprint.plugins.flashforge - DEBUG - readraw() returns: CMD M27 Received. | SD printing byte 3045937/17491619 | ok | 
2020-10-16 06:29:15,727 - octoprint.plugins.flashforge - DEBUG - buffering: CMD M27 Received.
2020-10-16 06:29:15,728 - octoprint.plugins.flashforge - DEBUG - buffering: SD printing byte 3045937/17491619
2020-10-16 06:29:15,731 - octoprint.plugins.flashforge - DEBUG - buffering: ok
2020-10-16 06:29:15,732 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-10-16 06:29:15,735 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-10-16 06:29:15,738 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-10-16 06:29:15,745 - octoprint.plugins.flashforge - DEBUG - readraw() called by thread: comm._monitor, timeout: 2000
2020-10-16 06:29:16,335 - octoprint.util.comm - ERROR - Unexpected error while reading from serial port
Traceback (most recent call last):
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/util/comm.py", line 2916, in _readline
    ret = self._serial.readline()
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_flashforge/flashforge.py", line 418, in readline
    data = self.readraw()
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_flashforge/flashforge.py", line 585, in readraw
    raise FlashForgeError("USB Error readraw()", usberror)
FlashForgeError: USB Error readraw() (LIBUSB_ERROR_PIPE [-9])
2020-10-16 06:29:16,360 - octoprint.plugins.flashforge - DEBUG - close()
2020-10-16 06:29:16,670 - octoprint.plugins.flashforge - DEBUG - keep_alive() exiting
2020-10-16 06:29:16,672 - octoprint.plugins.flashforge - DEBUG - closing handle...
2020-10-16 06:29:16,675 - octoprint.plugins.flashforge - DEBUG - on_disconnect()
2020-10-16 06:29:16,685 - octoprint.util.comm - INFO - Changing monitoring state from "Printing from SD" to "Offline (Error: FlashForgeError: 'USB Error readraw() (LIBUSB_ERROR_PIPE [-9])' @ comm.py:_readline:2916)"

and then I am guessing you manually reconnected it?

2020-10-16 07:12:48,631 - octoprint.util.comm - INFO - Serial detection: Trying port FlashForge Dreamer NX 3D Printer, port:1:4, baudrate 115200
2020-10-16 07:12:48,632 - octoprint.plugins.flashforge - DEBUG - __init__()
2020-10-16 07:12:48,640 - octoprint.plugins.flashforge - DEBUG - claimed USB interface
2020-10-16 07:12:48,640 - octoprint.plugins.flashforge - DEBUG -  setting number: 0x00, class: 0xff, subclass: 0xff, protocol: 0xff, #endpoints: 4
2020-10-16 07:12:48,641 - octoprint.plugins.flashforge - DEBUG -   found endpoint type LIBUSB_TRANSFER_TYPE_BULK at address 0x01, max packet size 64
2020-10-16 07:12:48,642 - octoprint.plugins.flashforge - DEBUG -   found endpoint type LIBUSB_TRANSFER_TYPE_BULK at address 0x81, max packet size 64
2020-10-16 07:12:48,643 - octoprint.plugins.flashforge - DEBUG -   found endpoint type LIBUSB_TRANSFER_TYPE_BULK at address 0x83, max packet size 64
2020-10-16 07:12:48,644 - octoprint.plugins.flashforge - DEBUG -   found endpoint type LIBUSB_TRANSFER_TYPE_BULK at address 0x03, max packet size 64
2020-10-16 07:12:48,645 - octoprint.plugins.flashforge - DEBUG -   cmd_endpoint_out 0x01, cmd_endpoint_in 0x81
2020-10-16 07:12:48,645 - octoprint.plugins.flashforge - DEBUG -   sd_endpoint_out 0x03, sd_endpoint_in 0x83
2020-10-16 07:12:48,646 - octoprint.plugins.flashforge - DEBUG - enable_keep_alive(True)
2020-10-16 07:12:48,647 - octoprint.plugins.flashforge - DEBUG - on_connect()
2020-10-16 07:12:48,647 - octoprint.plugins.flashforge - DEBUG - keep_alive() set to:0.5
2020-10-16 07:12:48,648 - octoprint.util.comm - INFO - Serial detection: Handshake attempt #1 with timeout 2.0s
2020-10-16 07:12:48,649 - octoprint.plugins.flashforge - DEBUG - timeout()
2020-10-16 07:12:48,650 - octoprint.plugins.flashforge - DEBUG - Setting read timeout to 2.0s
2020-10-16 07:12:48,651 - octoprint.plugins.flashforge - DEBUG - write() called by thread comm._monitor
2020-10-16 07:12:48,651 - octoprint.plugins.flashforge - DEBUG - write() 
2020-10-16 07:12:48,652 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): gcode:M601, cmd:M601 S0
2020-10-16 07:12:48,653 - octoprint.plugins.flashforge - DEBUG - is_sd_printing()
2020-10-16 07:12:48,655 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2020-10-16 07:12:48,656 - octoprint.plugins.flashforge - DEBUG - write() called by thread comm.sending_thread
2020-10-16 07:12:48,656 - octoprint.plugins.flashforge - DEBUG - readraw() called by thread: comm._monitor, timeout: 2000
2020-10-16 07:12:48,656 - octoprint.plugins.flashforge - DEBUG - write() M601 S0
~M119
2020-10-16 07:12:48,659 - octoprint.plugins.flashforge - DEBUG - readraw() returns: CMD M119 Received. | Endstop: X-max: 0 Y-max: 0 Z-min: 0 | MachineStatus: BUILDING_FROM_SD | MoveMode: MOVING | ok | 
2020-10-16 07:12:48,659 - octoprint.plugins.flashforge - DEBUG - state changed from 0 to 3

but note that the printer did not respond to the M601 but the plugin detects the printer responses and that SD printing is in progress, so subsequent M601 "hello" commands to the printer are filtered out and not sent:

2020-10-16 07:12:48,661 - octoprint.util.comm - INFO - Serial detection: Handshake attempt #2 with timeout 2.0s
2020-10-16 07:12:48,662 - octoprint.plugins.flashforge - DEBUG - timeout()
2020-10-16 07:12:48,662 - octoprint.plugins.flashforge - DEBUG - write() called by thread comm._monitor
2020-10-16 07:12:48,663 - octoprint.plugins.flashforge - DEBUG - write() 
2020-10-16 07:12:48,664 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): gcode:M601, cmd:M601 S0
2020-10-16 07:12:48,664 - octoprint.plugins.flashforge - DEBUG - is_sd_printing()
2020-10-16 07:12:48,665 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): dropping command

Meanwhile OctoPrint is waiting for a response to the M601 "hello" command and because it does not see it, thinks that the printer is not connected and so keeps sending the command until it gives up.

So there are a couple of issues:

• Why did the connection to the printer appear to drop at 6:29am - do you have Polar Cloud or anything else trying to access the printer over Wifi?
• Why does the printer not respond to the M601 command when you reconnect? I am wondering if the connection may not actually have dropped but blocked for some reason, causing the plugin to close the connection. Meanwhile the printer thinks it is still connected to something (eg Polar Cloud?), so when you reconnect it does not respond to the M601 command, however that does seem like a bug in the printer firmware.

[KeltE]

Polarcloud does not support the Dreamer Nx printer. So I have no connection there. Over Wifi I enter the Octop environment through the router.
Fortunately, it doesn't interfere with printing because it loads the job into the printer and can reconnect during the job. It seemed just a strange query to the printer, because I knew the M601 would pause print on Prusa printers.
Otherwise, the plugin has worked pretty well.
Thank you very much for the good work you have done so far.

[KeltE]

I think the subject can be locked at the moment. All the buttons, bells and whistles work that I've tested. The commands in the Dremel.Gcode.protokoll.Pdf file also work beautifully on Dreamer Nx. I even entered commands manually in the Octop environment and working And of course sorry I didn't look at the Dremel Gcode protocol. There yes M601 connection command.

[Mrnt]

Glad to hear it is otherwise working well! I also have a Wiki page with the g-code commands that seem to work and has been updated with most of the ones from the dremel doc: https://github.com/Mrnt/OctoPrint-FlashForge/wiki/G-Code-Reference

If you can reliably reproduce the conditions when it generates this error and closes the connection:

2020-10-16 06:29:16,335 - octoprint.util.comm - ERROR - Unexpected error while reading from serial port
Traceback (most recent call last):
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/util/comm.py", line 2916, in _readline
    ret = self._serial.readline()
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_flashforge/flashforge.py", line 418, in readline
    data = self.readraw()
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_flashforge/flashforge.py", line 585, in readraw
    raise FlashForgeError("USB Error readraw()", usberror)
FlashForgeError: USB Error readraw() (LIBUSB_ERROR_PIPE [-9])

Then we could try a special build to see if it is possible to recover from the error without dropping the connection.

[KeltE]

Yes I will let you know if I can repeat the interruption. It seems to be happening too randomly at the moment. Hard to track that way. During the second hour of printing, the connection was lost again, but now it has been printing for 4.5 hours and the connection has not been lost again.

[KeltE]

Maybe the wrong place to share. Couldn't write anywhere else here.
If it does not fit here then it can be deleted.
I got a document started today where I'm going to put notes on my printer. The work is still in progress, but since I got a lot of information from here, I will share the original version in progress.
Flashforge Dreamer NX Notes English(work in progress).pdf

[Mrnt]

Oh thats great! When I have a chance I'll add a link to it in the docs or Wiki. I will also try to add the information you have there about which commands are supported by the dreamer nx to the g-code reference in the Wiki.

I did ask for an official list of g-code commands on the official FF Facebook page but the response was short and negative.

[KeltE]

I can't say exactly when I'll be ready. It takes me a long time to write. I'm not very good at English. Much remains to be done and tested. I also have access to the Fanuc guide. Pretty much the commands in G-code are the same. I want to test my printer on what works and what doesn't.

It's a shame that Flashforge is trying to keep information that I think should be in the user guide. G-code in for end user use. And as I understand it, they use open source projects a lot in the background.

[KeltE]

This is how Octoprint responds to the M651 command. It appears to be the origin of the machine home position.
CMD M651 Received.
X:158.498 Y:76.2346 Z:0
ok

[Mrnt]

Egon, I finally updated the Wiki with respect to M651 - thanks for that!