1.2109 - macro + while(){}

[Robertspark]

I don't know if this is a bug or just (my) bad macro code?

I wrote a macro which has a while (){} statement within it , but when I pressed the reset / e-stop the macro remained running and it did not terminate the macro as I thought it probably would.

I added a work around to the macro to kill the macro in event of a reset / e-stop.

BAD CODE (potential bug):

Code: Select all

if (AS3.GetLED(11))
   {
   exec.Setoutpin( 1, 1);
      while (AS3.GetLED(10) && AS3.GetLED(11))
         {
         Thread.Sleep(50);
         }
      exec.Clroutpin( 1, 1);
   }
return;

WORK AROUND CODE:

Code: Select all

if (AS3.GetLED(11))
   {
   exec.Setoutpin( 1, 1);
      while (AS3.GetLED(10) && AS3.GetLED(11))
         {
         Thread.Sleep(50);
            if (AS3.GetLED(25))
            {
            exec.Clroutpin( 1, 1);
            return;
            }
         }
      exec.Clroutpin( 1, 1);
   }
return;

I've not tried the bad code with any previous development / the stable release to see if the issue is consistent.
thought it may be worth a check if it was a bug or not.

[cncdrive]

Hi Rob,

Why would the e-stop terminate the macro? It does not, you have to take care to terminate it if you want it to terminate on e-stop/reset like how you did.
And we have already talked about this, that stopping a macro while it is running would be programmatically dangerous as it could lead to unpredictable results in Windows programming.
I'm sure this is what causes many of the bugs (unpredictable happenings) in mach3, that they killing macros and codes like that. According to Microsoft programmers should possibly never do that and when I was thought programming in school they taught us the same...

[Robertspark]

Hi Rob,
Why would the e-stop terminate the macro? It does not, you have to take care to terminate it if you want it to terminate on e-stop/reset like how you did.

I obvious through that it probably should, thanks for confirming that it does not, I'll allow for it in my macros in the future.

And we have already talked about this,

I do / did not recollect, but there are now ~13,000 posts on this forum and ~1600 topics / threads so your memory is obviously better than mine, although I do follow about 4 forums on various topics and cnc is not my only forte and uccnc is only a tiny element of my hobbies, not my work.
So I do understand your frustration going over the same things time and again, but understand that the forum users have many interests, of which cnc and more specifically uccnc is but 1 so these topics will come up from time to time, hence its sometimes better to just refer to the previous thread discussing it if you can remember which it was.

I do however sort of remember a discussion about killing macros that was had with I think Terry on the forum so whether or not those posts and threads were part of the his ~500 posts is probably why it did not jump out at me and given those discussions are now rather one sided, it probably did not jump out at me.

..that stopping a macro while it is running would be programmatically dangerous as it could lead to unpredictable results in Windows programming.
I'm sure this is what causes many of the bugs (unpredictable happenings) in mach3, that they killing macros and codes like that. According to Microsoft programmers should possibly never do that and when I was thought programming in school they taught us the same...

Thanks, I did not know, I've never done programming at school, where I grew up they had one room of ~30 PC's for ~500 students + teachers never had them and we never had them at home.... life was simple. I am self taught at programming a hack at best that gets the job done, but not good enough to do it as a job, as I'm sure >90% of uccnc users are.

I do not recollect how mach3 works and did not compare uccnc to mach3, I just had what I perceived as a problem, when I ran a macro with a while(){} statement in it via the MDI, pressed the RESET, and still could not access the MDI, re-set the RESET and still could not access the MDI as the macro had not terminated. My perception was wrong, but I could see a fix for it, I just was not sure if that was the intended way it was to work or not by the macro(s) continuing to run regardless of the RESET / e-stop status.

Thanks for letting me know that is the intended way, I'll work around it and write better code in the future as I now know I need to account for a watch on the RESET possibly where the macro may be autonomously moving or doing something external via I/O (relay) that may be latched in one state even though the RESET / e-stop has been pressed in an attempt to stop all ongoing actions.