Finder V2 Issues After Upgrade - Tool Temp, Bed Position, Stepper Noise

[brendanm720]

I'm experiencing a strange issue after upgrading Octoprint to 1.6.1 and The FlashForge plugin to 0.2.6. It looks like the G-Code is being changed in either Octoprint or the plugin and the printer is not functioning normally.

It was working with the super old versions I was running before (and I may re-install with the older versions). After the upgrade, when it didn't work correctly, I thought maybe there had been some kind of problem with the upgrade (maybe there were steps on the path which I had skipped) so I wiped out my SD Card and reinstalled the newest latest and greatest OctoPrint and FlashForge plugin. This did not yield any different results.

If I "Upload to SD" (the way I have been beginning prints), no matter which tool temp I have in the G-Code, the hot end is set to 180° C and heats to that temp. The build plate comes up to its usual position for tool heating, and after a few seconds the print head starts moving around with filament being extruded in mid-air. There is a strange clicky/grindy quality to the movements of the print head that isn't usually there (the clicks are most likely the extruder not enjoying the fact that it's got PETG in it and it's only heating up to 180° C). If I let the printer do its thing, the hot end eventually warms up to the specified print temp in the G Code and brings the build plate up and tries to print the job. Of course, by this time, it's got a nozzle jam because it's warmed the PETG up enough to ooze all over everything but not really enough to print well.

I can connect the Finder to the Wifi and use Flashprint to stream the GX file and everything prints normally.

octoprint (19).log

[brendanm720]

The other humps in that chart are me cancelling and starting new jobs, and trying to clear the nozzle jam.

[Mrnt]

Sorry for the delay - did you take a look at octoprint.log with debugging turned on for the FlashForge plugin? Or make a clean log and upload it here.

It sounds like the printer is not waiting for the tool to reach temp before printing, but this is really odd since uploading to SD card puts all control in the hands of the printer, ie the code is not modified by the plugin during upload. Exporting a sliced file from FlashPrint then uploading the file to the printer SD card via the FlashForge plugin SHOULD be the same as printing direct from FlashPrint...

[Mrnt]

This is very odd because the looking at the log it appears that the printer only starts printing when it gets to 230C. Not sure why it heats to the intermediate temp of 180C-

According to the log file it appears the printer waits to print while the tool heats to 180 and then it sets the tool temp to 230 and carries on waiting:

2021-05-20 13:59:40,189 - octoprint.plugins.flashforge - DEBUG - readraw() returns: CMD M27 Received. | SD printing byte 0/1000 | ok | 
2021-05-20 13:59:40,190 - octoprint.plugins.flashforge - DEBUG - buffering: b'CMD M27 Received.'
2021-05-20 13:59:40,191 - octoprint.plugins.flashforge - DEBUG - buffering: b'SD printing byte 0/1000'
2021-05-20 13:59:40,192 - octoprint.plugins.flashforge - DEBUG - buffering: b'ok'
2021-05-20 13:59:40,193 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2021-05-20 13:59:40,194 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2021-05-20 13:59:40,195 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2021-05-20 13:59:40,199 - octoprint.plugins.flashforge - DEBUG - readraw() called by thread: comm._monitor, timeout: 2000
2021-05-20 13:59:40,939 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): gcode:M105, cmd:M105
2021-05-20 13:59:40,940 - octoprint.plugins.flashforge - DEBUG - is_sd_printing()
2021-05-20 13:59:40,942 - octoprint.plugins.flashforge - DEBUG - write() called by thread comm.sending_thread
2021-05-20 13:59:40,944 - octoprint.plugins.flashforge - DEBUG - write() M105
2021-05-20 13:59:40,953 - octoprint.plugins.flashforge - DEBUG - readraw() returns: CMD M105 Received. | T0:224 /230 B:0/0 | ok | 
202

Note the SD printing byte 0/1000 which supposedly indicates printing has not started yet and T0:224 /230 indicating the tool is set for 230 and is currently at 224. When the tool finally reaches 228 it says that it starts printing:

2021-05-20 13:59:46,963 - octoprint.plugins.flashforge - DEBUG - buffering: b'CMD M105 Received.'
2021-05-20 13:59:46,964 - octoprint.plugins.flashforge - DEBUG - buffering: b'T0:228 /230 B:0/0'
2021-05-20 13:59:46,964 - octoprint.plugins.flashforge - DEBUG - buffering: b'ok'
2021-05-20 13:59:46,966 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
...
2021-05-20 13:59:47,207 - octoprint.plugins.flashforge - DEBUG - readraw() returns: CMD M27 Received. | SD printing byte 0/1000 | ok | 
...
2021-05-20 13:59:48,201 - octoprint.plugins.flashforge - DEBUG - readraw() returns: CMD M27 Received. | SD printing byte 4/1000 | ok | 
2021-05-20 13:59:48,202 - octoprint.plugins.flashforge - DEBUG - buffering: b'CMD M27 Received.'
2021-05-20 13:59:48,203 - octoprint.plugins.flashforge - DEBUG - buffering: b'SD printing byte 4/1000'
2021-05-20 13:59:48,203 - octoprint.plugins.flashforge - DEBUG - buffering: b'ok'
2021-05-20 13:59:48,205 - octoprint.plugins.flashforge - DEBUG - readline() called by thread comm._monitor
2021-05-20 13:59:48,206 - octoprint.util.comm - INFO - Changing monitoring state from "Operational" to "Starting print from SD"

So the log file matches the temperature curve you see but does not match the print behavior you are describing. I don't really know what can be happening here.

[Mrnt]

Presumably there was something in the G-code file that pre-heated T0 to 180 and then increased it to 240 since there is nothing in the log to indicate a command sent from Octoprint was doing it.