QtPlasmaC Qtvcp Python Traceback on Run From Line after M67

Issue: "Run From Line" works fine unless trying to run from a line AFTER a g-code line that looks like this:

(slow down to 60% for a small hole)


LinuxCNC 2.10.0~pre0
Running on MX Linux 21
Using qtplasmac
Debs built from code pulled roughly 2 weeks ago; I don't have the exact Git rev number handy.
Gcode generated by Sheetcam TNG Development 7.1.28 (I see 7.1.29 is now available)

The full traceback:


Sometimes typing something out helps you to see the obvious that you missed while looking at it the first time. Seems to me the complaint is that an int is expected, but a float (60.0) is received? Is this a Sheetcam post processor issue, or something that could be tweaked in LinuxCNC code to accept ints or floats? Perhaps I'm way off base here. I dabble in python but sure don't write code every day or anything.

I'm not in my shop now or I would experiment with removing the .0 and see if I can Run from Line successfully then...

So I went out to my shop and experimented some more. If I'd not be so rusty with coding I'd have noticed the quotes around '60.0' meaning it's a string... anyhow, so I decided to modify the code to first convert the string to a float, then convert the float to int, and now my Run From Line works as expected in the file that was giving me problems! The (very slightly) modified line is below:

I'm not experienced enough to know if this is an acceptable fix or if it's a cringeworthy hack.

An interesting observation I made also (probably no news to qtplasmac gurus) is that nowhere in my original gcode file is a line found containing "m67 e3 q60.0". It appears that QtPlasmac runs some logic that replaces certain lines with directions of its own when a file is loaded. The closest I can find in the actual file output from Sheetcam is the following:

And from that, the file loading process in qtplasmac creates the offending line, m67 e3 q60.0

Thanks for finding this bug.
A float is valid for an analog pin so the int is incorrect.
linuxcnc.org/docs/devel/html/man/man9/mo...9.html#MOTION%20PINS

The following concerns me though, is it actually changing the value?

The closest I can find in the actual file output from Sheetcam is the following:

M67 E3 Q65

And from that, the file loading process in qtplasmac creates the offending line, m67 e3 q60.0

There is a filter program named qtplasmac_gcode that the gcode file is run through when loaded.

Thanks for the responses, and sure, I will attach the file that gave me trouble.

At Line 274 of this file, you will see M67 E3 Q65. But a view of the code in QtPlasmac looks different, the line numbers don't match and there's the line with the 60.0 float described above. In this picture you'll observe the "m67e3q65" line at 278, and line 279 isn't found in the gcode file. Trying Run From Line for any line greater than 279 resulted in the Python traceback.



Gcode file attached in the exact form I ran it, below.


PS. The qtplasmac version is visible in the picture, v1.233.249

Trying again with the ngc file...

 

 

Thanks, Greg! I see your commit and can easily edit the code on my machine to match. (I'll probably do a git pull on my build VM and build some new debs to take out to my machine too so I have all the latest fixes and goodies; who can resist?)

Back to the topic of hole cutting, do I have a situation where that is being doubly processed? In other words, since Sheetcam is writing the % of slowdown into the gcode (m67e3q65) in addition to adding the #<holes> = 2 line, is qtplasmac told twice to perform hole cutting rules? Not sure if I am making sense. In other words, a situation where qtplasmac is told to figure out where the little holes are by itself and apply hole cutting rules automatically, but on top of that there are feed reduction directives manually written into the gcode by the post processor for each small hole...

Maybe none of this matters and qtplasmac will replace / over-ride sheetcam's m67 lines. Just wondering.

Joel