Hello! I tried to search this but the search engine for this forum doesn't like me or something. If I am asking an old question, a link will suffice.

I am trying to prohibit the drawbar from releasing the tool when the Disable or Stop button are pressed during a tool change.

   local machEnbld = mc.mcSignalGetState (mc.mcSignalGetHandle (inst, mc.OSIG_MACHINE_ENABLED))
   local eStop = mc.mcSignalGetState (mc.mcSignalGetHandle (inst, mc.ISIG_EMERGENCY))
   if machEnbld == 1 and eStop == 0 then
      -- drawbar release code here
   end

What is worse is if I run that code with the machine Disable button flashing green "Enable" then that code works. However while it is in motion that code does not work. The Disable button pushed in a tool change will make the code execute straight through with none of the moves slowing it down until it reaches the end of the code and then it says the tool has been changed! Of course in the process it just dropped the tool it had on the floor.

Now, the e-stop is a different story. That works. The Feed Hold is fine but the Stop? What is that signal?

During testing my code tonight I kept hitting the Disable and Stop buttons and after a few time it was like the Z axis lost it's position and did a rapid down into the tool carousel from about an inch above it. It was suppose to rapid up to 0 first but just went straight down the moment I hit the Cycle Start MDI. Maybe I was hitting the Cycle Start after a Stop? I don't remember but my recollection was hitting Disable.

If anyone can help it will make me a much happier person!

I also could not find a signal to indicate a stopped state.  However a possible fix is to add code to the stop button to set a register to indicate this - and read it in your code.  Add similar to the start button to reset the register.

For ATC moves, it might make sense to use machine coordinates (G53) and to check at the start of the ATC cycle that the machine has been referenced.  That way zero will always be in the same place!
Code to check if referenced: https://www.machsupport.com/forum/index.php?topic=36295.msg283262#msg283262

I also could not find a signal to indicate a stopped state.  However a possible fix is to add code to the stop button to set a register to indicate this - and read it in your code.  Add similar to the start button to reset the register.

For ATC moves, it might make sense to use machine coordinates (G53) and to check at the start of the ATC cycle that the machine has been referenced.  That way zero will always be in the same place!
Code to check if referenced: https://www.machsupport.com/forum/index.php?topic=36295.msg283262#msg283262

Hey, I forgot I asked this! Thanks for the reply.

I have actually found that 100% of my troubles where in the nesting of my Lua calls. Apparently Lua just sucks and the implementation embedded with Mach4 has some major issues. Case in point, same script but I assigned returned values to a variable and then make the next call and things like that and the scripts all work now.

I am not faulting the Mach people but Lua is the absolutely worst choice in scripting languages. As much as I hate Python I have to admit that it doesn't have troubles with foreign memory access and objects on the stack like Lua does.

So, for anyone following after this, my advice is never nest a function call inside of another, always assign a return value to a variable FIRST before passing it to the next function. Lua's concept of a "Stack" isn't just flawed, it is straight up broken. The return value may not be the thing your were expecting at that point in time because the execution engine hasn't yet made that object available. The only way to guarantee that thing is what you think it is is to assign it to a variable FIRST.

Then Lua is like, "Oooh, you really care what this thing is. Ok, it is here now."

That signal I was looking for never showed up because the object I was passed was empty or never connected to the backend with the data :p

Once I assigned it to a variable, then passed it to the next function, there was my signal!

I can get mad at people and scream and yell, or I can just get my Teknic ClearCore out and never have these issues again

I'd found the same thing - but assumed it was just not supported and everybody but me knew about it!

Despite having lots of problems (lack of type casting being a big one) - it is an easy to write, easy to understand language (even if it trips you up occasionally).  Probably not a bad choice for non-coders?

I do wonder why they didn't go with VB Script & use Visual Studio as the IDE.  VB ticks the easy box but has a proper stack and types - and is more common than Lua.

That said, I'm grateful that it has any kind of scripting interface!  We can always work around the problems.

Si