#315 Gcode subroutines issues

[Anonymous]

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]
O123 RETURN
O200 ENDIF
O124 WHILE [1]
O124 BREAK
O124 ENDWHILE
O123 endsub(End definitions)
M02

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.

[Nick]

AXIS 2.6.0-pre0-4385-g9c95855 -sim
Actually it was tested on several different versions.
And not only by me. There's a topic on this bug on linuxcnc.org:

http://linuxcnc.org/index.php/english/forum/20-g-code/26579-gcode-subroutings-issues

PS sorry for the late answer...

[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]

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]

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]

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.

[Michael Haberler]

Please try the tentative fix: http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=commit;h=13273aadcc931148238d997343cfdf5a1a344952

This now runtests tests/interp/oword-bug315 OK

This is a bug in master only.

-Michael

[Michael Haberler]

this is a tentative fix for v2.5_branch on the second reported issue, please try http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=commit;h=f27301c823067f831713fad78455993b7093f6ef and report

the following now parses OK:

O<multipass> SUB
# _{= #1
O# CALL
O<multipass> ENDSUB
m2}

[Nick]

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

[Michael Haberler]

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