#315 Gcode subroutines issues


There are probably a bug in the O-codes parser/interpretator.

Here are two examples of code which causes errors.

O123 sub
O200 IF [5 LE 0.01]
O124 WHILE [1]
O123 endsub(End definitions)

If BREAK or RETURN are removed the code is accepted, otherwise the error is shown "an 'unknown character after O word'"


Second code:

O<multipass> SUB
#<sub> = #1
O#<sub> CALL
O<multipass> ENDSUB

Undefined #<sub> parameter error is shown. If we define #<sub> outside O<multipass> then we wont get this error till LinuxCNC is restarted.

Both codes causes error on loading the file. No mater that this SUB is never called.


  • Michael Haberler

    please specific a version if downloaded a package, or the top lines of 'git log' if built from git.

  • Michael Haberler

    This is a block nesting error, the 'O123 return' should be read 'O200 return' and then the code executes fine on master.

    O200 IF [5 LE 0.01]
    O123 RETURN ; wrong label - change O123 to O200
    O200 ENDIF

    The line labeling rules for O-word statements are a tad fuzzy, and the - originally separate code - for numeric and string owords has been folded together. I admit this isnt a particularly good explanation for the less than helpful error message.

    I have no comment on the second error - computed calls and gotos are an abomination of control flow and should be deleted from the language to start with.

  • Nick

    Nick - 2013-07-08

    I tought that id in Ocode is needed to simplify finding other Ocodes that belong to the same subroutine.

    So if we write return it should have the same number with IF...

    Otherwise what are they needed for?

    About the seccond error. It's a function which makes multipass cutting. We have got a lot of simple functions to make flat cut, and then want to process them with seleral passes. So we have multipass function which takes pointer to that simple funtion and calls it for each pass.
    I can not imagine how to do that another way with out using "pointres"...
    By the way if we are not using named parameter the code works fine.

    PS sorry for my English...

  • Michael Haberler

    The ocode prefixes are used to group blocks. Now your block is 'if (expression) return' means the corresponding statements need to be labeled with the same oword, because they are a unit of execution.

    I admit it would be valuable to have support to verify proper nesting of blocks and detect obvious errors, but that is fairly hard to do given the existing design of the interpreter code


    Re computed function calls and computed goto: you can always replace them by a chain of if-then-else (a case statement would be nice but we dont have that)

    The reason why I advocate removing computed function calls and computed goto from the language altogether is that it is practically impossible to determine if a program makes any sense at parse time, and that is not something you'd want in a machine control - if anything, we need better parse time analysis

  • Nick

    Nick - 2013-07-08

    O-retun corresponds to O-sub, and not to O-if. So it imho should have Subs prefix. How will parser find from which Sub it should return? From the execution stack? And why this prefix is needed for again, just to check that it is the same with the execution unit?


    Using if/elseif is less prefered in our situation - thus we will have to modify multipass sub each time new function is added, plus multipass is used in our Linuxcnc Features - aka native cam, and usually multipass is used only with small amount of that small functions so most of them are not presented in the Gcode so we will have to include all of them to Gcode othervise we will probably get undentified O-calls.

  • Chris Radek

    Chris Radek - 2013-07-08

    Nick, could I suggest that you split the second report into a separate bug? It makes the conversation really confusing to have them combined.

    About the O label on the return: I agree (and Ken L agreed in private email to me and Michael) that your original code is correct and the return label should match the sub label. Your original code runs correctly in v2.5.2 and this is simply a regression in master that needs to be fixed before 2.6.

    I'm going to ask Michael to redirect discussion about this regression to the devel list.

  • Nick

    Nick - 2013-07-09

    Thank you for the quick fix I will try it later from home!

  • Michael Haberler

    fixed in f27301c8 (v2.5_branch) and f27301c8 (master)

  • Michael Haberler

    • status: open --> open-fixed
    • Group: -->