Cancel a macro

[ger21]

There are lots of things that mach3 does that we wouldn't want UCCNC to do.

[Vmax549]

Hi Dan , Teh ATC macro is not as simple as teh test piece of code. The atc is not a simple sliding carrousel. It is basically a 1 armed bandit style tool changer that when parked is tucked in out of teh way.

We ran into teh macro problem when testing out HOW to sec from a sequence. Much to our surprise it when all wrong.

The atc has to operate in a defined sequence of movements to avoid collisions. Each stage of an output defines a movement. Output 5,1 OFF is one directional move of one element. Output 5,1 OFF is the opposite directional move of that element. And there is a detection switch for both limits of travel for that element. There are 14 motion events and 28 detection events per cycle and 2 cycles per tool change. When a cancel is applied ALL outputs HAVE to state in teh same state as when the {ESC} was applied. Then the operator will back the order of events up to a safe position to resume if needed or STOP all together

When we hit {Esc} to see how it would react to a macro cancel we were surprised that everything went wacky and ALL elements tried to move at teh same time because all teh outputs reset themselves. THAT was a BIG surprise as I have NEVER seen a controller do that on stop or esc. DIY or commercial.

Now can I write around that SURE I can but I should not have to. To me this is a safety issue. It would seem that IF teh {ESC} can allow certain things like cancel all motion it SHOULD be able to cancel all output toggling as well. There should be a warning put in teh UCCNC manuals describing what happens on an {ESC} or {Stop} and specifically how to deal with it when programming a function. As it will be required for all macros that make use of outputs.

GERRY , I remember when UCCNC was first getting started up EVERYONE said we want it to work like MACH3 does. Well it is my turn I want this to work like mach3 did.

I am done with MY soapbox session and rant and am returning to normal space

(;-) TP



Like I said it IS what it is and we have to deal with it.

(;-) TP

[cncdrive]

Terry,

The problem is that if it will work like it is in Mach3 then it will likely to become unreliable like macros often are in Mach3.
The issue is that we can't just stop a running code, we could kill (abort) the thread, but as I wrote it can cause unexpected results, because Microsoft is not guaranteing that it will stop the thread and if it will then when it will exactly happen, also they are not guaranteeing that it will not mess something up.
Even on the Abort function description page they describe the function as "it usually stops the thread".
Well, that it usually stops it is not good enough for what we want to do. We would need a function which immediately and always stops it in a controlled manner, but that type of function does not exist unfortunately.

[Vmax549]

Hi Balazs. I understand you do not want to Kill teh macro as per say with {ESC}.

You make teh {ESC} function ignore teh motion codes and make it shut off defined outputs like spindle ,coolant. Can you not make it ignore all other outputs as well??

(;-) TP

[dezsoe]

Can you not make it ignore all other outputs as well??

(;-) TP

Please, DO NOT KILL UCCNC! It is one of the powerful features in UCCNC that if you write a macro well then you can handle a stop condition correctly. If UCCNC ignores all outputs after a stop is pressed, then the possibility of handling the outputs is over.

GERRY , I remember when UCCNC was first getting started up EVERYONE said we want it to work like MACH3 does. Well it is my turn I want this to work like mach3 did.

If UCCNC starts to work like Mach3 then it will be an other program that I'll never use.

[Vmax549]

So exactly what do YOU want to do with teh outputs that requires you to handle EVERY output individually as apposed to simply leaving them as is when teh macro is cancelled with {ESC)?

Could you not simply write a routine at the END of the macro that handles the outputs for you. then when the macro is cancelled and cycles to teh end. It will take care of your need

IF it were THAT easy that is exactly what I would do. BUT UCCNC does not allow that option it insists on toggling ALL teh outputs.

How would it be IF a Gcode program ran all teh macros on startup and YOU had to program a way around that ?? Easy enough to do. How about when stopping a Program it cycled all teh macros all teh way to teh end of teh program before stopping AND you had to program a way around that. Would not be very nice would it. The same with cancelling a macro and have it toogle all teh outputs.

Both sides could be served with a simple Checkbox in Config.

[ ] Do not cycle outputs on Stop_Esc

(;-)TP

[Vmax549]

Please, DO NOT KILL UCCNC! It is one of the powerful features in UCCNC that if you write a macro well then you can handle a stop condition correctly. If UCCNC ignores all outputs after a stop is pressed, then the possibility of handling the outputs is over.

How do you figure that ?? You would simple do the opposite of what you want me to do.
Handle it

You could write teh same exception scripts that you want me to write only in reverse and that puts teh burden on teh minority not teh majority.

(;-) TP

[Vmax549]

If UCCNC starts to work like Mach3 then it will be an other program that I'll never use.

That would be your loss not ours UCCNC already works like Mach3 in many ways. Has from teh beginning. It copied teh look and feel fairly closely. Lot of teh function names are the same and work in about teh same way.

NOW you can even use VB like mach3 did

(;-) TP

[Dan911]

Hi Dan , Teh ATC macro is not as simple as teh test piece of code. The atc is not a simple sliding carrousel. It is basically a 1 armed bandit style tool changer that when parked is tucked in out of teh way.

We ran into teh macro problem when testing out HOW to sec from a sequence. Much to our surprise it when all wrong.

