FlashForge Finder 2.0 - Controlling Movement

[rmhalvorsen]

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.

[Mrnt]

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.

[rmhalvorsen]

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.

[Mrnt]

so
G28 X Y
will not work?
After

G28 X
G28 Y
G28 Z

are you able to step X, Y, Z successfully?

[rmhalvorsen]

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.

[rmhalvorsen]

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

[Mrnt]

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.

[rmhalvorsen]

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"

[Mrnt]

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?

[Mrnt]

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.

[rmhalvorsen]

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 ?

[Mrnt]

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.

[rmhalvorsen]

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.

Flashforge_finder_v20.zip
Follow_stream.txt

[Mrnt]

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

[rmhalvorsen]

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.

[rmhalvorsen]

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

[Mrnt]

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.

[rmhalvorsen]

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.

[Mrnt]

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

[rmhalvorsen]

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

[Mrnt]

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.

[Mrnt]

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?

[rmhalvorsen]

If the setting is there it should be possible to find it 😁

[Mrnt]

@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?

[rmhalvorsen]

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

[Mrnt]

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

[rmhalvorsen]

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

[rmhalvorsen]

it disconnects printer after awhile also i see now

[Mrnt]

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.

[rmhalvorsen]

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.

[Mrnt]

Just so I understand:
G28 X works?
G28 Y works?
G28 Z works?
G28 X Y Z works?
G28 X Y does NOT work?

Your printer may be different, but there is another problem with my printers: if the printer takes 4 or more seconds to home it drops the connection to OctoPrint because OctoPrint waits for it to finish but if the printer does not receive anything for 4s then it assumes the host is gone. This will easily happen when homing all 3 axes. I have been working on a fix for this problem for a while and it is almost ready.

[rmhalvorsen]

that correct on all about G28.

it dosent loose connection here while homing, but it looses connection sometimes while printing but have not got around to look into it, but seams to be an usb issue

[Mrnt]

OK I added a change for homing as discussed above. Can you re-test by installing the Finder 2/Guider 2 branch using the Plugin Manager > Get More... > and under "...from URL" enter:
this URL
https://github.com/Mrnt/OctoPrint-FlashForge/archive/No_G91_Support.zip

[rmhalvorsen]

the X/Y home button only homes Y axis

[Mrnt]

That is really confusing. OctoPrint should now be sending:

G28 X
G28 Y

when you press the X/Y home button. I tested to make sure both commands are sent and they seem to be. Can you verify from the log that the two commands are sent and see whether the printer provides any feedback that might be a clue as to why it ignores the G28 X command.

[rmhalvorsen]

it sends both commands, may it be that they come too close together so printer straight out just ignores one of them for some reason?

