Error running on windows 10 w/ Printbot pro modern marlin 1.19

[TheNumenorean]

Traceback (most recent call last):
  File "meshscan.py", line 326, in <module>
    offset = run_probing(X_LIM, Y_LIM, SPACING, leveling = True)
  File "meshscan.py", line 266, in run_probing
    row.append(taste_leveling(i+offset,
  File "meshscan.py", line 177, in taste_leveling
    return(float(zzm114))
ValueError: could not convert string to float: ''

Command: python meshscan.py -v -x 150 -y 150 -s 25 -l -p COM4 -m

Also it makes an ungodly racket somehow.

[lellasone]

Did the ungodly racket take place while the machine was traveling along one edge of the board? There seems to be an issue on some printerbots/firmwares where the extreme edges of the bed are problematic for some reason.

Interesting, it looks like it's not going into Modern Marlin mode correctly because that line should read return(float(zzm114)/STEPS_PER_UNIT_Z) if the MODERN_MARLIN variable is True. That doesn't actually explain why zzm114 is empty though, is the printer sending a response to the M114 command?

What version of python are you using? (not that it should really matter)

I was able to re-produce the issue on windows 10 with the following command by setting the delay between sending the startup file and starting the scan too short for the startup GCode to fully run. Such that the calibration was still running when the first probing commands were sent. Is there any chance that's the issue?

pythyon3 meshscan.py -v -x 150 -y 150 -s 25 -l -p COM7 -m

[lellasone]

Added a '-d' argument to the dev branch. I'd try running something like this and seeing what happens:

pythyon3 meshscan.py -v -x 150 -y 150 -s 25 -l -p COM7 -m --start_delay=60

[TheNumenorean]

I suspect a delay is not enough. During that time it prints many lines, and since you have a static 150 characters there is a good chance it will go over.

[lellasone]

Since the serial object gets closed each time the send function ends and since all the startup commands are sent in a burst at the start of the waiting period there should be nothing remaining in the incoming buffer once the delay period ends. (provided there is no overlap between when old commands are being executed and when new ones are being issued).

[lellasone]

You are right though that the 150 characters doesn't actually cover all of the responses. It's way longer then any of the valid ones though (at least as far as I am aware).

[lellasone]

One more thing to check on the subject of those time delays you mentioned while running: The code snippet above looks like it's from the script running in non-modern-marlin mode. The new firmware roughly triples the time it takes to execute a G30, so that might explain the issue you were getting where the timing still doesn't keep up once the scan starts.