The atc has to operate in a defined sequence of movements to avoid collisions. Each stage of an output defines a movement. Output 5,1 OFF is one directional move of one element. Output 5,1 OFF is the opposite directional move of that element. And there is a detection switch for both limits of travel for that element. There are 14 motion events and 28 detection events per cycle and 2 cycles per tool change. When a cancel is applied ALL outputs HAVE to state in teh same state as when the {ESC} was applied. Then the operator will back the order of events up to a safe position to resume if needed or STOP all together

When we hit {Esc} to see how it would react to a macro cancel we were surprised that everything went wacky and ALL elements tried to move at teh same time because all teh outputs reset themselves. THAT was a BIG surprise as I have NEVER seen a controller do that on stop or esc. DIY or commercial.



Now can I write around that SURE I can but I should not have to. To me this is a safety issue. It would seem that IF teh {ESC} can allow certain things like cancel all motion it SHOULD be able to cancel all output toggling as well. There should be a warning put in teh UCCNC manuals describing what happens on an {ESC} or {Stop} and specifically how to deal with it when programming a function. As it will be required for all macros that make use of outputs.

GERRY , I remember when UCCNC was first getting started up EVERYONE said we want it to work like MACH3 does. Well it is my turn I want this to work like mach3 did.

I am done with MY soapbox session and rant and am returning to normal space

(;-) TP



Like I said it IS what it is and we have to deal with it.

(;-) TP

Hi Terry,
Definitely seems like a complicated macro to write and GOOOOOOD LUCK!!! lol

I must add though, any time writing a macro/plugin it's your responsibility to make safe by utilizing functions available. I think if UCCNC made the changes you suggest there will be other complaints soon to follow.

I don't have much experience with ports/pins since using a UC100, but with my experimenting induced by this thread this simple line with a created bool for each port/pin regardless how many, would set port/pin to it's state before escaped pressed and not change to end of macro.


if(!exec.Ismacrostopped()){exec.Setoutpin(5,16); Set516 = true;}

// end of macro

if (exec.Ismacrostopped())
{
if(Set516 == true) {exec.Setoutpin(5,16);} else {exec.Clroutpin(5,16); return;}
}

Most times when reading your post/thread I learn something new!

Thanks,
Dan

[Vmax549]

Hi Dan. It is actually easier than that. You want teh Esc sequence in front of teh output statement so that it blocks teh execution and cancels at that point. Other wise it WILL cycle one last output assigment passed where you stopped. I tried it AFTER teh function as well but ran into teh one last cycle problem. One woulf THINK that one last output function would not mean anything. BUT IF that one output toggle opened teh gripper and dropped your new $1200 probe face first onto teh table you would quicky learn it could be a serious problem.

That is not saying your version does not work as well I will test it out too to see which way works best.

You also really need to guard any status messages or you will just confuse teh heck out of teh operator when he sees 60 messages go streaming by.

You ALSO have to severely guard all wait LOOPS or you will get stuck in an endless loop and have to shut down teh machine and restart to get out

It took mostly of teh night and most of today to get it all tested and back to where I was at AND 326 lines of code to block it all so they would not cycle and it all stayed put.

I would be willing to BET good money at 100:1 that "NO ONE" would ever know teh difference IF UCCNC simply blocked all outputs on {Esc}; The normal DIY Router Drivers never uses such things.

AND assigned outputs are already handled differenly by teh {ESC} they cycle to the function inactive state which ever way that is as defined in config.

Because up to Now "NO ONE" noticed that it toggles ALL teh unassigned outputs till the end of teh macro.

And for the record Mach3 had this problem at one time long ago and it was fixed by Art. AND being I do not have the source code I don't know HOW he fixed it. But I have a good idea how he did it. Sneeky that one was.

"You" would really LIKE working on an ATC and tool change macro. It is a challenge. There is a 12 tool carousel with a fully articulating arm that not only rotates from side to side but also inverts feeding teh spindle and carousel. When parked it folds up and out of teh way on teh side of teh machine. It is designed to work extremely well with a knee mill and keeps all teh mechanism well out of teh table/work area. With this design you could use it with a chain system and have a 100 tool changer easily.

Another challenge was getting the tool table to work with Slot# assignments. UCCNC cannot do that so you have to figure out a way to do it for it. There is also a GLITCH in teh tool table display at teh moment that BLOCKs me from running an auto update routine to assign slot#s and I cannot see a way around it. And I have tried for weeks now with no success. But I do not give up easily. I will get it working EVEN IF I have to program a NEW TOOL TABLE via a plugin to handle it. But I REALLY do not want to do that. Hopefully the glitch can get fixed soon enough to use it on Dereks ATC#2. Hes has a lot of work backing up and it needs to get online ASAP.

I think he also has it serving him coffee in teh morning when he gets to the shop .

if(exec.Ismacrostopped()){return;} // Blocks teh activation before it happens
exec.Setoutpin(5,2); // if in process let it cycle then teh next output cycle will catch it
exec.Wait(100);

code
code

if(exec.Ismacrostopped()){return;}
exec.Clroutpin(5,2);
exec.Wait(100);

if(exec.Ismacrostopped()){return;} // Bock messages from cycling on ESC
exec.AddStatusmessage( "Test Message")
exec.Wait(100);