run from here does not work on latest 2.5 branch

Hi,

Unlike other controllers, I think all the 'run from here' facility is simply designed for is when you have an 'Oh S**t' moment, press escape and hastily move the overhanging tool that was going to foul the chuck or whatever and then continue.

It does not start from the line you select unless that line is linear move (probably rotary too, never tried that one), and will start at the next line containing a move.

Both from this and its total lack of awareness of previous code, it really does not like re-starting in the middle of subs.

Another thread where someone had real problems with this
www.linuxcnc.org/component/option,com_ku...d,8406/lang,english/

Andy's point about using the same number for all if/endif blocks comes into focus when the next linear move is not within the the block it restarts in and it could be matching the wrong o101 endif

Not sure why you would want to start part way through a toolchange, but if the situation occurs regularly, perhaps skipping the positional move prior to the change, you could have a conditional parameter in the original call that determines start point and leaves your sub as one integral unit.

regards

I think the issue you have has to do with the labels you use for oword statements.

for instance 101.ngc:

O<101> sub (tool change sub)
---^^^^^this needs to match the endsub - it does, fine
...
o<101> if [#5400 eq #9 and #9 ne 0]
---^^^^ this is wrong - you need a new label!

make each if/then/else, while/do etc use distinct labels and retry

-Michael

ps: I'll look wether that is something the interpreter could detect and give an error message

oh. and the other problem I think is - you use M2 to cop out of a subroutine

I suggest upgrading to master and use
(abort, "error message")
to terminate in a subroutine

-m

I upgraded to master, but the abort option does not work so good

example

M66 P3 L3 Q5
O129 if [#5399 EQ -1]
M65 P0
M65 P1
M5
(abort, "Index don't lock")
O129 endif

I check input 3, if input 3 does not come true, then i have to turn off output 0 and output 1 and turn off the spindle.

nothing of that happen, i just got program stopped the abort message appears but all output are still on, and spindle still turning.

but if i write it like this

M66 P3 L3 Q5
O129 if [#5399 EQ -1]
M65 P0
M65 P1
M5
(msg, "Index don't lock")
M2
O129 endif

It does everything including turning off output and the spindle.

Can abort be fixed, or it's OK to use M2??

As for naming all if and endif differently i did that too, but it does not solve the problem, but thanks to ArcEye i now know why the safety movement was skipped and i added a double Z safety movement that's working great, and i have been able to further understand my issue, which i will now try to explain:

The g-code calls on the ATC subroutine more times.

As i explained in my g-code i have

O101 call [....]
G0
G1
O101 call [....]
G0
G1
O101 call [....]
and so on

What i have been able to observe is that if i start the program normally each call is executed in the right way, but when i run from a O101 call that is not the first one something different happens

Is as if the interpreter create a single file with all my calls inside and then it plays it from the beginning until the call i just run from.

What the machine does is execute the first call then execute the second call which i have run from, without executing all the lines in between the calls, instead it should only execute the second call.

What i think is that the interpreter created a file with ALL the calls in it, and each time it plays a portion of it depending on the call, but when you run from here the interpreter does not count the fact that i am starting from a second call in my g-code, it just starts the file that it has created from the very beginning to the end of the call i run from, instead of doing like it does normally to just execute the right portion of it depending on the call.

Dunno if I'm right or wrong, but it seems like this to me.

Hi

I wasn't aware of the (abort, ........) message, Michael has been busy again!
I would like a link to the docs, if any, it's not present in the pull I am using.

You can return from a sub, but given the nested nature of your code, probably not wise in this case.

I can't understand why M5 would not work if followed by (abort, ....). but in the interim a simple sub like:-
would keep everything modular and should prevent the M2 being triggered by any strange 're-start from here' behaviour.

Have to check that abort is not now a reserved name, perhaps <prog_abort> instead?

regards

(abort, message) is in master only and documented here: www.linuxcnc.org/docs/devel/html/gcode/main.html#_calling_files

It is a pseudo-comment and NOT a reserved word.

-Michael

There was a serious bug with M2 being executed in O-word subs.

I fixed this in master this morning and it should show up in v2.5_branch in a few days.

Please retry.

If this doesnt work for you, please narrow down the behaviour so it can be used isolated and with a simulator configuration.

- Michael

It does not work still

If you want to test in a simulation environment you can do it, just connect your keyboard with HAL_input

add some digital IO with num_dio=10

then connect these input

net no-tool-p0 motion.digital-in-00 <=
net have-tool-p1 motion.digital-in-01 <=
net index-in-p3 motion.digital-in-03 <=
net cover-close-p4 motion.digital-in-04 <=
net cover-open-p5 motion.digital-in-05 <=
net spindle-stop-p6 motion.digital-in-06 <=
net ok-button-p8 motion.digital-in-08 <=


to your keyboard buttons, i suggest numbers from 1 to 7

Then you can start 01.ngc in the attached rar, simply play with the numbers on the keyboard and the ATC should go on.

I think that's all you need, let me know if you have problems making it work in simulation.

is it really asking too much to post a *complete configuration* (HAL files, ini, the works)?

Why do you expect developers to reverse-engineer your setup and waste their time?

- Michael

No it's absolutely not asking too much, i'm very sorry it was not my intention to waste your time, i apologize if my last post made it look so.

I've attached the complete configuration.

there is also the udev rule for hal_input to put in /etc/udev/rules.d

also for connect your keyboard with hal_input you need to write in terminal

less /proc/bus/input/devices

Find how your keyboard is called, and write it in the .hal file on this line

loadusr -W hal_input -KRAL KB

instead of KB which is my keyboard name

You need also to change the PROGRAM_PREFIX in .ini but i assume you know that.

When you play Test.ngc press keypad numbers from 1 to 6 repeatedly and you will see what the subroutine does, if you try to start from the second o101 call you should first load tool 3 with T3M6 in MDI, at this point the interpreter should recognize that i already have the tool that i'm asking for and skip ATC all together, but instead it tells me that the tool i have is wrong because it wants to play the first o101 call,
To understand better also play Test2.ngc in which the first part is trimmed, you can play that with tool 3 loaded in the machine and see how it should work if i run from there.
Also if you have no tool (T0M6) and you run from the second o101 call you can see how it goes to take the tool in the first position then put it back immediately, then it goes take the tool in the second position and do the job.

If there is anything more i can do don't hesitate to ask.