OctoPrint-FlashForge
OctoPrint-FlashForge copied to clipboard
FlashForge Finder 2.0 - Controlling Movement
Flashforge Finder v2.0 Firmware 2.2.7.299 F2.12.2 20181203
controlling print head from #control tab with arrow buttons doesnt work as desired and dosent take home buttons at all.
ie. setting stepsize 10 and press arrow will move head one time in that direction at that distance only relative to start position. will not move any further by pressing arrow again, will only go one step in any direction and on time back.
from terminal tab printer does not respond to G28 command for homing all axis, it only respond to G28 * (* = X, Y or Z), and will not take multiple axis at same command
dosent seams printer respond well as desired to commands G90, G91, G92 from terminal eighter.
Can you connect OctoPrint to the Finder while the printer is in idle state, then in OctoPrint:
- click the X/Y home button once and wait for any movement to finish
- click the Z home button once and wait for any movement to finish
- try clicking x, Y or Z buttons to see if they work, preferably allow movement to finish before clicking another button And let me know what happens?
Please note that on the Finder the Z axis may be inverted - ie the "up" arrow actually makes it go down and vice versa. You can fix this in the Settings > Printer Profiles edit the printer profile, Axes tab > select "Invert control" for the Z axis.
the home buttons doesnt initiate a movement at all.
log in terminal show following on home X/Y:
Send: G91 Recv: CMD G91 Received. Recv: ok Send: G28 X0 Y0 Recv: CMD G28 Received. Recv: ok Send: G90 Recv: CMD G90 Received.
and the following om Home Z:
Send: G91 Recv: CMD G91 Received. Recv: ok Send: G28 X0 Y0 Recv: CMD G28 Received. Recv: ok Send: G90 Recv: CMD G90 Received.
but printer wont respond to G28 if parameter behind is anything else then just a X, Y or Z, and only one of them at once.
G28 X G28 Y G28 Z
works, anything else will not work.
so
G28 X Y
will not work?
After
G28 X
G28 Y
G28 Z
are you able to step X, Y, Z successfully?
and stepping with arrow buttons just moves one time only in each direction with selected stepsize.
you cannot select stepsize 10 and move 20 by pressing arrow twice, it just moved to 10mm relative to current position once.
thats correct "G28 X Y" will not work, it only takes one parameter and it has to be one of the axis X, Y or Z
Interesting. Couple of ideas:
- Have tried controlling from FlashPrint to make sure it is not something an issue with the printer firmware:
- Make sure you do not also have FlashPrint connected to the printer (via WiFi for example) when also connected with OctoPrint.
- Turn on logging for the plugin and look in the log for the response to the M601 command that is sent during connection - it should say something like:
FlashForge.readraw() CMD M601 Received. | Control Success. | ok |
and upload it here as well.
works as it should in flashprint. flashprint not running at all.
responds from M601 is control failed
2020-05-21 19:51:07,262 - octoprint.plugins.flashforge - DEBUG - Found device 'unknown' with Vendor ID: 0X1D6B, USB ID: 0X0002 2020-05-21 19:51:07,263 - octoprint.plugins.flashforge - DEBUG - setting number: 0x00, class: 0x09, subclass: 0x00, protocol: 0x00, #endpoints: 1, descriptor: 0 2020-05-21 19:51:07,264 - octoprint.plugins.flashforge - DEBUG - endpoint address: 0x81, attributes: 0x03, max packet size: 4 2020-05-21 19:51:07,265 - octoprint.plugins.flashforge - DEBUG - Found device 'unknown' with Vendor ID: 0X1D6B, USB ID: 0X0003 2020-05-21 19:51:07,265 - octoprint.plugins.flashforge - DEBUG - setting number: 0x00, class: 0x09, subclass: 0x00, protocol: 0x00, #endpoints: 1, descriptor: 0 2020-05-21 19:51:07,266 - octoprint.plugins.flashforge - DEBUG - endpoint address: 0x81, attributes: 0x03, max packet size: 4 2020-05-21 19:51:07,268 - octoprint.plugins.flashforge - DEBUG - Found device 'FlashForge Finder 3D Printer' with Vendor ID: 0X2B71, USB ID: 0X00EE 2020-05-21 19:51:07,268 - octoprint.plugins.flashforge - DEBUG - setting number: 0x00, class: 0xff, subclass: 0x00, protocol: 0x00, #endpoints: 4, descriptor: 5 2020-05-21 19:51:07,269 - octoprint.plugins.flashforge - DEBUG - endpoint address: 0x81, attributes: 0x02, max packet size: 512 2020-05-21 19:51:07,270 - octoprint.plugins.flashforge - DEBUG - endpoint address: 0x02, attributes: 0x02, max packet size: 512 2020-05-21 19:51:07,270 - octoprint.plugins.flashforge - DEBUG - endpoint address: 0x83, attributes: 0x02, max packet size: 512 2020-05-21 19:51:07,271 - octoprint.plugins.flashforge - DEBUG - endpoint address: 0x04, attributes: 0x02, max packet size: 512 2020-05-21 19:51:07,272 - octoprint.plugins.flashforge - INFO - Found a FlashForge Finder v2.12 2020-05-21 19:51:07,273 - octoprint.plugins.flashforge - DEBUG - FlashForge.init() 2020-05-21 19:51:07,284 - octoprint.plugins.flashforge - DEBUG - claimed USB interface 2020-05-21 19:51:07,284 - octoprint.plugins.flashforge - DEBUG - setting number: 0x00, class: 0xff, subclass: 0x00, protocol: 0x00, #endpoints: 4 2020-05-21 19:51:07,285 - octoprint.plugins.flashforge - DEBUG - found endpoint type LIBUSB_TRANSFER_TYPE_BULK at address 0x81, max packet size 512 2020-05-21 19:51:07,285 - octoprint.plugins.flashforge - DEBUG - found endpoint type LIBUSB_TRANSFER_TYPE_BULK at address 0x02, max packet size 512 2020-05-21 19:51:07,285 - octoprint.plugins.flashforge - DEBUG - found endpoint type LIBUSB_TRANSFER_TYPE_BULK at address 0x83, max packet size 512 2020-05-21 19:51:07,285 - octoprint.plugins.flashforge - DEBUG - found endpoint type LIBUSB_TRANSFER_TYPE_BULK at address 0x04, max packet size 512 2020-05-21 19:51:07,286 - octoprint.plugins.flashforge - DEBUG - cmd_endpoint_out 0x02, cmd_endpoint_in 0x81 2020-05-21 19:51:07,286 - octoprint.plugins.flashforge - DEBUG - sd_endpoint_out 0x04, sd_endpoint_in 0x83 2020-05-21 19:51:07,286 - octoprint.plugins.flashforge - DEBUG - on_connect() 2020-05-21 19:51:07,290 - octoprint.util.comm - INFO - Changing monitoring state from "Offline" to "Opening serial port" 2020-05-21 19:51:07,295 - octoprint.util.comm - INFO - Changing monitoring state from "Opening serial port" to "Detecting baudrate" 2020-05-21 19:51:08,302 - octoprint.plugins.flashforge - DEBUG - FlashForge.timeout() 2020-05-21 19:51:08,303 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() called by thread comm._monitor 2020-05-21 19:51:08,311 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() 2020-05-21 19:51:08,313 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): gcode:M601, cmd:M601 S0 2020-05-21 19:51:08,317 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor 2020-05-21 19:51:08,319 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() called by thread comm.sending_thread 2020-05-21 19:51:08,320 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() called by thread: comm._monitor, timeout: 10000 2020-05-21 19:51:08,322 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() M601 S0 2020-05-21 19:51:08,342 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() CMD M601 Received. | Control failed. | ok | 2020-05-21 19:51:08,345 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor 2020-05-21 19:51:08,348 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor 2020-05-21 19:51:08,351 - octoprint.plugins.flashforge - DEBUG - Setting read timeout to 30.0s 2020-05-21 19:51:08,357 - octoprint.util.comm - INFO - Changing monitoring state from "Detecting baudrate" to "Operational"
Thanks for that information re FlashPrint.
I'm not sure, but I'm thinking M601 Received. | Control failed. | ok |
may be related to the issue.
I am not sure how technical you are - have you ever used something like WireShark to look at network traffic?
Can you verify if the other controls are working - lights, extruder, setting temperature?
I will update the ReadMe to reflect this is not working until I figure it out.
never used wireshark much before, but if i figure out how to filter to just follow 192.168.1.151 i can maybe monitor what flashprint does ?
That would be great if you are willing to have a look!
Hopefully you can capture something meaningful between the printer and FlashPrint on ethernet traffic.
Otherwise, another user was on Windows (I'm on MacOS so a little different) and installed the 64 bit version of WireShark and during installation it gave the option to install USBPcap, which he was able to use to capture USB packets.
temprature and light control works, but control of extrude/retract are not working properly eighter.
looks like flashprint sends this for to printer for homing:
~G28 X Y Z CMD G28 Received. ok
for movement it looks like it sends this to move head:
~G1 Z-1000.000 F800.000 CMD G1 Received. ok
and this to stop movement when button are released in flashprint:
~M112 CMD M112 Received. ok ~M114 CMD M114 Received. X:85.9998 Y:70.0023 Z:113.348 A:0 B:0 ok
saved capture file and follow stream output from wireshark , hope they are readable.
Thanks for that (and pulling it into a single text file) - very helpful to see what is being sent and received. Also there is a command I have not seen - M650
Weird that FlashPrint is sending G28 X Y Z
- you said that did not work when you entered it manually in the Terminal?
When you did the test with FlashPrint prior to to control -
works as it should in flashprint. flashprint not running at all.
was that with FlashPrint connected via USB or WiFi?
It is also interesting that when it moves it is using rather large numbers (not mm) for the steps:
~G1 Z-1000.000 F800.000
~G1 X-1000.000 F2000.000
etc
whereas my v1 Finder uses mm so commands would look more like:
~G1 Z-10.000 F800.000
~G1 X-10.000 F2000.000
Can you try the following sequence of commands in the OctoPrint terminal to see if they work in the same way as FlashPrint:
M650
M114 ; should return X:85.9998 Y:70.0023 Z:140 A:0 B:0
G91
G28 X Y Z ; should home all axes, wait for it to finish
M114 ; should return X:85.9998 Y:70.0023 Z:-2000 A:0 B:0
G1 X-1000.000 F2000.000 ; should move x axis 73mm to the left
M114 ; should return X:12.3752 Y:70.0023 Z:-2000 A:0 B:0
im running flashprint with wifi to printer.
it was little hard to follow everything at the same time, but it looks like flashprint sends ~G1 Z-1000.000 F800.000 hvem you hit the arrow in control panel to move bed, and let it move along until you release the arrowbutton and then sends a M112 to abort movment.
would say thats a rather lazy way of programming it.
tried this command sequence you gave, it homed all axes with G28 X Y Z now, but the G1 command send head all the way to the other end and kept spinning/skipping on belt until i sent M112
after homing it states as you say Send: M114 Recv: CMD M114 Received. Recv: X:85.9998 Y:70.0023 Z:140 E0:0 E1:0
as yours that G1 failed i downscaled it to G1 X-10.000 F2000
Send: G1 X-10.000 F2000.000 Recv: CMD G1 Received.
and get this:
Send: M114 Recv: CMD M114 Received. Recv: X:-10 Y:70.0023 Z:140 E0:0 E1:0
nozzle are now located 10mm left of center bed.
on your finder v1 are origin placed at center or in lower left ?
its in center on v2 as far i have figured out.
Send: G1 X0000.000 Y0000.000 F2000.000 Recv: CMD G1 Received. Recv: CMD M114 Received. Recv: X:0 Y:0 Z:140 E0:0 E1:0
nozzle now are located in center of bed
Ugh sorry about that - I was basing it on what you observed from FlashPrint, which looked like it was sending the number of stepper motor steps rather than mm distance.
G91 is supposed to switch the printer to relative positioning - maybe after homing the printer switches back to absolute positioning. So:
G28 X Y Z
G90
G1 X-10.000 F2000
should put it 10mm left of origin (which is the center of the plate) and:
M114
Recv: CMD M114 Received.
Recv: X:-10 Y:70.0023 Z:140 E0:0 E1:0
Whereas if you do:
G28 X Y Z
G91
G1 X-10.000 F2000
it should go 10mm left of home and:
M114
Recv: CMD M114 Received.
Recv: X:75.9998 Y:70.0023 Z:140 E0:0 E1:0
If that works then it is puzzling because clicking the step button in OctoPrint is supposed to be sending something like:
G91
G1 X-10.000 F2000
to move 10mm to the left.
tried to do another G91 after homing, it still does move to 10 left of origin, its like it recieves the G91 but totally ignore it.
it was little hard to follow everything at the same time, but it looks like flashprint sends ~G1 Z-1000.000 F800.000 hvem you hit the arrow in control panel to move bed, and let it move along until you release the arrowbutton and then sends a M112 to abort movment. would say thats a rather lazy way of programming it.
Ah, I missed this - yes that would explain the large movement numbers. In fact if you remove all the status commands the log you sent distills down to just:
~M601 S1 ; hello, use ethernet for control
~M115 ; get firmware
~M650 ; ?
~M115 ; get firmware again for some reason
~M114 ; get current position
~G91 ; use relative positioning
~G28 X Y Z ; home all three axes
~M114 ; get current position
~G1 Z-1000.000 F800.000 ; send z up to some extreme position
~M112 ; STOP!!
~M114 ; get current position
~G1 X-1000.000 F2000.000 ; send x left to some extreme position
~M112 ; STOP!!
~M114 ; get current position
~G1 Y-1000.000 F2000.000 ; send y forward to some extreme position
~M112 ; STOP!!
~M114 ; get current position
~G91 ; use relative positioning
~G1 Z-1000.000 F800.000 ; send z up to some extreme position
~M112 ; STOP!!
~M114 ; get current position
I wonder if G91 is broken somehow in the firmware. It seems like that would be bad since slicers do use G91, but when I looked through some G code files generated by FlashPrint and Cura they only seem to use G91 at the end of the file when finished printing, so maybe it doesn't matter for printing and if it was broken then that would be why they haven't fixed it.
Did you check that you have the latest firmware?
This may mean that OctoPrint control of head and extruder will not work on Finder v2
As far as i could find on google i May not have the latest, but upgrade firmware on printer states i have the latest.
Looked at the .gx of one of the latest prints. And it use only G90 and G28 X Y Z in the start code.
Further down it use absolute positioning when printing.
So G91 is only needed for manual move ment of axis i guess. But not used by flashforge/flashprint
Not sure if there is possible to rewrite command to do a M114 to get position, set a variables, then use that to calculate absolute position to move axis to.
Doing the flashprint way and sending a big move with G1 then sending M112 to stop will not work well. As sending M112 in terminal also kills the serial connection to octoprint
Yes, I was thinking the way you outlined ie G91
becomes G90, M114, G1 <to some new position based on the result of M114>
. Kind of a pain, but maybe I can do something not too hacky using the rewrite hook.
I think I almost have a solution for the (G91 relative) movement not working - Question: if it was an option in the printer profile to enable a work around, would you find the setting?
If the setting is there it should be possible to find it 😁
@rmhalvorsen I have added some functionality to the development branch to support this printer via a checkbox under the Axes tab of the printer profile.
You can install the development branch using the Plugin Manager > Get More... > and under "...from URL" enter:
https://github.com/Mrnt/OctoPrint-FlashForge/archive/devel.zip
Can you give it a try and let me know if it works?
just done a little testing yet, but so far it doesnt move anything anywhere, and ive made some custom buttons earlyer for homing axes those also stopped working after trying to use motion control arrows or homebuttons
Did you find and enable this control:
With the above enabled, what you should see in the OctoPrint log after clicking a move button is:
FlashForge.write() M90
...
FlashForge.write() M400
...
FlashForge.write() M114
...
FlashForge.write() G1 <some new absolute position based on the step size>
...
FlashForge.write() M90
its enabled and everything hangs up when communicate twith printer.
get this in log:
2020-05-30 23:07:37,794 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() called by thread: comm._monitor, timeout: 30000 2020-05-30 23:07:38,095 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): gcode:G91, cmd:G91 2020-05-30 23:07:38,100 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() called by thread comm.sending_thread 2020-05-30 23:07:38,102 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): gcode:G1, cmd:G1 Y-1 F2000 2020-05-30 23:07:38,103 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() G90 2020-05-30 23:07:38,105 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): gcode:G90, cmd:G90 2020-05-30 23:07:38,115 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() CMD G90 Received. | ok | 2020-05-30 23:07:38,126 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor 2020-05-30 23:07:38,131 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() called by thread comm.sending_thread 2020-05-30 23:07:38,132 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() M400 2020-05-30 23:07:38,132 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor 2020-05-30 23:07:38,136 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() called by thread: comm._monitor, timeout: 30000 2020-05-30 23:08:08,139 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() error: LIBUSB_ERROR_TIMEOUT [-7] 2020-05-30 23:08:08,139 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() 2020-05-30 23:08:08,146 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor 2020-05-30 23:08:08,150 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() called by thread: comm._monitor, timeout: 30000
it disconnects printer after awhile also i see now
Thank you for your log and patience - I'm debugging this blind so that is helpful. I don't think it likes the M400 (wait for movement to finish) command. I just removed the command, so can you reinstall the "devel" version again (as described above) and testing again.
well you are doing all the hard work with this and it makes finder more controllable then it is with just flashprint. for me with bigger custom bed and using cura as slicer to benefit from that, sending directly to printer saves me alot of time not needing to run back and forth with the usb stick for every print.
and for the development part
motion control works as it should with all axes, tested 0.1 , 1 and 10 stepping, testet 100 only on Z as this most likely will send it outside boundries on X and Y, there should maybe be some limits in code to stop it before it reach outside bed size configured in printer profile ?
extract and retract on extruder works also
home buttons does still not work.
well, its confirmed, stepping of 100 will send X and Y outside movable area. i was a little unlucky with keyboard control just now :P
without been trying, it could be an issue no matter what stepping selected.