2020-06-09 20:41:01,238 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() called by thread: comm._monitor, timeout: 30000
2020-06-09 20:41:02,735 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): gcode:G91, cmd:G91
2020-06-09 20:41:02,739 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): gcode:G28, cmd:G28 X0 Y0
2020-06-09 20:41:02,741 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() called by thread comm.sending_thread
2020-06-09 20:41:02,752 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() G90
2020-06-09 20:41:02,756 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): gcode:G90, cmd:G90
2020-06-09 20:41:02,764 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() CMD G90 Received. | ok |
2020-06-09 20:41:02,776 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor
2020-06-09 20:41:02,782 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor
2020-06-09 20:41:02,784 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() called by thread: comm._monitor, timeout: 30000
2020-06-09 20:41:02,786 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() called by thread comm.sending_thread
2020-06-09 20:41:02,792 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() M114
2020-06-09 20:41:02,806 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() CMD M114 Received. | X:-5.26877 Y:70.0023 Z:0 A:0 B:0 | ok |
2020-06-09 20:41:02,806 - octoprint.plugins.flashforge - DEBUG - pos: {'Y': 70.0023, 'X': -5.26877, 'Z': 0.0, 'E1': 0.0, 'E0': 0.0}
2020-06-09 20:41:02,810 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor
2020-06-09 20:41:02,815 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor
2020-06-09 20:41:02,822 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor
2020-06-09 20:41:02,823 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() called by thread comm.sending_thread
2020-06-09 20:41:02,823 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() called by thread: comm._monitor, timeout: 30000
2020-06-09 20:41:02,826 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() G28 X
2020-06-09 20:41:02,834 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() CMD G28 Received. | ok |
2020-06-09 20:41:02,837 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor
2020-06-09 20:41:02,840 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor
2020-06-09 20:41:02,842 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() called by thread: comm._monitor, timeout: 30000
2020-06-09 20:41:02,843 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() called by thread comm.sending_thread
2020-06-09 20:41:02,845 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() G28 Y
2020-06-09 20:41:02,857 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() CMD G28 Received. | ok |
2020-06-09 20:41:02,860 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor
2020-06-09 20:41:02,862 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor
2020-06-09 20:41:02,864 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() called by thread: comm._monitor, timeout: 30000
2020-06-09 20:41:02,867 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() called by thread comm.sending_thread
2020-06-09 20:41:02,869 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() G90
2020-06-09 20:41:02,884 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() CMD G90 Received. | ok |
2020-06-09 20:41:02,887 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor
2020-06-09 20:41:02,890 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor
2020-06-09 20:41:02,892 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() called by thread: comm._monitor, timeout: 30000
2020-06-09 20:41:03,172 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): gcode:M105, cmd:M105
2020-06-09 20:41:03,175 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() called by thread comm.sending_thread
2020-06-09 20:41:03,177 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() M119
2020-06-09 20:41:03,187 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() CMD M119 Received. | Endstop: X-max:0 Y-max:1 Z-max:1 | MachineStatus: READY | MoveMode: READY | Status: S:1 L:0 J:0 F:0 | ok |
2020-06-09 20:41:03,190 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor

[Mrnt]

It's probably depends on the phase of the moon ;-)

The log shows it received the commands so maybe your theory about timing is correct. We can sort of test your theory if you try manually entering:

G90
M114
G28 X
G28 Y
G90

[rmhalvorsen]

Tryed it, and it ignores the second G28 command while its still homing the first one.

dont know if there is way to delay sending the second command, it takes 5-6 second to home X or Y if the extruder is in the opposite end of printer.

[Mrnt]

You can try this but it may cause the connection to the printer to drop (make sure to move the X and Y to the opposite end of home first, as in your previous test):

G90
M114
G28 X
M400
G28 Y
G90

M400 is supposed to block until any pending movement has finished. So in this case the printer would not reply to the M400 until G28 X has completed at which point OctoPrint would send the next command, ie G28 Y.

[rmhalvorsen]

That worked.

[Mrnt]

OK, I just pushed that change to the repo.

Can you re-test by installing the Finder 2/Guider 2 branch like before, using the Plugin Manager > Get More... > and under "...from URL" enter this URL:
https://github.com/Mrnt/OctoPrint-FlashForge/archive/No_G91_Support.zip

[rmhalvorsen]

well, that did not work very much, the big question is why that worked while i typed it manually in terminal and not trough script.

