Hello Guest it is March 29, 2024, 08:41:29 AM

Author Topic: Implementation of physical buttons  (Read 3124 times)

0 Members and 1 Guest are viewing this topic.

Implementation of physical buttons
« on: June 18, 2018, 12:47:14 PM »
Current setup:
win10pc
Mach4 hobby
ESS with C25s expansion board
C11s BOB
Charter Oak 12z mill with steppers.

Currently I am building a custom control panel with MPG and physical buttons to do:cycle start, feed hold, stop, rewind, enable, toggle coolant, feed override up and feed override down.  I also have a rotary switch to select jog increment and another to select axis to jog.

  I have done no scripting and the last language I used to write a program was DOS. I had kinda figured how to do what I wanted with DoOEMbuttons in mach3, but there were not enough inputs available.  From what I can tell, there is no direct replacement in Mach4, and that I will have to learn PMC and/or programming in Lua.  Is this a correct assessment or did I miss a better way to implement?
Re: Implementation of physical buttons
« Reply #1 on: June 18, 2018, 03:06:38 PM »
Hi,
yes some coding will probably be required. The good news is that probably as few as two or three lines per button is required.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: Implementation of physical buttons
« Reply #2 on: June 18, 2018, 07:30:14 PM »
Hi,
to implement this project you are going to want as many inputs as you can get.

Reading the manual for the C11 does not lead me to believe that pins 2-9 can be repurposed as inputs.
I would recommend the C10, you'll need two of them, fortunately only $23.00 each.
On the C10 you can nominate pins 2-9 as inputs, thus with the two boards you have 26 inputs and 10 outputs
not counting the C11 or C25.


Your C11 or C25 would still occupy port 1 and that would be the board to which you connect your motor drivers
and spindle for instance.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: Implementation of physical buttons
« Reply #3 on: June 18, 2018, 07:40:49 PM »
Hi,
How many positions are your rotary switches?
Rotary switches can absorb a lot of inputs, you can multiplex them to reduce the number but it adds
very significantly to confusion and complication both electronic and software. If you have two four position switches
you would need 8 inputs without multiplexing.

If you have ports 2&3 of the ESS equipped with C10s you will have plenty of inputs ans so can avoid all that complication,
in fact should be fun!

By my count:
CycleStart=1
FeedHold=1
Stop=1
Rewind=1
Enable=1
Toggle Coolant=1
FeedUp=1
FeedDown=1
2 by 4 pos rotary switches=8
MPG=2 (single ended signalling assumed)

For a total of 18 inputs.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: Implementation of physical buttons
« Reply #4 on: June 19, 2018, 10:16:05 AM »
If you are going to use all those inputs anyway I would consider not using selector switches and instead program 4 buttons as Radio buttons. Press 1 latch function 1. Press any other and unlatch what is on and latch the new one. On power up or reset nothing is selected. Use a DRO to indicate which function is active.
Re: Implementation of physical buttons
« Reply #5 on: June 19, 2018, 04:21:30 PM »
I have cnc4pc's c25s expansion board that plugs into ports 1&2 of the ESS.  The c11s is on port 3.  I have the motors and spindle on the c11s on port 3 along with estop and MPG.  I wired all the buttons and switches to pins between the 3 ports and still have open input pins, so I'm sure I will find use for them.  Once I figure out how to use them that is. 

I started checking out the down and dirty Lua cheat sheet, but have not be able to find the functions list in the toolbox area that is referenced in the document.  I am assuming this list will be like the DoOEMbuttons from mach3?

Re: Implementation of physical buttons
« Reply #6 on: June 19, 2018, 06:39:10 PM »
Hi,

Quote
I am assuming this list will be like the DoOEMbuttons from mach3?
No, I don't think so.
Open the screen editor and look at the 'Action' property of some of the buttons, the jog buttons for instance.
If you click on it you will find a drop down list of stock actions. Nice to have a look at but not particularly useful
just at the moment.

