spurious 'Attempt to divide by zero' message

[kstrauss]

The Tormach and LinuxCNC documentation for G98/G99 seem almost identical. Is there a subtle difference that I'm missing?

I am not familiar with G50/G51. The only occurrence of G50 in the Tormach manual is in the "safety block" of some of the examples and they do not appear in the list of gcodes at https://www.tormach.com/machine_codes_gcodes.html What do they do?

[PCW_MESA]

The Tormach and LinuxCNC documentation for G98/G99 seem almost identical. Is there a subtle difference that I'm missing?

I am not familiar with G50/G51. The only occurrence of G50 in the Tormach manual is in the "safety block" of some of the examples and they do not appear in the list of gcodes at https://www.tormach.com/machine_codes_gcodes.html What do they do?

Sorry M98

[Fenichel]

I've attached a version of my example in which all of the M98s, G50s, and G98s are gone. It exhibits the same behavior as it did when it was PathPilot-style.

There are 4 subroutines and a caller:

• initializeLinux.ngc just initializes the environment.
• set_tool.ngc does what its name implies
• dovetail_female_verbose.ngc is the loquacious version of a routine that I use to cut dovetails. It cuts downward from the top in tiers, where each tier uses some number of passes. Like all of my subroutines, this routine uses the A register as a progress meter. This routine has no known bugs.
• half-dovetail_buggy.ngc has had a bug deliberately re-installed. The bug causes an attempt to divide by zero.
• male 1484 crippled.ncc is the caller. It was originally written with some additional calls (for example, to cut the guide slot for the dovetail), but these have been commented out for this demo.

When you run male 1484 crippled.ncc, you will almost immediately start seeing the status messages from dovetail_female_verbose.ngc, and you'll see the A DRO climbing up from zero. During the subroutine's 12th pass (of 12) on the 9th roughing tier (of 12), when the A DRO is around 17.5, the status message 'Attempt to divide by zero' appears. The exact timing of its appearance might vary with processor speed, but the point is that it appears when the subroutine containing the bug is not running. If male 1484 crippled.ncc's call to half-dovetail_buggy.ngc is commented out, or if the bug in half-dovetail_buggy.ngc is fixed, then this message doesn't appear. Running the demo takes just a couple of minutes.

As I said several messages ago, the interpreter is looking ahead, and that's fine, but the generation of unlocalized or mislocalized diagnostic messages is a symptom of sloppy design.

[PCW_MESA]

I've attached a version of my example in which all of the M98s, G50s, and G98s are gone. It exhibits the same behavior as it did when it was PathPilot-style.

There are 4 subroutines and a caller:

• initializeLinux.ngc just initializes the environment.
• set_tool.ngc does what its name implies
• dovetail_female_verbose.ngc is the loquacious version of a routine that I use to cut dovetails. It cuts downward from the top in tiers, where each tier uses some number of passes. Like all of my subroutines, this routine uses the A register as a progress meter. This routine has no known bugs.
• half-dovetail_buggy.ngc has had a bug deliberately re-installed. The bug causes an attempt to divide by zero.
• male 1484 crippled.ncc is the caller. It was originally written with some additional calls (for example, to cut the guide slot for the dovetail), but these have been commented out for this demo.

When you run male 1484 crippled.ncc, you will almost immediately start seeing the status messages from dovetail_female_verbose.ngc, and you'll see the A DRO climbing up from zero. During the subroutine's 12th pass (of 12) on the 9th roughing tier (of 12), when the A DRO is around 17.5, the status message 'Attempt to divide by zero' appears. The exact timing of its appearance might vary with processor speed, but the point is that it appears when the subroutine containing the bug is not running. If male 1484 crippled.ncc's call to half-dovetail_buggy.ngc is commented out, or if the bug in half-dovetail_buggy.ngc is fixed, then this message doesn't appear. Running the demo takes just a couple of minutes.

As I said several messages ago, the interpreter is looking ahead, and that's fine, but the generation of unlocalized or mislocalized diagnostic messages is a symptom of sloppy design.

Still not runnable on LinuxCNC (still has M98s and M99s that appear to be structural parts of the code), plus G50s

[samco]

Took a bit of hacking...

Linuxcnc doesn't load - it starts out with a divide by zero near line 116 which is the call to <half_dovetail_buggy>

