spurious 'Attempt to divide by zero' message
The message below the line presents an interesting puzzle, but the solution turns out to be simple. While running the code shown, the interpreter was simultaneously looking ahead through the main program and down into the subroutine next to be called. That's where it found the attempted division by zero. With the diplomatic discretion for which it is famous, the interpreter did not choose to reveal where it had found the problem.
-----------------------------------------------------------------------------------------
I have a gCode program that causes PathPilot to generate a false 'Attempt to divide by zero' message. To document the problem, I went through my code and logged the divisor of every division, even where the divisor was a constant. Some of the resulting code looks like this:
About 3 minutes into the operation of the program, PathPilot's Status output from this code includes (color added)Code:#1 = [2 * #<HPasses>] (debug, A = #5423, T.P = #<_TP>, divisor(2 * HPasses) = #1) #<CutProg> = [#<_TierProg> / [2 * #<HPasses>]] ; .. 2 cuts per loop #<HPass> = 0 ; .. o 10351 repeat [#<HPasses>] ; loops cycle outward #<HPass> = [#<HPass> + 1] ; .. #<_TP> = [#<_ReportTier> + #<HPass>/10000] ; added for debugging #<WOffset> = [#<HPass> * #<WOC>] ; .. (debug, A = #5423, T.P = #<_TP>, divisor(2) = 2) #<ToeUnder> = [#<WOffset> + #<_ToolRadius> - #<_SlotWidth> / 2] o 10355 if [#<_Finishing> OR [#<ToeUnder> GT 0]] ; cut into side #<XOffset> = [#<WOffset> * #<_sin>] #<YOffset> = [#<WOffset> * #<_cos>] #<XSE> = [#<_XClearStart> + #<XOffset>] #<YSE> = [#<_YClearStart> - #<YOffset>] #<XNE> = [#<_XClearEnd> + #<XOffset>] #<YNE> = [#<_YClearEnd> - #<YOffset>] #<XNW> = [#<_XClearEnd> - #<XOffset>] #<YNW> = [#<_YClearEnd> + #<YOffset>] #<XSW> = [#<_XClearStart> - #<XOffset>] #<YSW> = [#<_YClearStart> + #<YOffset>] G00 X [#<XSE>] Y [#<YSE>] ; to SE G01 X [#<XNE>] Y [#<YNE>] A [#<_OldA> + #<CutProg>] ; to NE G00 X [#<XNW>] Y [#<YNW>] ; to NW G01 X [#<XSW>] Y [#<YSW>] A [#<_OldA> + 2 * #<CutProg>] ; to SW G00 X [#<_XClearStart>] Y [#<_YClearStart>] ; to Clear #<_OldA> = [#<_OldA> + 2 * #<CutProg>] o 10355 else ; don't bother cutting air #<_OldA> = [#<_OldA> + 2 * #<CutProg>] ; easy progress G00 A [#<_OldA>] ; .. o 10355 endif ; on to next loop o 10351 endrepeat ; ..
The code quoted above is inside a subroutine, so execution goes ahead despite PathPilot's mistaken detection of an error, but then the run aborts as soon as this subroutine returns.Code:A = 18.973602, T.P = 10.001000, divisor(2) = 2 Attempt to divide by zero A = 18.823018, T.P = 10.000900, divisor(2) = 2 A = 18.672434, T.P = 10.000800, divisor(2) = 2 A = 18.521850, T.P = 10.000700, divisor(2) = 2 A = 18.371266, T.P = 10.000600, divisor(2) = 2 A = 18.220682, T.P = 10.000500, divisor(2) = 2 A = 18.070098, T.P = 10.000400, divisor(2) = 2 A = 17.919513, T.P = 10.000300, divisor(2) = 2 A = 17.768929, T.P = 10.000200, divisor(2) = 2 A = 17.618345, T.P = 10.000100, divisor(2) = 2 A = 17.618345, T.P = 10.000000, divisor(2 * HPasses) = 26.000000
Has anyone else seen this problem before? I don't see how it could be tracked down without going through the code of PP's gCode interpreter.
Similar Threads:
Last edited by Fenichel; 12-03-2017 at 02:48 PM. Reason: problem solved
Re: spurious 'Attempt to divide by zero' message
Is it a PathPilot issue or LinuxCNC issue? AFAIK, PathPilot does a minimal amount of extra error checking on loading a file (verifies it's not a binary for example), but LinuxCNC owns the interpreter.
If so, you'll get a lot more traction going to LinuxCNC rather than posting here.
Re: spurious 'Attempt to divide by zero' message
It's a LinuxCNC issue. As noted in other threads, the control-structure features of gCode were kludged on. The chosen syntax is ugly, with dysfunctional redundancy, and the interpreter was adapted to accept the new features with minimal changes, so, for example, a syntactic error in a subroutine is reported as if it occurred in the calling program, and an execution error in a subroutine (division by zero, for example), may be reported (without location information) while that subroutine is executing, while the caller is executing, or while an unrelated subroutine is executing.
But again, as I tried to say in my earlier post, the problem is not -- as I first thought -- one of falsely claiming attempts to divide by zero. It is a problem of error handling.
Re: spurious 'Attempt to divide by zero' message
If you have an example that demonstrates the problem then posting it to the emc-users mailing list (https://sourceforge.net/projects/emc/lists/emc-users) might provide a useful result. The list has a number of very LinuxCNC savvy users and developers.
Re: spurious 'Attempt to divide by zero' message
@Ken Strauss
The easiest demo I could think of is
Pathpilot responds to this with the messageCode:M98 p100 M30 o 100 #1 = 0 #1 = [#1+1] #1 = [#1+1] #1 = [#1+1] #1 = [#1+1] (add as many as you like) #1 = [#1+1] #1 = [#1+1] lkjlkjlkjlkjlkj #1 = [#1+1] #1 = [#1+1] #1 = [#1+1] #1 = [#1+1] (add as many as you like) #1 = [#1+1] #1 = [#1+1] #1 = [#1+1] M99
even though the problem is not near line 2 at all.Code:G-Code error in demo1.ncc Near line: 2 Invalid G code command issued
It's a little harder to show that messages like "Attempt to divide by zero" can show up while no dividing (much less by zero) is going on, because one must somehow generate a case in which PP's lookahead parsing and pre-execution has got sufficiently far ahead during a time-consuming routine A that PP is working on a to-be-called routine B, finds the error, and sends the (location-unidentified) diagnostic message out amid the status output of the innocent, not-yet-completed routine A. I have such an example (that's why I started this thread), but it has lots of distracting detail.
In any event, the floating "Attempt to divide by zero" is really the same problem as in the trivial example above. If PP had been written so that the message in the example above were
then it would presumably avoid the mysterious, untethered "Attempt to divide by zero" by sayingCode:G-Code error in demo1.ncc Near line: 55 (or wherever the actual lkjlkjlkjlkj were) Invalid G code command issued
Code:Error in demo1sub.ngc Near line: 232 (or wherever) Attempt to divide by zero
This is such an old issue that I find it hard to believe that the LinuxCNC people have not seen it long ago, and decided, for one reason or another, that it was too much trouble to fix. Do you really think that sending them something would help?
Re: spurious 'Attempt to divide by zero' message
Not being a LinuxCNC developer I have no idea if it would help. That said, most developers aspire to produce error free software.
Re: spurious 'Attempt to divide by zero' message
I dont see any history of this error in LinuxCNC, and since this code is using specific PathPilot interpreter modifications
(M98 and M99 are not supported by LinuxCNC)
I suspect Its a PathPilot interpreter bug and should be brought to Tormach's attention
Re: spurious 'Attempt to divide by zero' message
Sounds like there is a problem reporting subroutine line numbers for error reporting rather than actual errors in the interpreter then?
I wonder if they are counting the M98 as the "line" being executed and whatever the sub does is considered to be part of that operation.
Re: spurious 'Attempt to divide by zero' message
The example I showed was M98/M99-dependent, but the same thing happens with an o <subr> call to a <subr>.ngc file.Originally Posted by PCW_MESA
Re: spurious 'Attempt to divide by zero' message
In LinuxCNC?
Can you provide and example of that?
Re: spurious 'Attempt to divide by zero' message
Yes, that's what they are doing. It's not what they should be doing.
Even if it were true (it isn't) that the only subroutines ever used should be those supplied by Tormach, they must concede that there will be occasional bugs. Possibly those bugs will be beyond the competence of ordinary users to fix. Even then, suppose my code is
and that every other line of my code is a debug statement to help me localize problems. If there is a bug in the Tormachsub3.ngc file, PathPilot might issue its diagnostic right after the status line generated by my line 52, amid the lines generated by Tormachsub2, after the status line generated by my line 64, or (only if I were lucky) amid the lines generated by Tormachsub3. What should I tell Tormach to help them find and fix the bug?Code:(my code here) ; lines 1-50 o <Tormachsub1> call ; line 51 (my code here) ; lines 51-60 o <Tormachsub2> call ; line 61 (my code here) ; lines 62-70 o <Tormachsub3> call ; line 71
Last edited by Fenichel; 12-04-2017 at 02:27 PM. Reason: errors in pseudocode
Re: spurious 'Attempt to divide by zero' message
@PCW_MESA
Yes, but (as noted in message #5), my example has a lot of distracting detail. It has a main program (125 lines) that calls 4 different subroutines. The first 2 subroutines are trivial (14 lines, 23 lines), after which a call lets subroutine #3 (163 lines) chug along for a few minutes. When it is getting near its end, a diagnostic relating to the (then buggy, now fixed) subroutine #4 (116 lines) appears amid the status reports from subroutine #3.
I'll unfix subroutine #4 and upload the package if you really want to see it.
Re: spurious 'Attempt to divide by zero' message
OK, I have attached a slightly cut-down version of my original example, still using 4 subroutines & a caller. The exact timing of the appearance of the 'Attempt to divide by zero' message is probably environment-dependent; running PP 1.9.13 in a VirtualBox under Windows 7/64, I see it when the A register (used by all my programs as a progress meter) is between 17 & 18. Your mileage may vary.
Re: spurious 'Attempt to divide by zero' message
Unfortunately this not very close to legal LinuxCNC gcode...
Re: spurious 'Attempt to divide by zero' message
OK, I'll take it up with Tormach.
Re: spurious 'Attempt to divide by zero' message
I'm not a gcode expert and mostly just use CAM but I'm curious. You said that Tormach had added M98/M99. Could you indicate some of the other differences between LinuxCNC gcode and what is allowed on the Tormach?
Re: spurious 'Attempt to divide by zero' message
At least as regards M98/M99, the issue of LinuxCNC compliance is a red herring. The same mislocating diagnostic is generated by this
as by my earlier example using M98/M99.Code:o <erroneous> call M30 o <erroneous> sub #1 = 1 #1 = [#1 + 1] #1 = [#1 + 1] #1 = [#1 + 1] #1 = [#1 + 1] #1 = [#1 + 1] #1 = [#1 + 1] #1 = [#1 + 1] #1 = [#1 + 1] #1 = [#1 + 1] #1 = [#1 + 1] #1 = [#1 + 1] #1 = [#1 + 1] ';l';l';l';l';l';l';l #1 = [#1 + 1] #1 = [#1 + 1] #1 = [#1 + 1] #1 = [#1 + 1] #1 = [#1 + 1] #1 = [#1 + 1] #1 = [#1 + 1] #1 = [#1 + 1] #1 = [#1 + 1] #1 = [#1 + 1] o <erroneous> endsub
I'll update my multi-file example to be LinuxCNC-compliant as soon as PCW_MESA tells us what other differences might be important.
Re: spurious 'Attempt to divide by zero' message
The problems I found were unsupported G and M codes plus comments on Gcode lines
(LinuxCNC does not allow comments at the end of an active gcode line)
I think the error message source problems are the same or similar
Since the divide by 0 error doesn't seem to have even been noticed in LinuxCNC
I suspect its a Pathpilot issue or something about your environment.
If it can be duplicated on a current version of LinuxCNC (2.7.11 or 2.8) , its definitely worth raising PR
( Note that PathPilots version of LinuxCNC is about a 2 year old fork for with significant interpreter changes)
Re: spurious 'Attempt to divide by zero' message
What do you mean by "active gcode line"? In G Code Overview the only restriction seems to be that "comments may appear between words, but not between words and their corresponding parameter". I don't immediately see any lines in Fenichel's example that violate that restriction. What am I missing?
Is there a list of the G and M codes that are unsupported in LinuxCNC so that I can avoid using them?
Re: spurious 'Attempt to divide by zero' message
Yes, I was wrong about the comments ";" comments can be used at end of lines, I probably deleted some other cause of a syntax
error when I deleted the comments and thought they were an issue
The g/mcodes I remember deleting were g98 and G50
Reply with Quote