2020-06-10 04:34:20,658 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor
2020-06-10 04:34:20,659 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() called by thread: comm._monitor, timeout: 30000
2020-06-10 04:34:21,484 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): gcode:G91, cmd:G91
2020-06-10 04:34:21,492 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): gcode:G28, cmd:G28 X0 Y0
2020-06-10 04:34:21,494 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() called by thread comm.sending_thread
2020-06-10 04:34:21,505 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() G90
2020-06-10 04:34:21,506 - octoprint.plugins.flashforge - DEBUG - rewrite_gcode(): gcode:G90, cmd:G90
2020-06-10 04:34:21,515 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() CMD G90 Received. | ok |
2020-06-10 04:34:21,520 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor
2020-06-10 04:34:21,526 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor
2020-06-10 04:34:21,527 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() called by thread: comm._monitor, timeout: 30000
2020-06-10 04:34:21,532 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() called by thread comm.sending_thread
2020-06-10 04:34:21,534 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() M114
2020-06-10 04:34:21,547 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() CMD M114 Received. | X:15.9998 Y:30.0023 Z:140 A:0 B:0 | ok |
2020-06-10 04:34:21,549 - octoprint.plugins.flashforge - DEBUG - pos: {'Y': 30.0023, 'X': 15.9998, 'Z': 140.0, 'E1': 0.0, 'E0': 0.0}
2020-06-10 04:34:21,552 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor
2020-06-10 04:34:21,556 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor
2020-06-10 04:34:21,563 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor
2020-06-10 04:34:21,566 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() called by thread comm.sending_thread
2020-06-10 04:34:21,566 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() called by thread: comm._monitor, timeout: 30000
2020-06-10 04:34:21,568 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() G28 X
2020-06-10 04:34:21,578 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() CMD G28 Received. | ok |
2020-06-10 04:34:21,580 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor
2020-06-10 04:34:21,583 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor
2020-06-10 04:34:21,585 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() called by thread: comm._monitor, timeout: 30000
2020-06-10 04:34:21,587 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() called by thread comm.sending_thread
2020-06-10 04:34:21,589 - octoprint.plugins.flashforge - DEBUG - FlashForge.write() M400
2020-06-10 04:34:51,588 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() error: LIBUSB_ERROR_TIMEOUT [-7]
2020-06-10 04:34:51,590 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw()
2020-06-10 04:34:51,593 - octoprint.plugins.flashforge - DEBUG - FlashForge.readline() called by thread comm._monitor
2020-06-10 04:34:51,600 - octoprint.plugins.flashforge - DEBUG - FlashForge.readraw() called by thread: comm._monitor, timeout: 30000

[rmhalvorsen]

it doesent matter if extruder is already at home positions or anywhere else, it times out eighter way

[Mrnt]

I think the other changes I spoke about will address this issue. I will try and push those out and then fix the homing issue.

[Mrnt]

@rmhalvorsen I just pushed 0.2.1 which adds in support for the homing, movement issue via a setting under "Axes" in the printer profile. Can you give it a try?

[TorStava]

@Mrnt, I have just tested the controls on my FlashForge Finder 2.0 but they don't work for me with the latest version of the plugin (0.2.1). However, downgrading the plugin to version 0.1.22 made the controls work (for the most part). I could control movement, turn lights on and off, but the Z-axis tried to move beyond its limits. I'll be happy to provide more structured testing and any logs that would help you, just let me know what you need.

[Mrnt]

@TorStava can you try with the dev branch as described in the other issue #45 (comment)

[rmhalvorsen]

Sorry for late reply, but havent been home.

Can try this tomorrow when ill get home.

[Mrnt]

@TorStava @rmhalvorsen if you could start off with a clean log, make sure debugging for the FlashForge plugin is turned on (as described in the troubleshooting section of the readme) (and preferably no other plugins enabled apart from the ones that actually come with OctoPrint and the FlashForge plugin) and do the following:

Install the dev branch as mentioned above, then:

1. Check that the setting in the Settings > "Printer Profiles" > printer profile for your printer > "Axes" tab where you need check the box next to "G91 Not Supported" then connect to the printer and then use the controls X,Y,Z to see what happens - upload log if not working correctly
2. Try uploading a gcode file to the SD card using the "Upload to SD" button - you should see upload progress go to 100% and then OctoPrint should immediately go into print mode showing print progress and wait for the extruder/bed to warm up.
3. Try printing directly from OctoPrint using the "Upload" button and then starting the print process (during this process you should also see print progress in the "GCode Viewer" tab).

If any of these steps fail it will likely be early on but having a detailed log file should really help identify the issue.

[TorStava]

@Mrnt, here are the results of the tests. Let me know if you need anything else, I'll be happy to assist.

