Hi guys

I'm trying to incorporate some hard buttons into my machine to take over from GUI buttons.

Is there a general way to execute the "actions" via siglib?  Some of the gui buttons have obvious scripts i can call, others have only these actions.

One example is flood cooling.  The button properties list only "flood toggle".  How can I find the actual command that is triggered by this button? (so that I can copy it into the siglib for my corresponding hard button)

I'm sure this is obvious but it is escaping me

Here's some of mine. PoKeys, but yours could be whatever pin.

----------Mach4 Input 17 PoKeys Pin 17-----
----------Toggle Coolant M8----------------
[mc.ISIG_INPUT17] = function (state)
if (state == 1) then
     local inst = mc.mcGetInstance();
     local sigh = mc.mcSignalGetHandle(inst, mc.OSIG_COOLANTON);
     local sigState = mc.mcSignalGetState(sigh);
     if (sigState == 0) then
         local OSigCool = mc.mcSignalGetHandle (inst,mc.OSIG_COOLANTON)
         mc.mcSignalSetState(OSigCool,1)
         mc.mcCntlSetLastError(inst, "Coolant On")
     else
         local OSigCool = mc.mcSignalGetHandle (inst,mc.OSIG_COOLANTON)
         mc.mcSignalSetState(OSigCool,0)
         mc.mcCntlSetLastError(inst, "Coolant Off")
     end
end
   
end,

----------Mach4 Input 14 PoKeys Pin 14--
----------Toggle Mist M7----------------
[mc.ISIG_INPUT14] = function (state)
if (state == 1) then
     local inst = mc.mcGetInstance();
     local sigh = mc.mcSignalGetHandle(inst, mc.OSIG_MISTON);
     local sigState = mc.mcSignalGetState(sigh);
     if (sigState == 0) then
         local OSigMist = mc.mcSignalGetHandle (inst,mc.OSIG_MISTON)
         mc.mcSignalSetState(OSigMist,1)
         mc.mcCntlSetLastError(inst, "Mist On")
     else
         local OSigMist = mc.mcSignalGetHandle (inst,mc.OSIG_MISTON)
         mc.mcSignalSetState(OSigMist,0)
         mc.mcCntlSetLastError(inst, "Mist Off")
     end
end
   
end,

------------Mach4 Input 8 PoKeys Pin 8----------------
------------Toggle SpinCW-----------------------------
[mc.ISIG_INPUT8] = function (state)
if (state == 1) then
     local inst = mc.mcGetInstance();
     local sigh = mc.mcSignalGetHandle(inst, mc.OSIG_SPINDLEON);
     local sigState = mc.mcSignalGetState(sigh);
     if (sigState == 1) then
         mc.mcSpindleSetDirection(inst, 0);
     else
         SpinCW()
     end
end


Might help!

Tom

That's great!

Thanks, I can't wait to try it.

Hi,

Is there a general way to execute the "actions" via siglib?  Some of the gui buttons have obvious scripts i can call, others have only these actions.

Some Mach elements have an 'Action' and others have a 'Script'.

In general an Action is a bunch of code within Mach4 that performs a specific action. It is not viewable or editable. For example open the screen editor,
select the Events tab, and inspect the actions available as a drop down menu when you select  say the GCodeLoad button, per the attached screenshot.

Other items items, for instance the CycleStart button has a script rather than an action.......although note from the Events tab it could have either or both. If you wish to see
the script the control to the right of the script will cause the script editor to open so you can view and in many cases edit the script.

Thosj has posted some code that he has put into the SigLib table, and it looks like it would work fine.

Note the the signal script triggers and runs whenever one of Machs many hundreds, both internal and external, of signal change state, which could happen many hundreds of times a second.
For this reason it is recommended that you keep the SigLib table very lean and clean, and in this regard I would write the SigLib table entries more like this:

[mc.ISIG_INPUT17]=function(state)
if(state==1) then
     MyBloodyCoolantPumpON()
else
     MyBloodyCoolantPumpOFF()
end
end,
The two functions (MyBloodyCoolantPumpON() and MyBloodyCoolantPumpOFF()) are actually functions in the screen load script. This means that there is minimal code burden
whenever the SigLIb table is called.

Please be assured I never call a spade, just a 'spade' but always a 'Bloody Spade', its a matter of technical pride you understand!

Craig

Ah yes, there is the distinction.  I found a workaround to use these actions by way of the scr commands.  They appear to work well but it feels kinda 'hackey' and not the right way.

Is there a convenient way to have an "include" file or something in the screen script that will pull from a separate lua file of my creation? (for convenience, I'm thinking to modify the actual screen script as little as possible and put my code in one script if at all possible.) 

The process that the screen editor uses with temporary files is a bit buggy for my comfort.

Hi,

I found a workaround to use these actions by way of the scr commands.  They appear to work well but it feels kinda 'hackey' and not the right way.

Correct, I try to avoid scr commands. The correct way is to place an object, like a button, it does not have to be visible, but then you get the options of UpAction,
DownAction, UpScrpit, DownScript, ClikedScript etc.

Is there a convenient way to have an "include" file or something in the screen script that will pull from a separate lua file of my creation?

Yes you can write Lua modules or Lua Panels....I'm not really familiar with them Look up some of Daz-the-Gaz's videos.

I'm thinking to modify the actual screen script as little as possible and put my code in one script if at all possible.

Why?. I modify the screen load script, PLC script and others all the time. That's what they are for, and they work a treat. Take a copy of your preferred screen script,
wx4.set say, give it a unique name like Mywx4.set, and modify the hell out of it. When you update to the latest build the uniquely named .set file will survive the update
unaltered so you can carry on using it.

You are at the very least going to have to edit the SigLib table......so there is no avoiding editing the screen script. It does make sense to have all your edits gathered in one
place, so I'll often put all my own coded functions at the end of the script, but inevitably you will have to make a few edits throughout the screen script which can be a pain
to recall and trace. There is a function, if I recall correctly, which allows you to compare the differences between files and thereby locate any edits in one file compared to the
standard issue .set file.

Craig

Hi,

https://www.machsupport.com/forum/index.php?topic=35007.0

Craig

Hi,
place a toggle button on screen and look at its properties. You'll see that it can be logically connected with an input signal and/or an output signal.
But note also that on the events tab you have the regular collection of scripts and/or actions. Thus the toggle button can be triggered by an external
input and that can in turn trigger an event or action.

Craig

Hi,
as an added bonus you don't actually need an entry in the SigLib table to have an input trigger a toggle button.

Craig