Duplicate O word label error in version 2.6

More
16 Apr 2014 23:35 #45991 by fodder7
I am using v2.6.0-pre0-5409-ge66e5c9 of linuxCNC
I have a bunch of custom code and GUI using GladeVCP and python

When I call the following o word file using a python MDI call it works the first time but the second time it gives me an error:
Duplicate o-word label on line 47 which is:
o<getnew> if [#2 GT 0]

My memory is a little shaky on this but I was running v2.4 about a year ago and this code worked I believe. I updated to the v2.6 pre version and now it does not. I know that its not a duplicate label but trying to figure out why it thinks so is what is driving me crazy. I lately have been under the assumption that it still has this gcode file in memory and therefore thinks its a duplicate but by checking the Linuxcnc.status before and after the call to this routine it says that the opened file before this call is the cut file that I am using and then after the call it says the same so I just don't know.

I am going to try and revert back to linuxCNC v2.5 and see if it works then. Here is the file printout:
o<tool> sub
;Call as:
; o<tool> call [1] [2]
G49 G20 G90

(PRINT, in tools prog 1=#1 and 2=#2)
G28.1 ;temp store current location
G53 G0 Z0
;Need to turn off spindle here.
#<_xput>= #[1000+#1]
#<_xget>= #[1000+#2]
#<_yput>= #[1100+#1]
#<_yget>= #[1100+#2]
#<_zput>= #[1200+#1]
#<_zget>= #[1200+#2]
#<_hput>= #[1300+#1]
#<_hget>= #[1300+#2]
(PRINT, init 0: put x=#<_xput> y=#<_yput> z=#<_zput>)
(PRINT, init 0: get x=#<_xget> y=#<_yget> z=#<_zget>)

(************************************************************)
(** Put Tool Back)
(************************************************************)
;if first passed parameter is not 0 then put tool up.
o<putback> if [#1 GT 0]
G0 X#<_xput> Y[#<_yput>+1] (go to tool PUT X,Y+1)
G53 G0 Z#<_zput>
G53 G0 Y#<_yput> (Slide Tool into Palette)
(PRINT, kin 1st param not 0: x1=#<_xput> y=#<_yput> z=#<_zput>)
(PRINT, 101 open)
M64 P0 (open Holder)
M66 P1 L2 Q0.5 (wait 500ms)
G53 G0 Z[#<_zput>+2] (lift Tool Holder up 2 inches to clear tool)
(PRINT, 101 Close)
M65 P0 (close Tool Holder)
M66 P1 L2 Q0.5 (wait 500ms)
o<putback> else
(PRINT, 101 else)
G53 G0 Z0
o<putback> endif
(PRINT, b4 102b)
(************************************************************)
(** Get New Tool)
(************************************************************)
(if second passed parameter is not 0 then get tool.)
(PRINT, b4 102a)
o<getnew> if [#2 GT 0]
(PRINT, after 102)
G53 G0 X#<_xget> Y#<_yget>
G53 G0 Z[#<_zget>+1.6]
(PRINT, in second param not 0: get x=#<_xget> y=#<_yget> z=#<_zget>)
(PRINT, 102 open)
M64 P0 (Blow Off Tool)
M66 P1 L2 Q0.5 (wait 500ms)
M65 P0
(PRINT, 102 close)
M66 P0 L3 Q0.5
(PRINT, 102 open)
M64 P0 (open Holder)
M66 P1 L2 Q0.5 (wait 500ms)
G53 G0 Z#<_zget> (Grab Tool)
(PRINT, 102 close)
M65 P0 (Close Holder)
M66 P1 L2 Q0.5 (wait 500ms)
G43.1 Z[#<_hget>+2] (load tool length offset)
G53 G0 Y[#<_yget>+1] (go to tool GET Y+1)
o<getnew> else
G49
o<getnew> endif
G53 G0 Z0
;TURN ON SPINDLE HERE
G53 G0 X#5161 Y#5162 ;Move to absolute X and Y stored from 28.1 command
G53 G0 Z#5163
(PRINT, Tool Exit)

o<tool> endsub
(PRINT, Tool Exit1)

M2
Attachments:

Please Log in or Create an account to join the conversation.

More
17 Apr 2014 13:52 - 17 Apr 2014 15:23 #46021 by ArcEye
Misread code - delete

Thats what you get trying to read on a mobile phone :laugh:
Last edit: 17 Apr 2014 15:23 by ArcEye.

Please Log in or Create an account to join the conversation.

More
17 Apr 2014 22:16 #46032 by fodder7
Lol, I understand. In the email from the forum it had a response that I assume was yours Arceye. I didn't understand it but now I do ;) As an update to this problem I downgraded to v2.5.3 and the problem went away. I know that does not necessarily mean that its a bug in v2.6 but I am going to have to stick with 2.5.3 I think. But I would like to report it to the dev team and don't know how.

Please Log in or Create an account to join the conversation.

More
17 Apr 2014 22:30 #46034 by ArcEye

Lol, I understand. In the email from the forum it had a response that I assume was yours Arceye. I didn't understand it but now I do ;)


Thought I had it cracked when I could only see 4 lines at a time and misread which o block I was in :laugh:

Its all here

www.linuxcnc.org/index.php/french/compon...ticle/48-bug-reports

They need the bug to be reproduceable, so best to trim out bits that are hardware reliant, or M code routines they won't have.
Sometimes the problem disappears and that gives a clue.

Will need some clue as to the calling routine too

regards

Please Log in or Create an account to join the conversation.

More
01 Jul 2018 19:49 #113181 by lorenzn
I ran into this error but I'm new to subroutines so I don't know if this is expected when redefining subroutines while the machine is on or a bug.

The error message is:

emc/task/emctask.cc 397: interp_error: 4: duplicate O-word label - already defined in line 3: 'o100 if [ #1 GT 5]'
4: duplicate O-word label - already defined in line 3: 'o100 if [ #1 GT 5]'


To reproduce define the subroutine:
o<test1> sub

o100 if [ #1 GT 5]
    (debug, true)
o100 else
    (debug, false)
o100 endif

o<test1> endsub
M2

o100 starts on line 3.

Now call the subroutine (I am using the MDI tab in Axis UI):

o<test1> call [20]

The message 'true' pops up in the notifications.

Edit test1.ngc and insert an extra blank line so the o100 if statement is on line 4. Save the changes.
o<test1> sub


o100 if [ #1 GT 5]
...

Call the subroutine again:

o<test1> call [20]

The error occurs. I'm using master branch (cloned March 19 2018).

Please Log in or Create an account to join the conversation.

More
02 Jul 2018 16:14 #113242 by andypugh
That sounds wrong, and unexpected.
I wonder if the system is somehow cacheing the old subroutine file?

Does it always error even if you don't edit the file?

Please Log in or Create an account to join the conversation.

More
04 Jul 2018 01:04 #113360 by lorenzn
There is no error if I don't edit the file.

The error will occur once for every change (inserting blank lines before o100). The second time I call the subroutine the error does not occur.

The error also does not occur if I toggle the e-stop and machine power buttons:
- machine is on
- edit file to add blank line to move o100 if line
- toggle e-stop and power
- call subroutine
- no error

Please Log in or Create an account to join the conversation.

More
04 Jul 2018 17:25 #113427 by andypugh
This sounds like a problem with cacheing. I think that the interpreter might load a copy of the subroutine file, and it gets confused if you edit the file while the system is live.

I think this is strange, and incovenient, but probably not a major issue for most installations?

Please Log in or Create an account to join the conversation.

More
04 Jul 2018 17:55 #113431 by lorenzn
I suppose it's something to be aware of. In my case I was making frequent edits to the subroutine and calling it again. Now I know to toggle power or call the subroutine two times ignoring the error on the first call after the edit.

I wonder if this was the cause of the problem with the OP. They don't mention if the file was edited with the machine on. Even simply adding a comment line could trigger this error. The first call would be OK then adding a comment or some other edit could trigger the error on the second call.

Please Log in or Create an account to join the conversation.

More
04 Jul 2018 18:10 #113432 by andypugh
I think it is worth raising a bug tracker for this, it looks like some check is flagging a false positive.
Can you confirm what version of LinuxCNC you are using? The OP says 2.6 but it is an old thread.

Please Log in or Create an account to join the conversation.

Time to create page: 0.099 seconds
Powered by Kunena Forum