OctoPrint-FlashForge
OctoPrint-FlashForge copied to clipboard
Mrnt
Flashforge Finder 2 - Print not working
Happy to provide debug logs, just not sure which ones you want. And happy to be a guinea pig to test things out.
I can load and hit print on a job, it will start heating up and hit the start temp, but the bed never moves, and nothing ever extrudes. The only thing that happens is it heats up.
It does have "Unexpected error while reading serial port" and "FlashForgeError: 'USB Error readraw() (LIBUSB_ERROR_IO [ -1])'" coming up every few seconds.
I've enabled the G91 setting in Axes.
If I load the same job through Octoprint to the SD Card it prints just fine.
Well I'm glad the SD card method still works.
Can you turn 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. Restart OctoPrint just to be safe, then repeat what you did to cause the error and then upload the octoprint.log here. With any luck I will be able to figure it out. Hopefully.
OK, something else has gone wrong with my printer. Now nothing is working and when I try to load any job I get "Lack of Extruder Temperature" error on the printer screen. Let me fix that first.
I'm thinking I broke the plugin for some printers - see https://github.com/Mrnt/OctoPrint-FlashForge/issues/40#issuecomment-679549359.
Do you have a link to the previous version I can manually roll back to and test that theory out?
You can download old versions as zip files and then install them via the OctoPrint plugin manager. Version list is here: https://github.com/Mrnt/OctoPrint-FlashForge/releases
If you feel comfortable editing the code you can try that first following the directions I gave in the other thread. Either way an octoprint.log file would help me identify the cause since it is working fine on my printers.
Thanks and sorry, for the trouble.
I really do test pretty thoroughly but part of why developing this plugin is such a slow process is that it is all reverse engineering from my printers and then looking at log files from other people like yourself.
Don't be sorry. If it weren't for you, I'd have nothing at all. I'm not scared of tracking down a few bugs and running a few tests to help out. It's the only thing I can do to contribute.
@Mrnt I'm thinking I broke the plugin for some printers - see #40 (comment).
And we aren't complaining! Thank you so much for giving us an opportunity to get away from the limited OEM Dremel software.
@Mrnt Don't sweat it -- custom plugins are always kind of a game of whack-a-mole. :-D
OK, I was able to print using SD Card upload with version 0.1.22. Kicked off the print just fine. I did that in the attached log. (all this starts around 12:00 today)
I then updated to 0.2.1 and tried to print the exact same thing again. That print didn't even start. I saw it stream the file to the printer (display on printer showed incoming file) but the job never kicked off.
Thanks, thats great info. Give me a little time to figure out what is happening.
Thanks, thats great info. Give me a little time to figure out what is happening.
Happy to provide more or do some testing if you need.
Thanks to @Mrnt for the great work on this extension. I would love to see the print from Octoprint working.
I have a Flashforge Finder 2.0 and Wireshark installed on a Windows machine and can provide logs if wanted. I have also tested this with a clean Octoprint version installed on a RPi4. When testing the printer behaved the same way as described by @reuter, the nozzle heats up but the print never starts.
(BTW: The upload to SD card method works fine)
I'll be happy to assist in any way I can to make this work.
@reuter I am not sure if it matters or not but:
- it looks like the PolarCloud plugin is throwing a bunch of errors. If possible can you disable it at least temporarily to eliminate it as an issue.
- it looks like you are still on Python 2.7 possibly because PolarCloud does not support Python 3. Again probably not the issue here, but you prob will need to move to Python 3 soon.
That all aside, I think the issue here is that the M155 command may not handled by the Finder 2 and so OctoPrint stops sending commands. To test that out I hopefully disabled it in the development branch. If you and @TorStava want to give it a try before I push it to release: go to Settings > Plugin Manager > click "Get More" > in the box "... from URL" enter: https://github.com/Mrnt/OctoPrint-FlashForge/archive/devel.zip and it should download the latest version of the devel branch. Restart OctoPrint before testing.
@reuter @TorStava @brendanm720 If you can test the dev version (and provide an octoprint.log) with a clean install and no other plugins it would be super helpful
Remove Polar Cloud Altogether. Not going to need it if I can get this working anyway. Installed the Dev version and tested. It heated, the head moved this time, but not the bed. But... it started making some pretty horrible noise, spewing filament and not moving the head anymore. I canceled the job, but manually used Home from the Printer front panel. Attached is the log.
Also, I have setup octopi fresh on a Rpi3 now (not the one with this log). I can try on that one too if you want. Just wanted to keep things consistent for now.
@reuter I'll take closer look in a bit, but at first glance it looks like it always reports it's status in response to M119 as MachineStatus: READY | MoveMode: READY | whereas other printers report things like HOMING when homing or WAIT_ON_TOOL when waiting for the extruder or bed to heat up. This will make it hard to determine what the printer is doing...
Did you mention that you can use Wireshark or was that someone else? I would be interested to see what or if the printer reports back its status to FlashPrint or PolarCloud when printing.
It wasn't me, but I'm happy to set up wireshark and capture that for you.
Gimme a bit.
Managed to get it up and running on Wifi (Long Story). I captured a test print sent over from Flashprint. It shortly after lost connection with the printer. That usually doesn't kill/stop the print (in this case, it started to spaghetti out on me, so I manually cancelled from the Printer screen)
I also captured sending over various movement commands for the bed and the print head unit.
Wireshark captures attached.
That's helpful - it looks like what someone else found - that FlashPrint sends the print head to either a very large negative position or very large positive position (depending on which button you press) and then issues the emergency stop command when you stop pressing the button.
It looks like the M119 command never reports the movement status correctly - can you capture what happens when you set "Jog Mode" to say 10mm and move X. Also can you try "Center X".
Here's a few more logs with some random movement commands. Jog was set to 10 on the first one and 20 on the second. I wasn't holding any buttons down. I would click the Z+ or Y- like buttons. I also typed in the 0 and hit enter as well as clicking the Center X, Y and Z buttons a couple times.
OK great thanks! Looks like it still sends the G91 command but in a way that doesn't do anything which is weird - why bother sending it...
And it looks like it did not send any homing commands G28 so presumably it just uses the G1 command instead to do the 'centering'.
I'm getting myself confused because there are actually more than one issues open for this same bug. In the other one I put: I made a new branch and added fixes for:
- the G28 X Y home issue
- the Pause, Cancel buttons sometimes being disabled after an "Upload to SD"
If you want to give it a try you can install the Finder_2 branch using the Plugin Manager > Get More... > and under "...from URL" enter this URL:
https://github.com/Mrnt/OctoPrint-FlashForge/archive/Finder_2.zip
I am fairly sure there is also an issue with using the M132 command, if you want to also take a look at that - can you try doing a clean connection to the printer, making it do some movements to ensure they are talking to each other and then go to the Terminal tab and enter M132 X Y Z A B and see if the printer drops the connection (like it was doing before when hitting the X&Y home button).
Installed and issued a few movement commands. All was working well. Issued the M132 X Y Z A B command in the terminal and the terminal stopped outputting anything. Attached Log. octoprint (1).log
I just pushed an update to the Finder_2 branch that disables the M132 command. To test you will need to reinstall using the URL above.
I'm getting myself confused because there are actually more than one issues open for this same bug. In the other one I put: I made a new branch and added fixes for:
You're not the only one getting confused. Should this one be merged with #29 ?
So, I tested the latest Finder_2 branch (after you disabled the M132 command). The test was done with a .gx file sliced with FlashPrint.
The test started fine and seemed to work up until about 2/3 in the print when the printer stalled and one of the steppers made an ominous sound. I couldn't tell exactly, but I think it was either the Y-axis or the extruder stepper. After a short period, the connection to the printer was dropped.
I then reconnected to the printer using the "Connect" button in Octoprint and homed the axis and turned off the hot-end manually, then disconnected the printer again.
The logfile for the test print: octoprint_finder_testprint_2020-08-31.zip
Two other things I noticed in this version:
- In the Controls when I now press the Home XY button, the printer homes the Y-axis and then stops. I see the G28 X command sent in the Terminal tab and the printer responded "ok", but the command is never executed. If I issue G28 X Y Z manually, it works fine (homes the Z-axis first, then X, then Y).
- Using the manual controls it's possible to push the printer out of its limits in the axis ends that don't have any endstops. When I selected the 100 multiplier and clicked the left X-axis arrow, the printer didn't stop until it hit the physical end of the axis and the stepper made unpleasant complaining sounds. A similar thing happened a couple of days ago for the Z-axis, where the bed actually drove into the nozzle. I didn't test the Y-axis but expect it would have the same results.
@TorStava a quick look shows that CMD M601 Received. | Control failed. M601 is used to connect - do you have any other software concurrently talking directly to the printer, maybe over a network/wifi connection?