You really need to set up input pins with the ESS plugin and then put functions/actions in the SigLib table.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: Implementation of physical buttons
« Reply #7 on: June 20, 2018, 06:07:38 AM »
Hi,
open Configure/Plugins/ESS and on the Pins Config page give the input pin, port1,pin10 for example, used for the button of interest a suitable alias, and maybe an active low status.
While still within the ESS configuration screen open the Input Signals page and scroll down and enable one of the general purpose inputs Input10 say, and attach the pin alias
you have allocated to that button. Hit <apply> so that the changes are save to the .ini file.

You can then enter some code into the SigLib table at the top of the Screen Load script, if you follow this example:

[mc.ISIG_INPUT10]=function(state)
      if (state=1) then
               CycleStart()
       end
end

It may not be clear how this simple statement can effect what you wish.

In Mach3 the program would occasionally, every 25ms or so, interrogate all its input signals to see if any had activated. This is called polling. Its not very efficient, it checks each input in turn whether it needs
it or not and then waits for a long time before it checks it again. Mach4 is much better. Whenever ANY signal, input or output changes state it runs the signal script. It doesn't wait until some sampling time
it acts as soon as a signal changes. If for instance one of Machs internal signals changes, say AXIS0_STOPPED the the signal script will run. We are not interested in this signal so we don't act on it. If however
ISIG_INPUT10 changes we are interested in doing something. This is how Mach goes about it:

It runs the Signal Script  as per usual and the standard script is:
if SigLib[sig] ~= nil then
    SigLib[sig](state);
end

I know....so simple ...how can such a simple three lines do anything useful???? All Mach knows at this point is that signal number <sig> has changed to <state>.
What happens is that Mach looks into the SigLib table, a Lua data structure to see if there is an entry in the table that matches <sig>. In our case there is in the form of ISIG_INPUT10.
Given that the test is affirmative Mach now executes the function associated with that entry and passes the variable <state> to the function. Mach now executes the function if <state>=1,
which in our case is yet another function called CycleStart() which is already in the screen load script.

This is an example of two important principles and concepts in Lua. The first is the table. Lua has ONLY one data structure, the table. The individual elements of the table may be arranged
in numerical order 1,2,3 etc. like we would an array in more familiar computer languages, but they can also be named out of order with positive AND negative arguments OR with STRING
arguments. Thus we could have a table:

MyFictiousTableInLua {
[1]='my first entry'
[2]='my second entry'
[2.345]= 'my third entry but note the real as opposed integer argument, perfectly legal in Lua'
[ARG4]='my fourth entry but with a string argument, again perfectly legal in Lua, even a mixed one like this'
[5] = function('it is also legal to have numbers , strings, functions and even a whole other table as an entry')
}

This is just an example of how flexible tables can be in Lua. As often happens in Lua what appears to be a very simple idea has remarkable flexibility and can
convey properties and possibilities well beyond what the simple idea would indicate.
The second  principle is a 'function as a first class value'. Thus you can see the last entry in my nonsense example table is a function whereas all the previous entries were
numbers or strings. A function can be treated just as another number...very simple and clever and allows Lua to perform great feats of computing despite being such a simple
language.

The upshot is that SigLib, a simple table in Lua, is in fact a table that contains functions, one function for each of the signals that we are interested in. Very clever, simple,
elegant and very lean computationally.

Lua is a real eye opener, I thought NFS had made a mistake when I first started to use it but these deceptively simple ideas mean that Lua is very powerful indeed. I
have very much changed my mind. C/C++ can do just about anything but is tightly typed and you have to manage your own memory. Lua is almost type free and
memory management is automatic such a boon to Mach4
When coding I have this link open pretty much permanently:

https://www.lua.org/manual/5.2/

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: Implementation of physical buttons
« Reply #8 on: June 20, 2018, 12:13:08 PM »
Craig,  Your explanation is very clear, and I am looking forward to trying it out this weekend.  I'm also glad to hear that Lua will manage my memory, I'm getting old enough that I need software to help me remember stuff. :)
Re: Implementation of physical buttons
« Reply #9 on: June 26, 2018, 12:16:42 PM »
would I use this mc.mcAxisEnable(inst,  AxisID, state);  --enable an axis with my 4 position rotary selector switch to change which axis I want to jog with the MPG?