Hacking that file - it ends up being the call to <HDTTier> around 67

    o 720 repeat [#<Tiers>]                                    ; *multilayer
        #<Tier> = [#<Tier> + 1]                                ; .. down from top
        (debug, roughing tier #<Tier> of #<Tiers>)
        #<_Depth> = [#<Tier> * #<VDOC>]                        ; ..
        #<_ZCut> = [#<_ZNeckBottom> - #<_Depth>]               ; ..
;        M98 P730                                               ; .. take passes
        o <HDTTier> call
    o 720 endrepeat

which gets you down to this line 102 in HDTTier (this is what causes linuxcnc not to load the

#<WOC> = [#<HinW> / #<HPasses>]

Initial run through HPasses must be zero

It is zero - if I stop the HDTTier sub at (with an m0) and a debug message.

    o <HDTTier> sub
;    o 730 ; subroutine to do a tier for tool at ZCut, allowing EdgeClearance
        ;    starts at ZClear
        ;    feed, speed, coolant set
        ; W items are offsets from the ClearStart-ClearEnd line
        ; uses TierProg

        #<HinW>    = [#<_Depth> / tan[#<_DovetailAngle>] - #<_EdgeClearance>]

        #<HPasses> = [fup[#<HinW> / #<_WOCRough>]]

 ; unfixed       o 731 if [#<HPasses> GT 0]
(debug, hinw is #<HinW> hpasses is #<HPasses>)
m0
 o <HDTTier> endsub 
            #<WOC>     = [#<HinW> / #<HPasses>]

I end the sub early before the #<HinW>/#<HPasses>

See screenshot - the initial run HPasses is 0

sam

[Fenichel]

@PCW_MESA
The only M98/M99/G50 in the version that I last uploaded are commented out. I think you must be looking at the previous version.
@SAMCO
You found the bug that I deliberately re-introduced in my code (you could have found it by looking for my 'unfixed" comment). Your experience demonstrates that your LinuxCNC engine looks further ahead than PathPilot does, so it finds the (deliberate) bug in half-dovetail_buggy.ngc before even starting to run dovetail_female_verbose.ngc. But then, your LinuxCNC engine mislocates the error (it is at line 94 of half-dovetail_buggy.ngc,not Line 116 of male 1484 crippled.ncc) just as PathPilot did in the example I posted in this thread:yesterday. In this regard (really, the only point of this thread), your LinuxCNC engine behaves no differently from PathPilot.

[samco]

#<HinW> = [#<_Depth> / tan[#<_DovetailAngle>] - #<_EdgeClearance>]

-.000526 = .00775 / 1.732051 - .005

so

#<HPasses> = [fup[#<HinW> / #<_WOCRough>]]

0 = 0 / .008

as a result

#<WOC> = [#<HinW> / #<HPasses>]

-.000526 / 0 Divide by zero..

I don't really think it is a read ahead issue... It is a math issue.

sam

[samco]

I don't know what you are expecting.. Linuxcnc pre-processes the file - does all the math. what are you expecting the values to be for the above?

[Norton-BMW]

[Fenichel]

I have been posing examples of deliberately erroneous code, pointing out that LinuxCNC and (derivatively, PathPilot) handle some errors in ways that wouldn't be accepted in interpreters written as exercises in a second computer course. I think that @samco is telling us that my deliberately erroneous code actually has an error in it. Yes.

[PCW_MESA]

Umm, your original post said it was a spurious divide by 0 error , this has yet to be duplicated under LinuxCNC...

[Fenichel]

Umm, your original post said it was a spurious divide by 0 error , this has yet to be duplicated under LinuxCNC...

I did say that when I first wrote that post (#1 in this thread), but I edited that post (I think I edited it before post #2 appeared) to start with

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.

and everything I've written to this thread since has been about error reporting, not about whether it is OK to attempt to divide by zero, or whether my code with deliberate errors contained errors. I should have retitled the thread, but I don't know how to do that.

Here's a summary of the thread:

• There are linguistic differences between standard LinuxCNC and PathPilot, but these differences turn out to be irrelevant here.
• Different gCode interpreters do different amounts of lookahead.
  
  • Samco's LinuxCNC interpreter (whichever it is) looks far ahead (possibly to the end of all gCode) before starting execution.
  • The gCode interpreter of PathPilot doesn't look quite so far ahead before starting execution, but then it looks ahead during execution.
  
  
• (When gCode can obtain input during execution (e.g., from probes), it is not possible for an interpreter to look ahead to the end of execution, except to the extent of catching syntactic errors)
• Neither of the gCode interpreters discussed in this thread consistently provides diagnostic messages to identify the line in which a syntactic or semantic error was found. Depending on the interpreter and the state of the lookahead, messages may identify an error
  
  • as being "near line <nnn>" of a specified file when that is correct
  • as being "near line <nnn>" of a specified file when the error is inside a subroutine (in that file or a different one) called near the specified line [Failure Mode A] (or, possibly, inside a subroutine called by a subroutine ... called near the specified line)
  • as having occurred, with no line location even suggested [Failure Mode B]
  
  

The example I gave in post #5 fails in Failure Mode A with either interpreter. My multifile example fails in mode A under Samco's interpreter and in mode B under PathPilot.

[samco]

I don't know path pilot.

In linuxcnc it took about 10 minutes to figure out the offending error line. Sort of divide and conquer. It would be nice if lnuxcnc gave you the actual line of the sub. It isn't there yet. Still pretty amazing extended language that works very well.