Test 1: Controls

• Connected printer
• Tested X, Y, and Z control on the Control tab
• X, Y, and Z stepping appears to be working fine
• Homing the X and Y axis: Started by homing the X-axis and the appear to hang
• Homing Z-axis seems to work fine
• logfile: octoprint_finder_controls_2020-08-28.log

Test 2: Upload to SD

• Connected printer
• Uploaded file using the Upload to SD button
• Printer started immediately to warm up and print started as expected
• Seems to work fine
• Printer could not be stopped from Octoprint so was stopped by cancelling on the printer panel
• logfile: octoprint_finder_uploadtosd_2020-08-28.log

Test 3: Upload then Print

• Uploaded file using the Upload button
• Selected the file and pressed the Print button
• Progress jumps to 6% then appears to hang
• Printer starts heating up hot-end
• Temperature graph appears to be lagging and the print progress stays fixed at 6%
• After hot-end reaches temperature it took longer time than usual, but the print started
• The bed did not move to the correct position so the filament was deposited in the air
• The progress bar appeared to continue from 6% to 7%
• I cancelled the print from Octoprint
• The hot-end did not appear to get reset so I turned it off manually from Octoprint
• Finally disconnected the printer from the Octoprint interface
• I realized that the bed and extruder was still in the position from the last test when starting this test, and it didn't perform any homing before starting the print. (Flashprint always performs a homing of all axis before starting a print.)
• logfile: octoprint_finder_uploadthenprint_2020-08-28.log

Test 4: Upload then Print 2

• Manually homed the printer using the printer panel
• Uploaded file using the Upload button
• Selected the file and pressed the Print button
• Progress jumps to 6% then appears to hang
• Printer starts heating up hot-end
• Temperature graph appears to be lagging and the print progress stays fixed at 6%
• Print bed raises up to about 4-5 cm from the hot-end (similar to what happens in FlashPrint)
• After hot-end reaches temperature it took longer time than usual, but this time the bed raised to the correct level and the print started fine.
• The progress bar continued on from 6%
• Left the print running for a little while, then tested the Pause button in Octoprint
• The printer stopped moving but hot-end didn't turn off
• Then got an error pop-up in Octoprint and the printer connection was dropped
• logfile: octoprint_finder_uploadthenprint_2_2020-08-28.log

[Mrnt]

@TorStava Awesome - thanks for breaking them into separate named files!

Looks like on the first log the printer is not recognizing the M400 (wait for movement to finish) command - can you verify this by just making a connection, go to the Terminal tab, type M400 and send it and then OctoPrint will should stop sending commands?

[TorStava]

@Mrnt, You're welcome. It seems the dev version is close to working as expected now. I can print with this version both with Upload to SD and by using Upload then Print. Although some small issues would be nice to solve, this works! Big kudos to you sir!

I tested sending the M400 command and the same thing happened as in Test 1; No more communication was received, and after a short time the connection to the printer was dropped.

octoprint_finder_m400_2020-08-29.log

[TorStava]

I did some additional testing using the Terminal tab:

• Issuing G28 without parameters does nothing. The printer responds with "ok" but nothing else happens.
• Issuing G28 X homes the X-axis successfully
• Issuing G28 Y homes the Y-axis successfully
• Issuing G28 Z homes the Z-axis successfully
• Issuing G28 X Y Z homes all axis successfully
• Issuing G28 X Y homes the X-axis but then hangs on M400 command

[Mrnt]

@TorStava, @rmhalvorsen I made a new branch and added a fixes for:

• the G28 X Y home issue
• the Pause, Cancel buttons sometimes being disabled after an "Upload to SD"

Can you re-test by installing 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

[Mrnt]

@TorStava can you also 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 (like you did for M400) and see if it also drops the connection.

[Mrnt]

Forget the M132 test looks like it doesn't handle the command when printing directly even though it seems ok in a file on the SD card (does not bode well for other commands).

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.