Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: TimGS on May 13, 2015, 10:23:19 AM
-
What is the best way to interface with the jogging features of Mach4?
What is the plan going forward?
The jogging tab on the Mach4 screen looks like it has all of the features just not the facilities to easily tie in external control.
Options:
Make a Lua Panel (Similar to the Joystick Project)
Positives:
User modifiable
Can use images for switches and controls
Negatives:
The current jogging tab will be out of sync with the new display
Make a plugin
Same as previous
How do I keep the current Jogging Display in Sync?
Just trying to implement this in a way that is usable by anyone...
...also trying understand the programing paradigm
-
Simple Jog test panel...
-
you can tye them to inputs, there is a lot of ways to do it via a pluging, lua, modbus. search through google there is some good lua stuff out there its just hard to find the correct stuff.
poppabear would be the person to talk to about it
-
Thank You. I have been in touch with him. I was really hoping the Brian B. would chime in and provide some programmatic insight. I can make it work. The question is how best to hook it up (HW and SW)? Do you need a plug in or macro to calculate the correct movements based upon a momentary switch input or MPG input. There is a jog feature built into the MACH 4 display. Shouldn't there be an easy way to connect electrical inputs to the basic functions of the Jogging Tab?
I will draw some pictures later to explain what I am trying to do. (Hardware wise and Software wise)
The toughest part about this hobby is finding time....between the girlfriend ::)....my house...oh...and work too :o .
I just want some "me" time to play with my cnc toys :'(
...awe who needs sleep ;D
-
Strip down an old usb keyboard, theres plenty of vids on utube on how to do this, then use the keyboard plugin in mach4 to configure. on the stripped down one include the shift lock key to act as an on and off key.
Another way is to use an arduino as an interface between the keys you have and the computer, the arduino has a keyboard library.
I feel a quick video coming on......
DazTheGas
-
daz you could use a num pad with M3 as a pendent using key grabber to set what key does what played with it years ago on a keyboard with a num pad.
since you can use the keyboard plugin and tye it to any input or output it should work as a pendent as well.
you may well be able to do it with a Arduino Leonardo as well through modbus or a plugin
-
on the external case i am building ive got a touchscreen connected to a leonardo which is connected to usb as a keyboard, anything i can put on screen can be programmed through the keyboard plugin to work.
DazTheGas
-
are you going to shear your hard work it would be cool if you did, if you did not that's understandable lua is hard work.
-
i can share everything apart from me chocky buscuits.
I`ll put a very short vid together of it working and how.
DazTheGas
-
thanks man its going to be a big help to everyone your the man
-
Using an old keyboard is an awesome idea but I am doing this for local control at the controller. My controller is connected through an ESS (Ethernet Smooth Stepper) back to the computer. I do not want another USB connection back to the computer. I will send some pictures this weekend as I make more progress.
-
i can share everything apart from me chocky buscuits.
DazTheGas
I just had to gooogle that one .... wasn't sure what I'd find. ;D
https://www.youtube.com/watch?v=-JPLcHKCxEI
I was pleasantly surprised. :D
Thanks Daz,
Russ :)
-
tim you are using the same hardware as daz
-
I am not sure what he is using.
I am using an Ethernet Smooth Stepper (ESS) with a PMDX-125 Breakout Board (BOB) and discrete switches and an MPG for control.
-
Using an old keyboard is an awesome idea but I am doing this for local control at the controller. My controller is connected through an ESS (Ethernet Smooth Stepper) back to the computer. I do not want another USB connection back to the computer. I will send some pictures this weekend as I make more progress.
Everyone seems to be missing the point here about using a usb keyboard, with a key assigned to an input signal anything can be programmed into a function in the PLC script. Worried about wires then use a wireless one, an average board in one of those is about 30mm x 50mm, crossin a couple of wires activates a key, you will have to map which ones before removing the whole keyboard.
DazTheGas
-
yep using a old keyboard saves money and works many different ways
-
I am not dismissing the idea; I like it.
I definitely will add a wireless keyboard/Pendant later when our group figures it out ;D
For now my requirements are for wired, local (switch and MPG) control of the ESS controller. This "should be" simple to do it just has some bugs in it right now.
-
it can be done you just have to get the codes in the correct spot`s that's the really hard part of lua and M4
-
Please excuse my ignorance but I though the keyboard interface only mapped key codes to a limited number of predefined functions. How do I map a key code to an on screen function?
Peter
-
you would have to ask poppabear and Ya Nvr No reading through there post it looks like they have worked it out dazthegas may have as well as far as I can see its using the call for that function, I got probe input working with a button all I did was map a input to it
-
There's a keyboard function?
-
Hey Peter I couldn't find it but somewhere in this forum and/or the yahoo forum there used to be script examples for doing keyboard emulation for Mach4. if ya can't find it anywhere I can copy from my machine but I'm not on the machine right now.
Dave
-
with the new version of M4 key mapping is not working just tried setting a key to a input it would not work last version it worked fine I had input 0 mapped to this key` for probe on, off with that key.
the example is here http://www.machsupport.com/forum/index.php/topic,27129.0.html
-
Thank you! Got to play with that tomorrow! Also, read the entire topic thread.
Thank you!
Pete
-
if you have version 2441 don't bother it wont work
-
But A, it will hopefully get fixed and work again, and B, will work if I stay with an earlier version and C, I'll get to understand how it work(s/ed). Up till now I thought anything added had to be tied to one item on a predetermined list of functions.
Pete
-
Before installing a new version of anything I tend to back up the old one that works. if you still have the previous one then copy the 2 keyboard files over the new ones then its working again.
Not the perfect way but keeps ya going.
DazTheGas
-
yep can you send me a copy i deleted it
-
Unable to PM it so see if this works.
Copy files into plugins directory.
DazTheGas
-
thanks daz its working as it should
-
A member has posted a warning in the bugs thread about his jogging project having a nasty behavior. Apparently if he has a jog button active when MACH4 starts, the axis begins to move continuously and he has to e-stop/disable MACH4 to get the table stropped. I suggested he bring that issue to this thread where solutions are being discussed.
In the case mentioned above, he is apparently going thru an ESS, but it is unclear (to me) exactly how he has things connected.
Based on the topic of this thread, it seems that interfacing thru a popular motion controller should be part of the discussion. In the case of the ESS, however, I think the first step in diagnosis should be to determine if the problem is with the ESS or MACH4.
I have an ESS that was purchased only to test compatibility with my own TCP/Modbus device, and I do not know much about it operationally.
Since I have just completed interfacing an industrial joystick and rotary quadrature encoders to MACH4's jogging facility, I can offer some suggestions.
Probably the most important thing for Pendant developers to realize is that once a MACH4 jog is initiated, it continues until it is expressly terminated. The behavior of the screen buttons is deceiving in that is appears as though MACH JOGS only as long as contact is maintained, but that is not that case.
Like most Windows mouse controls, a 'mouse click' is divided into several parts, most notably the initial 'click' from the downward movement followed by a completely separate event occurring when the mouse button is released. It appears that some folks are only sending a Jog start on contact of their button and expecting the jog to stop when the button is released. That will not happen. You MUST provide a jog STOP when the button is released, otherwise the axis will continue to move.
Initially, I tried actuating the standard MACH screen buttons using input data, but this did not work well at all for me. YMMV, but I abandoned this approach pretty quickly.
To partially speak to the thread title 'What is the best way', I would suggest that any way other than USB is best. There are a number of ways to get data into MACH4 using TCP interfaced devices and while they are somewhat more complicated to get going, once you have the comm established, it is much faster than USB and pretty much bullet proof. The best you can say for USB is that it 'seem to be working at the moment'. USB has a great spec and was a well planned replacement for the old serial interface, but it has been ruined by the veritable land-rush to use it's highway to transport converted RS232 signals instead of producing true native USB interfaces.
-
I have dug into mach4 today in relation to the jogging, you can get bad behaviour from it, but all depends on the code that you implement with it.
if its using the keyboard emulator as I was today, even if the machine is disabled the machine could still jog... but it would be continuous and only by pressing enable then disable or estop could stop the machine. This is where it comes down to the backend of what you put in it. My answer was to map keys to an input signal in a function that would only work if the machine state was enabled, this worked perfect with cycleing between constant and step.
other ideas I have in pipeline is to send an output signal to my touchscreen to enable/disable jogging depending on the machine state.
DazTheGas
-
you just need to find what the code is for pushed do this when not push stop it will go in clicked script
-
have a look at this
http://www.machsupport.com/forum/index.php/topic,27190.0.html
-
There are 'actions' and there are Lua scripts. These are different animals and screen buttons can do either or both.
'Clicked Script' would run Lua code one time when the button was used, and it sees a mouse click as a singular event. This would not work for jogging. There are a bunch of 'actions' defined for use with screen buttons. For example Jog X+ and Jog X off which are in the mouse down and mouse up entries in the standard MACH4 screen jog buttons.
To send a signal based on machine state would require monitoring. A way to do that is with the PLC script which runs continuously. All of my code for the joystick jogging is in the PLC script.
here is a fragment showing a way to monitor the machine condition:
--InTurn Code
EstopIssued = machEnabled;
-- Spindle power bar graph
--local EstopIssued = 0;
if (EstopIssued == 0) then
mc.mcRegSetValue(EstopTOInTurnRegister,1);
if ((scr.GetProperty('tbuttonSPIN','Button State')) ~= '0') then
scr.SetProperty('tbuttonSPIN','Button State','Up');
end
local InTurnSpindleHandle = mc.mcRegGetHandle(inst, "modbus0/InTurnIN12");
mc.mcRegSetValue(InTurnSpindleHandle, 0);
else
mc.mcRegSetValue(EstopTOInTurnRegister,0);
end
-
have a look at this
http://www.machsupport.com/forum/index.php/topic,27190.0.html
This thread is no longer relevant. The problem being discussed was eliminated when enable was added to the buttons.
Buttons can be enabled by any of a long list of conditions.
-
I am not meaning using it for a on screen button yea you set it to idle under machine state to stop a button working when a Gcode is running
its to help work out a code so a button not on screen can be deactivated when a Gcode is running
this is about pendant`s not screen buttons your codes for modbus you can use a key sniffer type of pendant with out using modbus that what a keyboard is button bla,bal being pushed means do this
so what i have done is I have a key on the keyboard that puts the machine in estop what needs to run all the time, and i will have a button on the keyboard that zeros the dro`s i would not wont to nock it when the machine is running it. needs a code to stop the keyboard key working when a Gcode is running.
if there a another way to do it I am all ear`s
-
The purpose of the code fragment is 'showing a way to monitor the machine condition'.
Once the condition is detected, the data can be used in any way you want. In this particular case it was sent to Modbus because the device needing the data was on the Modbus. Obviously, you would just as easily send the data to a MACH output pin, thru any number of devices that have accessible plug-ins, and so on.
The PLC script supplied with MACH already has a lot of examples to study. A great deal of it revolves around enabling and disabling controls, however, there is not a lot in the way of communication with external devices, hence the fragment. My PLC monitors a bunch of stuff and communicates with several external devices. The fragment I posted is related to monitoring the enabled state.
Modbus really makes no difference in LUA scripting other than the registers have a different identifier. Replace 'modbus' with 'gRegs' in the fragment and the data goes to a different place, but the code is the same. There is no mobus specific code in the fragment.
I am not familiar with the keyboard plugin, but presumably it is bi-directional and there is some method of communicating with it. Replace the screen button calls in the fragment with whatever the appropriate commands are for the keyboard plugin.
Likewise, if you want to monitor G-code, you would replace the machine state with the appropriate call to detect G-code execution.
-
I am not meaning using it for a on screen button yea you set it to idle under machine state to stop a button working when a Gcode is running
That's not actually what it does. Mach being enabled does not indicate that it is running G-code. The screen button is just switched off, not enabled or disabled.
If one considers a control as a whole, then the break (disable) can happen anywhere between the input and the resulting action. In my device, the joystick features encoders instead of pots and it communicates over I2C using interrupts, so it is not a good place to try to pull the plug on communications. Therefor the 'break' is done in the MACH PLC.
In other words the data flows in continuously and the PLC simply ignores the data if the joystick is 'disabled'. An Arduino DUE processor is collecting the data and running Modbus, so that device could also 'disable' the joystick. It would need (as an earlier post suggested for a touch screen) a signal from MACH to 'disable' and it could then simply stop sending data. There are a couple of other ways to accomplish a 'disable' and it is up to the developer to decide which is 'best' in a particular application. I'm just throwing some ideas on the table.
so what i have done is I have a key on the keyboard that puts the machine in estop what needs to run all the time, and i will have a button on the keyboard that zeros the dro`s i would not wont to nock it when the machine is running it. needs a code to stop the keyboard key working when a Gcode is running.
if there a another way to do it I am all ear`s
As I described above, you should not restrict your thinking to 'disabling a key', but rather as a signal path that needs to be broken somewhere between the user's finger and the final action taken by the machine.. There are undoubtedly a number of ways to accomplish that goal. If you can describe, in detail, exactly how the data gets from the key to MACH4 and how you plan to collect it inside of MACH, then I can assist.
-
well how about this I needed a code what will run under a type of state
be it a key board key connected to input 0 through the key board plug so when you pouch it, it stop`s the machine running only when the machine is enabled and a Gcode is running
or a key on the keyboard that will zero all axis connected to input 1 through the keyboard plugin having it working only when the machine is enabled and no Gcode is running
the other way is how I have the Estop key done input 3 through the keyboard plugin it is on a key on the keyboard and I have no extra code with it what means it will work anytime the machine is on but it wont enable the machine just disable it I have it set in M4 config under inputs as Estop keyboard at input3 in keyboad plug its Estop, selected key
so there is two types of state code needed, one when enabled only, one where if the machine is enabled and a Gcode is running it wont work, but will work when a Gcode is not running and the machine is enabled
setting a screen button to idle under machine state does stop a screen button from working when a Gcode is running its the simple way of doing it I tested it with the Estop screen button it did not work when a Gcode was running it did when no Gcode was running.
your fragment is not quite the correct fit for this yes the code will have to go in the PLC for different state control of the non screen buttons
this is with a keyboard only nothing else setting a key to a action in the keyboard plug tyed to a input in M4 inputs.
when it does not matter what state the machine is in it does not need any code, unless you needed it to change the state of the machine.
the other blocks will know how to do it they just give hints here and there, daz may well have worked it out I am not 100% sure how I wont to go about it yet so I cant be more clearer than what I have put above
-
the answer is in the Mach4 scripting manual
-
Daniellyall,
You have provided a good description of the process you want to create, so I can speak to that and provide a process for you to follow to create a solution.
Your process makes a good general example as it is a bit complicated due to the number of dependencies. Because of that, you should consider doing a flow chart as a first step and make sure you have all of the combinations accounted for.
In the coding, you will handle the dependencies with nested statements. The code fragment that I posted previously was in response to someone else's post which was quite simple and had no dependencies.
Here is a code fragment that demonstrates the solution you need:
-- ****************** JoyStick Jogging Routine *******************
if JoyStickActive == '1' then
SpeedX, rc = mc.mcRegGetValue(JoyStick_X_RegHandle);
SpeedY, rc = mc.mcRegGetValue(JoyStick_Y_RegHandle);
--ByteZ, rc = mc.mcRegGetValue(JoyStick_Z_RegHandle);
if JoyJogHoldX == '0'then
if SpeedX ~= 0 then
IsJoggingX, rc = mc.mcJogIsJogging(inst,0)
if SpeedX > 0 then
DirectionX = 1;
end
. . . . . AND SO ON
Please keep in mind that this is a fragment and not a program. However it demonstrates one (of several) methods that are applicable to your project. only the 'functions' that begin with 'mc.mc' are specific to MACH4. The rest is typical variables and logic.
The basic process is to first collect the data into variables and then plug those into the logic.
In the example above (which is actual code from my PLC),
'JoyStickActive' is a variable that is set 'true' if the I/O line that carries that signal is high (value of 1 or true).
'JoyJogHoldX' is 'true' if the X axis is on hold (the joystick controls all axis simultaneously, so 'disabling' one axis allows fine positioning of a single axis).
'SpeedX' is a variable that contains the desired jogging speed.
'DirectionX' is self explanatory.
In this fragment, you can see the actual code used to collect the data from MACH. Of particular interest to you would be the variable 'IsJoggingX' and how and where it gets it's value from.
So, you will create your own variables using descriptive names and use the appropriate MACH4 function to fill the variables with the date. Then arrange your nested conditional statements (if this , then do that). Finally, when all of the conditions are met, you perform the action.
-
the answer is in the Mach4 scripting manual
Glad to hear you found your answer.
Hopefully other readers will still benefit from the time I spent here.
-
yep thank whats in the manual is for a external switch not keyboard should of checked before I posted
-
I created a pendant last night from an MPG and discrete switches. It works well, I just have a bug to resolve with the registers that I have defined in Mach4; possible race condition when flipping between Axis and Increment selections and writing the registers.
Once I get the "ok" from ArtSoft, I will post the script on both sights.
The solution requires that the MPG is defined in the ESS plugin config. and lua script code is written that responds to the MPG control signals (inputs) as define (which axis you are controlling and what increment you have selected). The user maps the MPG to the controlled axis based upon control signals (inputs) defined in the signal code.
I believe that the ESS plugin takes care of the MPG counting up and down. I have asked Jeff_Birt/Greg of Warp9 to verify this. ...hey, it works ;D
I will post my script code on both sites and notes as soon as I get the "Ok" from ArtSoft.
-
Tim,
two questions, please;
1) What is a 'race condition'
2) Did you coordinate the MPG actions with the existing jog buttons? i.e. Do the screen jog buttons still function or does the user choose one or the other?
I have, or had, a completed interfacing a joystick jogging setup to MACH4 and it had not occurred to me to make sure it would coexist with the existing jog buttons. Seemed like it would be a simple matter to attend to . . . but ultimately required pretty much a complete rewrite of the joystick part of the code (which is in the PLC).
My device also has three rotary encoders (which is essentially the same interface as an MPG assuming quadrature output) but they are not for jogging and therefor do not interact with the internal jogging functions. For jogging, at least in my case, you must share the same resources with the existing system and that presented a very large challenge.
-
1) When two pieces of code try to change the same variable at about the same time. (I have changed the way I went about tracking the settings and I will test it tonight: simplified and clearer)
2) All of the screen functions still work
a) The Jog Mode can get out of sync if you select a jog mode using the <Jog Mode> button on the screen to neither "Cont" or "Inc". If I push the physical switch, it selects the mode depending on the state of the switch (bi-state "CONT" or "STEP") and the LEDs on the screen update accordingly to match the switch settings. The LED on the switch is mapped to the "STEP" LED on the screen. If the LED on the switch is out the mode is continuous/unknown.
b) The MPG controls the movement
c) The MPG axis is selectable by a 5 position rotary switch (posted somewhere on this site)
i) Each axis can have a separate MPG/Encoder (I have not tried this yet but it is do-able)
d) The Jog Increment is selectable by a 5 position rotary switch (The switch stays in sync with the display because the display tracks the X_Axis setting)
i) Jogging Increment can be set for each axis independently
3) I would like to graphically represent the switches on the display; similar to your joystick application... I just need more time in my day :D
-
One problem I haven't been able to solve is that the <Enable/Disable> button on the screen does not stay in sync with
mc.mcCntlEnable(); call
I have even tried to manually changing the screen. If I map the Input#0 to the button it stays in sync but I do not like that solution.
-
...code (which is in the PLC)...smart. I wonder if a button script can call a function from PLC. I think maybe my looping problems stem from not writing the functions in PLC. I'll try to call PLC function from a button.
Racing conditions ... yah, I noticed that to whereas when a line of Gcode is coded in Lua and mdi executed the rest of your script has completed and you cannot perform conditions on that specific block. It's like the block is released to the interpreter and for got about by Lua which just preceeds to goto the next line of Lua code. For example mc.mcCntlMdiExecute(" whatever block"), code for some condition, wx.wxMessageBox ("Complete") -> Run. Your Gcode is still running but yet the MessageBox immediately pops up. Hence, all these timing loops everyone seems to be doing or the need for mcJogIsJogging, IsStill, etc. I would think these functions would be for deconfliction of resources but I'm noticing the need for them like 'while mc.mcJogIsJogging do some line of logging message until not mcJogIsJogging or vice versa in order to hold mcLua from advancing to the next line of code.
Tim, your out of sync jog type issue with the button vs. MPG ... try this
1. highlight the Jog Inc button in operator edit screen (mine is named 'tbutton8'
2. change the properties value to this:
Text Up = Jog Cont
Text Dn = Jog Step
3. now goto the button's events where we would normally enter script and change to this: (select from predefined actions)
Down Action = Jog Mode Step
Up Action = Jog Mode Continuous
The button is of a toggle type. hence 'ibutton8' vs 'btnLaunchNuclearBomb' naming convention. Think of a DPDT type toggle switch where you would throw the lever to the left for jog continuous, lever in the middle is off, and lever thrown to the right is jog incremental. That is why you are seeing a three cycle rotation on two LED's on a toggle button. Just need to change the action state of the button. Super easy with the predefined actions that are their for us. Worked for me.
-
I may of gotten if backwards... I think to better visually match "your" switch just add a LED in the middle and map it to a 'nor conditional statement' ie
jog cont (led off) --- jog cont Nor jog inc (led on) --- jog inc (led off)
now that would have to be coded, there is not a predefined action for this on a LED. It would have to be wx.Lua scripted I think to create that specific LED.
using screen calls?? output is true if = nor (wow, that almost sounds like an oxymoron)
-
I did some more rigorous testing tonight and
found that the <Cycle Jog Inc> controls the Jog Increment for the A+, A-...Jog buttons and must somehow keep store and not use mc.mcGetJogInc variable even though the display does track it.
When the Mach4 "Jogging" display <Cycle Jog Inc> button is used to control the Jog increment, the "Jogging" Mach display buttons and the "Jogging Inputs" controlled by the physical switches increment based upon the display.
If I use the physical Jog Increment Switch to control the increment, the Mach 4 display shows the correct setting and the "Jogging Inputs" controlled by the physical switches increment accordingly but the "Jogging" Mach display buttons increment according to the previous setting controlled by the Mach4 <Cycle Jog Inc> button. :-\ Bummer Anyone have any ideas ???
The following is code to date:
--Start of Signals
--Set Defaults
--Set Default MPG Axis
local inst = mc.mcGetInstance();
--Should put these values elsewhere in register or machine.ini
mc.mcMpgSetAxis(inst, 0, mc.B_AXIS);-- Default Axis; B_Axis not used my configuration
mc.mcCntlSetLastError(inst, 'MPG Set to Unused Axis');
mc.mcMpgSetAccel(inst, 0, 100); --25 for servos to 100 for steppers
mc.mcMpgSetRate(inst, 0, 100);
mc.mcMpgSetCountsPerDetent(inst, 0, 4);
--Set Default Jog Increment
local JogIncrement = 1.0000; -- Default JogIncrement
mc.mcJogSetInc(inst, mc.X_AXIS, JogIncrement);
mc.mcJogSetInc(inst, mc.Y_AXIS, JogIncrement);
mc.mcJogSetInc(inst, mc.Z_AXIS, JogIncrement);
mc.mcJogSetInc(inst, mc.A_AXIS, JogIncrement);
mc.mcCntlSetLastError(0, 'JogIncrement = '.. tostring(JogIncrement) .. ' for all Axis');
SignalTable = {
[mc.ISIG_INPUT0] = function (on_off)--ESS Port 1 pin 15
local inst = mc.mcGetInstance();
if( on_off==1 ) then
-- On
mc.mcCntlEnable(inst, true);
mc.mcCntlSetLastError(inst, 'Machine Enabled via switch');
else
-- Off
mc.mcCntlEnable(inst, false);
mc.mcCntlSetLastError(inst, 'Machine Disabled via switch');
end
end,
[mc.ISIG_INPUT1] = function (on_off)--ESS Port 2 pin 15
--This works; you can get it out of sync with the display
--if you push the screen <jog mode> [tri-state] button but goes back in sync
--when you push the physical [bi-state] button
local inst = mc.mcGetInstance();
local jogRate
local hsig1 = mc.mcSignalGetHandle(inst, mc.OSIG_JOG_INC)
local hsig2 = mc.mcSignalGetHandle(inst, mc.OSIG_JOG_CONT)
mc.mcJogGetRate(inst, mc.X_AXIS, jogRate);
if( on_off==1 ) then
-- Jog Increment
mc.mcJogSetType(inst, mc.X_AXIS, mc.MC_JOG_TYPE_INC);
mc.mcJogSetType(inst, mc.Y_AXIS, mc.MC_JOG_TYPE_INC);
mc.mcJogSetType(inst, mc.Z_AXIS, mc.MC_JOG_TYPE_INC);
mc.mcJogSetType(inst, mc.A_AXIS, mc.MC_JOG_TYPE_INC);
--Update Jog Display Tab LEDs
mc.mcSignalSetState(hsig1, 1)--Real LED mapped to Jog Inc in MACH 4 Config
mc.mcSignalSetState(hsig2, 0)
else
-- Jog Continuous
mc.mcJogSetType(inst, mc.X_AXIS, mc.MC_JOG_TYPE_VEL,jogRate);
mc.mcJogSetType(inst, mc.Y_AXIS, mc.MC_JOG_TYPE_VEL,jogRate);
mc.mcJogSetType(inst, mc.Z_AXIS, mc.MC_JOG_TYPE_VEL,jogRate);
mc.mcJogSetType(inst, mc.A_AXIS, mc.MC_JOG_TYPE_VEL,jogRate);
--Update Jog Display Tab LEDs
mc.mcSignalSetState(hsig1, 0) --Real LED mapped to Jog Inc in MACH 4 Config
mc.mcSignalSetState(hsig2, 1)
end
end,
--[[
The following inputs are mapped through the Ethernet Smooth Stepper to a rotary switch
that closes one pair of 4 pairs of contacts at a time. The first position has no contacts.
The movement is limited to 5 positions in the following order starting at the CCW most position
"NONE"CW->"INPUT3"CW->"INPUT4"CW->"INPUT5"CW->"INPUT6"CCW->"INPUT5"CCW->"INPUT4"CCW->"INPUT3"CCW->"NONE"
representing MPG Axis Control where NONE=B_AXIS, Input3=X_AXIS, Input4=Y_AXIS, Input5=Z_AXIS
and Input6=A_AXIS
Note 1: I chose B_AXIS as a NONE or MPG OFF because I don't have one and the call requires a non NIL input.
Note 2: The order of processing is important. Signals are processed in order from the top down.
]]--
[mc.ISIG_INPUT3] = function (on_off)--ESS Port 3 pin 2
local inst = mc.mcGetInstance();
local MPGAxisEnabled = mc.mcMpgGetAxis(inst, 0); --Get ID of Last Axis MPG Mapped to
if( on_off==1 ) then
-- X AXIS Enabled
mc.mcMpgSetAxis(inst, 0, mc.X_AXIS);
mc.mcCntlSetLastError(inst, 'Axis = '..tostring(MPGAxisEnabled)..' No Longer Mapped to MPG'); MPGAxisEnabled = mc.mcMpgGetAxis (inst , 0);
MPGAxisEnabled = mc.mcMpgGetAxis (inst , 0);
mc.mcCntlSetLastError(inst, 'MPG Mapped to X Axis = ' .. tostring(MPGAxisEnabled));
else
--MPG Disabled
--Next if Only true during switch transition from "Input3"->"NONE"
--and briefly during transition from "Input3"->"Input4"; Doesn't really matter
mc.mcCntlSetLastError(inst, 'MPG ENABLE X_Axis; Input3 = 0');
if(MPGAxisEnabled == mc.X_AXIS) then
-- Setting to unused B Axis
mc.mcMpgSetAxis(inst, 0, mc.B_AXIS);
mc.mcCntlSetLastError(inst, 'Axis = '..tostring(MPGAxisEnabled)..' No Longer Mapped to MPG'); local Counts = mc.mcMpgGetCountsPerDetent (inst , 0);
MPGAxisEnabled = mc.mcMpgGetAxis (inst , 0);
mc.mcCntlSetLastError(inst, 'MPG Mapped to B Axis = ' .. tostring(MPGAxisEnabled));
mc.mcCntlSetLastError(inst, '...MPG Turned OFF');
end
end
end,
[mc.ISIG_INPUT4] = function (on_off)--ESS Port 3 pin 3
local inst = mc.mcGetInstance();
local MPGAxisEnabled = mc.mcMpgGetAxis(inst, 0); --Get ID of Last Axis MPG Mapped to
if( on_off==1 ) then
-- Y AXIS Enabled
mc.mcMpgSetAxis(inst, 0, mc.Y_AXIS);
mc.mcCntlSetLastError(inst, 'Axis = '..tostring(MPGAxisEnabled)..' No Longer Mapped to MPG'); local Counts = mc.mcMpgGetCountsPerDetent (inst , 0);
MPGAxisEnabled = mc.mcMpgGetAxis (inst , 0);
mc.mcCntlSetLastError(inst, 'MPG Set to Y Axis = ' .. tostring(MPGAxisEnabled));
else
-- No Need to do anything
mc.mcCntlSetLastError(inst, 'MPG ENABLE Y_Axis; Input4 = 0');
end
end,
[mc.ISIG_INPUT5] = function (on_off)--ESS Port 3 pin 4
local inst = mc.mcGetInstance();
local MPGAxisEnabled = mc.mcMpgGetAxis(inst, 0); --Get ID of Last Axis Mapped to MPG
if( on_off==1 ) then
-- Z AXIS Enabled
mc.mcMpgSetAxis(inst, 0, mc.Z_AXIS);
mc.mcCntlSetLastError(inst, 'Axis = '..tostring(MPGAxisEnabled)..' No Longer Mapped to MPG');
MPGAxisEnabled = mc.mcMpgGetAxis (inst, 0);
mc.mcCntlSetLastError(inst, 'MPG Mapped to Z Axis = ' .. tostring(MPGAxisEnabled));
else
-- No Need to do anything
mc.mcCntlSetLastError(inst, 'Z_Axis; Input5 = 0');
end
end,
[mc.ISIG_INPUT6] = function (on_off)--ESS Port 3 pin 5
local inst = mc.mcGetInstance();
local MPGAxisEnabled = mc.mcMpgGetAxis(inst, 0); --Get ID of Last Axis Mapped to MPG
if( on_off==1 ) then
-- A AXIS Enabled
mc.mcMpgSetAxis(inst, 0, mc.A_AXIS);
mc.mcCntlSetLastError(inst, 'Axis = '..tostring(MPGAxisEnabled)..' No Longer Mapped to MPG');
MPGAxisEnabled = mc.mcMpgGetAxis (inst , 0);
mc.mcCntlSetLastError(inst, 'MPG Set to A Axis = ' .. tostring(MPGAxisEnabled));
else
-- No Need to do anything
mc.mcCntlSetLastError(inst, 'A_Axis; Input6 = 0');
end
end,
--[[
The following inputs are mapped through the Ethernet Smooth Stepper to a rotary switch that closes
one pair of 4 pairs of contacts at a time. The first position has no contacts. The movement is
limited to 5 positions in the following order starting at the CCW most position
"NONE"CW->"INPUT7"CW->"INPUT8"CW->"INPUT9"CW->"INPUT10"CCW->"INPUT9"CCW->"INPUT8"CCW->"INPUT7"CCW->"NONE"
representing Increments NONE=1.0, Input7=0.1, Input8=0.01, Input9=.001 and Input10=.0001
Note: The order of processing is important. Signals are processed in order from the top down.]]--
[mc.ISIG_INPUT7] = function (on_off)--ESS Port 3 pin 6
local inst = mc.mcGetInstance();
if( on_off==1 ) then
mc.mcCntlSetLastError(0, 'JogIncrement was = '.. tostring(JogIncrement));
JogIncrement = 0.1;
mc.mcJogSetInc(inst, mc.X_AXIS, JogIncrement);
--Why use the X AXIS? Because it matches the screen
--Mach4 Display Jog Tab INC number seems to track X_Axis Increment Setting
--Note Each axis jog increment can be set independently
mc.mcJogSetInc(inst, mc.Y_AXIS, JogIncrement);
mc.mcJogSetInc(inst, mc.Z_AXIS, JogIncrement);
mc.mcJogSetInc(inst, mc.A_AXIS, JogIncrement);
JogIncrement = mc.mcJogGetInc(inst, mc.X_AXIS);
mc.mcCntlSetLastError(0, 'JogIncrement is now = '.. tostring(JogIncrement));
else
mc.mcCntlSetLastError(inst, 'IncDot1; Input10 = 0');
-- JogIncrement Set to 1.0000
--Next if Only true during switch transition from "Input7"->"NONE"
--and briefly between transition from "Input7"CW->"Input8"
if(JogIncrement == 0.1)then
mc.mcCntlSetLastError(0, 'JogIncrement was = '.. tostring(JogIncrement));
JogIncrement = 1.0000;
mc.mcJogSetInc(inst, mc.X_AXIS, JogIncrement);
mc.mcJogSetInc(inst, mc.Y_AXIS, JogIncrement);
mc.mcJogSetInc(inst, mc.Z_AXIS, JogIncrement);
mc.mcJogSetInc(inst, mc.A_AXIS, JogIncrement);
mc.mcCntlSetLastError(0, 'JogIncrement is now = '.. tostring(JogIncrement));
end
end
end,
[mc.ISIG_INPUT8] = function (on_off)--ESS Port 3 pin 7
local inst = mc.mcGetInstance();
if( on_off==1 ) then
mc.mcCntlSetLastError(0, 'JogIncrement was = '.. tostring(JogIncrement));
JogIncrement = 0.01;
mc.mcJogSetInc(inst, mc.X_AXIS, JogIncrement);
--M4 Display Jog Tab INC number seems to track X_Axis Increment Setting
--Note Each axis jog increment can be set independently
mc.mcJogSetInc(inst, mc.Y_AXIS, JogIncrement);
mc.mcJogSetInc(inst, mc.Z_AXIS, JogIncrement);
mc.mcJogSetInc(inst, mc.A_AXIS, JogIncrement);
mc.mcCntlSetLastError(0, 'JogIncrement is now = '.. tostring(JogIncrement));
else
-- No Need to do anything
mc.mcCntlSetLastError(inst, 'IncDot01; Input8 = 0');
end
end,
[mc.ISIG_INPUT9] = function (on_off)--ESS Port 3 pin 8
local inst = mc.mcGetInstance();
if( on_off==1 ) then
mc.mcCntlSetLastError(0, 'JogIncrement was = '.. tostring(JogIncrement));
JogIncrement = 0.001;
mc.mcJogSetInc(inst, mc.X_AXIS, JogIncrement);
--M4 Display Jog Tab INC number seems to track X_Axis Increment Setting
--Note Each axis jog increment can be set independently
mc.mcJogSetInc(inst, mc.Y_AXIS, JogIncrement);
mc.mcJogSetInc(inst, mc.Z_AXIS, JogIncrement);
mc.mcJogSetInc(inst, mc.A_AXIS, JogIncrement);
mc.mcCntlSetLastError(0, 'JogIncrement is now = '.. tostring(JogIncrement));
else
-- No Need to do anything
mc.mcCntlSetLastError(inst, 'IncDot001; Input9 = 0');
end
end,
[mc.ISIG_INPUT10] = function (on_off)--ESS Port 3 pin 9
local inst = mc.mcGetInstance();
if( on_off==1 ) then
mc.mcCntlSetLastError(0, 'JogIncrement was = '.. tostring(JogIncrement));
JogIncrement = 0.0001;
mc.mcJogSetInc(inst, mc.X_AXIS, JogIncrement);
--Display INC number seems to track X_Axis setting though INC setting can be set for each Axis
mc.mcJogSetInc(inst, mc.Y_AXIS, JogIncrement);
mc.mcJogSetInc(inst, mc.Z_AXIS, JogIncrement);
mc.mcJogSetInc(inst, mc.A_AXIS, JogIncrement);
mc.mcCntlSetLastError(0, 'JogIncrement = '.. tostring(JogIncrement));
else
-- No Need to do anything
mc.mcCntlSetLastError(inst, 'IncDot0001; Input10 = 0');
end
end
}
--I left off the Signal Table, too long for the posting
-
I reloaded tonight a cleared my <Enable/Disable> switch not updating the state of the Mach 4 Display <Enable/Disable> button. The Mach 4 Display <Enable/Disable> button tracks the switch and both the switch and the Mach 4 Display <Enable/Disable> button control the Enabled indicator (LED). Since the switch is a latching type, if I use the Mach 4 Display <Enable/Disable> button to control the Machine Enabled state, one push of the button changes nothing and resynchronizes both.
-
Now that took some time! Congrats Tim. You are almost there! Best guess to deconflict actions....
Event signals are mapped to a table reference of functions by input name in the PLC that execute would GUI type scr. calls to change the property values of that button/display to reflect your input. Considering your GUI environment matches your physical hardware binary/latching/electrical characteristics and vice versa.
GUI actions are mapped to executable functions within the PLC. Not hardware actions to GUI or GUI to hardware. The PLC is your interface.
That may take care of some syncing issues but the real issue as Simpson36 states is resolution of resource conflict. You may be using inputs from both
the MPG and the GUI to the exact same memory space resulting in syncing issues again, latency, or worse freeze-up. But shoot, I'm just a newbie trying to code auto tool zero without using G31. You guys are on like expert level.
-
"If I use the physical Jog Increment Switch to control the increment, the Mach 4 display shows the correct setting and the "Jogging Inputs" controlled by the physical switches increment accordingly but the "Jogging" Mach display buttons increment according to the previous setting controlled by the Mach4 <Cycle Jog Inc> button. Undecided Bummer Anyone have any ideas "
My joystick uses only Jog functions and not MPG functions, so there is probably no parallel between our interfaces. My challenges were in keeping the environment separated between the screen jogging buttons and the joystick. For example the joystick would stop jogging movement if it was centered (not calling for movement) and this would also shut off the button jogging. The joystick changes the jog rate, so it was always left at zero, which is appropriate for the stick, but then the jog buttons would not work. And so on, and so on . . .
MPG is, at least in part, a separate environment, so there is less 'racing'.
Speculation on your issues; The on-screen Jog increment button and DRO seem to be reporting the current system setting, however, a single jog increment setting would logically be either a separate, undocumented variable, or it sets each axis to the same jog increment. Each axis can have its own setting, so there is going to be a disconnect between the single button and the potential multiple rates. For example, if all axis are not at the same setting, and the on-screen single button/DRO can only display one setting, which axis is it reporting?
As far as I know, there is no function to set ALL axis at once, so you might try setting ALL axis one at a time to the same inc, including your unused axis B and C. Theoretically, this would resolve any confusion in the reading of the current inc by the system 'action' Toggle Inc (or whatever it is called).
Whatever the behavior is, it would likely also apply to jog rate, or any other 'one button, multiple settings' condition.
The odd enable/disable behavior is probably being caused by errors in the original PLC code provided by Newfangled Solutions.
Since I am not using the MPG functions, this is about all the help I can offer.
Good luck with your project and thanks for sharing!
-
when you are testing in the screen have the log running it shows what happening to what ever it is you are doing its one way to debug you can have something run fine in editor but not do anything on screen if nothing shows up on the log nothing is getting through or if something is coming up on the history and its a bad thing the problem can show up in the logging.
also if you have values set in the regfile and you don't think they are working get popabears, DebugVarValueTest or use this in the screen load script
function GetRegister(regname)
local inst = mc.mcGetInstance()
local hreg = mc.mcRegGetHandle(inst, string.format("iRegs0/%s", regname))
return mc.mcRegGetValueString(hreg)
end
and have a button on screen with this in it you just change "Test1" to your reg name it works fine to test any reg you have added to the regfile
regval = GetRegister("Test1")
wx.wxMessageBox(regval)
-
- or -
use the built in register diagnostics window in which you can view . . and change . . any register . . . . in real time . . . ;)
-
I am going to put off using registers for the moment. The code that I posted does not use them.
The <Enable/Disable> Button on the Mach 4 Screen and the Physical <Enable/Disable> Switch/LED work as expected and work just fine.
Thank You ALL
20,000 Axes...I will look into the PLC...that sounds like a viable lead.
The goal is to keep the my Jogging/MPG/switch settings in sync with the existing display for the most part. SW can't move a switch :D ...without a firmware interface. What I did not want was to create a situation where I thought that a control was set for one setting and find out it was set for another...very dangerous. (e.g. Intending to move .01 inches and the actual setting was 1 inch...ouch)
After I get the controls working it would be cool to make my own tab with visual controls that look like the HW controls.
Daniellyall and Simpson36 ... I will look deeper into the debug capabilities....currently just using entries into the history log.
-
Tim, if you are still having syncing problems look at the mc.Motion functions in Mach4.api for direct control over the motion controller ie. mc.mcMotionSync(inst).
Just a thought. Haven't played with it yet.
-josh
-
Thank You for your help... I never looked at that API...it was worth looking at...
The sync problem is between my <1.0, 0.1, 0.01, 0.001, 0.0001> Jog Cycle Inc switch and the Mach 4 Jog Display <Jog Cycle Inc> button; not the position of a motor.
-
Tim,
I'm sure I would get arguments over this statement, but Lua is a dream compared to MACH3's implementation of VB script.
To resolve your jog increment issue, a good approach would be to use the Lua editor to change all of the axis increments to say 1 and then then change them one at a time while watching the On Screen Increment dro (assuming it is real time) and you will then know what is being read.
This method will answer an important question for you and also give you a tiny taste of what working with Lua is like. The editor has step by step debugging so you can cut and paste the 'Set' functions 6 times and then just change the axis numbers and step down thru one at a time.
Notes: choose 'debug' from the drop down and step thru using the F11 key. Remember to 'stop debugging' before you try to edit again.
The Lua editor will give you a rather vague error message if you try to do the debugging without first saving the file. There is some trick (you can search it out if you are curious) that you can add to the bottom of the script that tells Lua that the script you want to run is actually IN the editor and (as if it should not already know that) and then it will run the script. However, simply saving the file first accomplished the same thing and ALSO protects you against the Lua editor locking up and loosing the script . . . because it was never saved. And the Lua editor locks up . . a lot . . . . in my opinion
-
if (mc.mcInEditor() == 1) then
DebugVarValueTest();--- name of file you are running. as in I got this of a file named, function DebugVarValueTest() so you put in DebugVarValueTest()
end
also if you are ruining a script test and have the screen out of editor use the logging as you will see what can happen when you push a screen button compered to your switch you have added it may help pin down any problems.
you can go in to the built in register diagnostics window to see if your reg are and if they have a var to see if they change, if unsure if you can call them use what I added that just to test calling regs when you get to it
-
Looks like the <Jog X +> buttons on the Mach4 Screen us different code than the <Jog X+> switch input:
Mach4 Jog Display <Jog X+>
2015-05-29 19:07:51.458 - API: mcJogIncStart() called. Axis 0, inc = 0.100000
2015-05-29 19:07:51.458 - Attempt transition from "Idle" on event "Jog" Axis.cpp:509
2015-05-29 19:07:51.458 - S_IDLE_on_exit
2015-05-29 19:07:51.458 - MACH_STATE_start_jogging
2015-05-29 19:07:51.458 - S_JOGGING_on_entry
2015-05-29 19:07:51.726 - Requesting a stopped report for axis 0 motors. Controller::CyclePlanner:1352
2015-05-29 19:07:51.726 - Requesting a stopped report for motor 0.
2015-05-29 19:07:51.726 - ESS: Mach requested MSG_REPORT_MOTOR_STOP Motor 0
2015-05-29 19:07:51.953 - ESS: Motor 0 Still
2015-05-29 19:07:51.953 - All motors marked as still.
2015-05-29 19:07:51.953 - Attempt transition from "Jogging" on event "Stop Jog" Controller.cpp:1074
2015-05-29 19:07:51.953 - S_JOGGING_on_exit
2015-05-29 19:07:51.953 - MACH_STATE_stop_jogging
2015-05-29 19:07:51.953 - S_IDLE_on_entry
<Jog X+> Switch Input
2015-05-29 19:06:57.034 - Signal id 169, (Jog X+), changed from LOW to HIGH.
2015-05-29 19:06:57.034 - Attempt transition from "Idle" on event "Jog" Axis.cpp:509
2015-05-29 19:06:57.034 - S_IDLE_on_exit
2015-05-29 19:06:57.034 - MACH_STATE_start_jogging
2015-05-29 19:06:57.034 - S_JOGGING_on_entry
2015-05-29 19:06:57.084 - Requesting a stopped report for axis 0 motors. Controller::CyclePlanner:1352
2015-05-29 19:06:57.084 - Requesting a stopped report for motor 0.
2015-05-29 19:06:57.084 - ESS: Mach requested MSG_REPORT_MOTOR_STOP Motor 0
2015-05-29 19:06:57.261 - Signal id 169, (Jog X+), changed from HIGH to LOW.
2015-05-29 19:06:57.286 - ESS: Motor 0 Still
2015-05-29 19:06:57.286 - All motors marked as still.
2015-05-29 19:06:57.286 - Attempt transition from "Jogging" on event "Stop Jog" Controller.cpp:1074
2015-05-29 19:06:57.286 - S_JOGGING_on_exit
2015-05-29 19:06:57.286 - MACH_STATE_stop_jogging
2015-05-29 19:06:57.286 - S_IDLE_on_entry
-
yah, Lua is an extension of C++ and the I'd bet you the core is written in C++. Those functions your are looking at are from the the core in C++. Even though we may still apply those parameters we do not know how they are implemented. That was Simpson36's point when he asked for open code or if we already have it...then, where is it? we can us MC_JOG or something like that..it is given to us in the api. Pappabear also references C++ parameters to pass to functions in his posts.
Basically, all I am saying is the core is written in C++ and we are give Lua to interface with the core as to protect it from corruption and counterfeiting. Simpson36 is right...and Daniel is right...both statements have a specific application. It just depends on your requirement. Simpson36 is leading you in a good direction....but, you have to find the answer. I mean he doesn't know exactly your specific requirement / hardward specs / interface/ etc...Daniel is giving you straight up code to fit a certain situation. Does that situation apply? I don't know. But it is two different perspectives. I really appreciate the different views that are given and your initiative on just tackling it. TAKE MACH 4 FOR a RIDE. Don't let Mach 4 take you for a ride. Thank you all for your contributions and time. I think this is wonderful and is a knowledge base worth preserving.
-
yer I only post on what I have learnt from lots of people to many to name just trying to give back still in the weeds most of the time, what I post is in here some wear most of the time from Craig or Scott and the others, its hard to rember where some answers are to to link back to for credit
-
yah, Lua is an extension of C++ and the I'd bet you the core is written in C++.
Lua is written in C per its publisher. I find it to be very similar to C in structure and function although the syntax has a dash of this and a dollop of that for whatever reason. Lua is designed to be an embedded scripting language. That is the singular fundamental difference.
The flavor of VB script used in MACH3 is the worst language I have ever used. Just hideous. However, it does serve to make the contrast with Lua all that much greater.
That was Simpson36's point when he asked for open code or if we already have it...then, where is it?
Just to clarify; what I was asking about was access to the source code for the screen only, not the core. The screen is a separate entity from MAHC4 core and is written in C and/or Lua or some combination thereof. The screen editor certainly appears to be wx.Lua and MACH4 comes with an entirely separate sample wx.Lua screen. However, it is rather Spartan and is not editable, so I really don't see the point in providing it. Without the source code, it is literally useless. Providing source code examples in the embedded scripting language is hardly an outrageous request. The product already comes with examples of several Lua scripts for common tasks as well as a rather complex widget with its own pop-up screen.
I started working with the editable GUI screen to add some attractive and ergonomic controls, but soon gave up on that effort due to the developer's effectively refusing to add tools or fix problems. The bottom line is that, by their own admission, the screen is not a priority for the developers.
The solution is to write new screens from scratch and thereby not be constrained by whatever few tools and choices the developer's think necessary. As an interim step, integrating widgets into the screen gets past some of the MACH induced restrictions, so I am no longer interested in the source code for the screens or pursuing tools and bug fixes for use with the current screens.
-
Yes! For example...how would I write code for an LED where there is no way to put my code in to change the state of the LED. The only options are the ones provided from the drop down menu. Don't get wrong. I think it is a great feature provided by NFS. I just want an LED to change state based on my requirement in Mach 4.
Nevermind. I answered my own question I think.
1. I would code for a condition and set state to true or false and return the state to a temp register.
2. Use the above script to emulate an IO device and us mc.IOfunctions to map to it and point to the temp register as it's own register
3. Then assign an output to the emulated IO device.
that could be a pain just to get an LED to blink based on my condition
-
The only options are the ones provided from the drop down menu.
If you are talking about adding an LED to the MACH4 screen, and you want to have a script behind it, one solution is to use a bitmapped button in place of the LED. You can add far better looking image of an indicator light than the horrible round LED and you can script the behavior.
You can learn more about this technique in a thread about 'makin it purdy' where you will find actual code examples.
The pre-defined choices in the MACH4 screen editor are certainly adequate for the vast majority of user needs, so please do jump in there and experiment. The 'checkbox programming' process makes good sense as a method by which non-programmers can quickly and easily make their own screen mods.
There are many more parameters available for screen items (buttons. led, etc) than are made available in the pre-defined list provided in the MACH4 screen editor. If you need a parameter that the Mach4 editor does not have a checkbox for, or a graphics function is partially or completely broken, then it becomes a roadblock and consequently a frustration.
Despite the restrictions, making a custom screen set, whether you are adding one LED or an extensive set of interactive controls, is far easier in MACH4 than in MACH3. The speed and capabilities of the MACH4 screens far exceed anything available in MACH3.
-
Yah, I do enjoy how Mach 4 is layed out and the abilities the NFS gives up to make our own screen sets. Was playing with the screen tree manager today and a blank screen set. Full screen tollbooth display with Lua panel overlays for data information. Good point about the bitmap button! While playing around I found myself thanking Mr. Barker for including those pre defined actions in the drop down menu 99% of the time. It's just that 1%...haha. The lua panel, is open source code to change GUI things. But nevertheless I'm lovin Mach 4 and Lua. Thanx!
-
Status:
I have created a test display and code to flip the images... If you copy it and try it you may need to update the PATH to the images
Attached is the window test display code... too big to post.
I have the signal code and now test display code
Next question...How do I get it into Mach4? ...then How to tie the Test Display to the signal code?
...Learning more every day... :D
-
Sorry about the confusion using the word "Stop" for the MPG. This display is for testing the display of the three states of the MPG (CCW, NOT MOVING and CW) as well as testing the display of the other two switches.
Does this make more sense?
-
Next question...How do I get it into Mach4?
Very nicely done.
When you say 'into' Mach4, are you seeking to add your wizard to a Mach Screen, or connect it to the Jogging system?
-
First I would like to connect it to the jogging system. I was able connect switches and an MPG to the jogging system via a signal script. Now I have created a display to display the switch positions. Now I would like to tie it all together....When I rotate the switch I want to see it change the screen and the Mach4 settings.
The code is set up as a standalone frame (Wizard Like)...but I can just put the panels I created on an "Operations" tab or my own "Display" tab. I just don't know how/where to put the code.
....sorry....work all day...play with Mach4 late into the night. Maybe I should just get some sleep ;) ... but I am on a role :D
-
Tim,
Add a Lua Panel.
Open the scripting choice for the panel (second 'page' of parameters with tiny icon that looks like a page)
The editor will open.
Copy your code into the editor and save.
Save screen - exit MACH4 and restart.
Your wizard should be in the panel . . . although is does not size down, so you'll need a big panel . . :)
You might consider leaving it as a moveable window. That way it will always be available.
-
Thank You for your help... I can kind of visualize this...
I will try it tonight after work. I don't have Mach at work so it will have to wait until I get home to try this....(Good thing I... :D ...I should be working... I can only do quick email replies to gather info and answer questions)
I also have a 5k race tonight so it will be about 7ish before I can try it. When you sit on your butt all day you have to do something to unflatten it ;D
-
I created a panel and added code....now I have a problem where I am not receiving events or generating them beyond the panel "wx.wxEVT_COMMAND_RADIOBUTTON_SELECTED"
...baby steps
-
SMurphy (aka Steve) You tackled this problem once before, I believe. I added a tab, inserted a Lua Panel and added my code. I click on the radio buttons and they move but nothing else happens. Turned on logging and see no messages being generated ??? Do you have any ideas?
-
Still stuck ...Can't receive events ??? ??? ???
-
Look at the "Joy Stick" example, it has an embedded wxLua Panel that throws events and you can get an idea how to do them.
Scott
-
The joystick example uses wx.EVT_SIZE, wx.wxEVT_PAINT and wx.wxEVT_TIMER. It seems radio buttons events or mouse events seemed to be blocked.
I posted my code on page 7 of this discussion....I don't see where I have gone wrong.
The radio buttons move but I do not catch/detect the radio button events
panel:Connect(RADIOBTN1_ID, wx.wxEVT_COMMAND_RADIOBUTTON_SELECTED,
function(event)
local Selected = rbtns1:GetValue();
if Selected then
frame:SetStatusText("MPG OFF");
MPGSwitchPosition = 1;
local dc = wx.wxPaintDC(BitMapPanel1);
dc:DrawBitmap (MPGSwitchBMPs[MPGSwitchPosition], 0,0, true);
dc:delete ();
panel:Refresh();
end
-
Everything works when it is in its own frame (Like when in a wizard). Which I might eventually do but I would like to know how to add buttons and code to a Lua Panel too. ;D
-
Your radio events are getting called, put a wx.wxMessageBox("my message"); under your event function.
when ever you change to that button (i.e. it was un-chechecked, now it is checked) the message will fire.
Your Paint events are being called in the Stand Alone, but..... they are not being called in the Panel version.........
But....... the "Jog" examples panels paint even DOES work.......... so........... go figure.........
Probably see if Steve can figure out why your paints are not firing.
Scott
-
I will try to put a wx.wxMessageBox("my message"); under myevent function tonight...just in case I have other problems.
If it is just a paint issue, that gets me closer; maybe take a closer look at the "jog" code to see if I made a mistake connecting to wx.wxEVT_PAINT. I will also see about how to monitor the windows message handler, that might help.
Once working this code will open the door for some interesting screens ;D.
Thank You for your help!!!!!
-
I FOUND THE PROBLEM ;D ... stay tuned
-
This code works....
1) Add a LUA Panel
2) Add code to the script of the LUA Panel
Thank You Poppa Bear... I used the dialog to find where the code was failing. I was so convinced that I wasn't receiving the events because I had put in a statement to watch for the button switching events. What I did not know was that the statement " frame:SetStatusText("MPG OFF");" was causing and error and the code would bail out right there and skip the change in the switch position and everything after that; restarting the loop when it hit the bottom of the code! That statement works as long as there is a frame to report to.
Now I will add the controls to Mach4 Thank You
-
Another trick you can do, especially if your wanting to watch more than one thing or message.
Pipe your data to a Register, and then use the diagnostics window which is live time, and you can
watch several at once.
Scott
-
I will have to learn how to do that soon ;D
Thank YOU!!!!
-
Tim,
How'd you get it to stick to the panel IN mach4? I figured out the whole wizards application and standalone frames for wx.Widgets from examples in the toolbox (thanx poppabear). Care to help an understudy out?
-
if you have a look at what poppabear did it will show you
-
Very impressive, found a bit in that code that has stumped me for a bit... Cheers
DazTheGas
-
Dude! are we blaming the democrats or the republicans? hehe
Hi Tim--
I thing poppabear is referencing the read/write/save register functions and using the diagnostics register window to view "real time" updates. (so, I actually have the logging window open on play and the register diagnostics open. No kidding, m4 updates that sh17 FAST! I was impressed. That was how I know my script/function call was working.)
-
na the torys
-
I thought you were a Kiwi dan? or an aussie?
-
Screwie Louie....
Reference the attached image.
1. Operator>Edit Screen
2. Expand Default
3. Select MaintTabs (or the location you want to add the page)
4. Select Add a page
5. Select Add Lua Panel
6. Resize the Panel Now (It doesn't seem to adjust later)
7. Under Properties, select the little page with the lightning bolt
8. Select the "..." to open the LuaEditor.exe
----Sorry no graphics for this part---
9. Add your code
10. Save your code
11. CLOSE MACH 4 Display NOW
12. Open Mach 4 (your panel should be there)
-
If you can't resize the lua panel (sometimes it can be touchy to "Grab" the edges/corners with your mouse), go to the properties window.
change the Ht/Wt properties and that will cause it to change size, also the top corner location can change its position.
Scott
-
Thank Scott....good to know
I am hoping to have some time this weekend to tie my I/O code to this display and visa-versa; my grandson is staying over so progress maybe a little slow between naps....both his and mine ;D
-
Yah, thanx Tim. That's not what I am talking about tho (where you insulting my intelligence, haha! j/k). I am taking about how to tell the window that the panel has a parent; connect the panel to parent (ie, Default page) so my image does not "pop up" as it' own window. I want it to stick to Mach4's window (or "Default page")
my question was referencing the use of-
local window = panel:GetParent();
or connect the window(that was coded) to the lua panel that I just added to the screen.....
-josh
-
panel = mcLuaPanelParent; --Ties your panel to the mcLua Panel Parent
and stripout all of the window stuff or throw some if statements around the window stuff.
You can make it such that your code can work in a window or a panel.
if (mcLuaPanelParent == nil) then
--Do window setup
else
--Do Lua Panel stuff
end
Beware if you have messages that refer to frame:SetStatusText("MPG OFF") and you do not have a window it will cause your code to fail. Wrap your windows/frame code with an if (mcLuaPanelParent == nil) then statement
PoppaBear has a lot of good examples in his wizards that can become panels.
For the most part I just stripped out all of the window related stuff in mpanelscriptRev5.mcs. I probably could clean it up a bit more and remove some more.
-
I thought you were a Kiwi dan? or an aussie?
I am no Aussie. I am a kiwi bro grr
-
That's weird. Huh...frame:SetStatusText("MPG OFF") "MPG OFF" is just being passed as a string not a command. I wonder why it is interpreted that way? Although I think MPG_OFF is a C++ argument, but I don't think that would matter. Weird!
Thanx Tim! I'll try stripping out the window definition and see if the panel connects to my screen instead of a pop-up. So mcLuaPanelParent must be a defined global variable in wx.Lua.....
-
I finally made it such that the MPG Axis selection can be controlled from either the mechanical switch or the display radio buttons. ;D
1) I swapped out the radiobuttons for radioboxs; just to reduce code size and to make selecting the radio buttons via software easier.
2) The Mach4 Display Rotary Switch image and MPG Axis RadioBox will always reflect which Axis the MPG is connected to
a) The MPG Axis Radiobox controls which Axis the MPG is connected to independent of the MPG mechanical rotary switch position
i) The MPG Axis Radiobox controls always reflect which Axis the MPG is connected to
ii) The selection of an Axis in the MPG Axis Radiobox does NOT move the MPG mechanical rotary switch position
b) The MPG mechanical rotary switch "when switched" controls which Axis the MPG is connected to independent of the MPG Axis Radiobox selection
i) MPG mechanical rotary switch only reflects the current MPG Axis selection at powerup, at Mach4 startup and after the MPG mechanical rotary switch has moved.
ii) The Mach4 Display Rotary Switch image and the MPG Axis RadioBox are always automatically updated to reflect the current MPG Axis setting
When I update and test the other Jog Increment control code I will post the code so you can see or try out what I am talking about.
Then all I have to do is implement the Manual MPG "Rotation Direction Detection" code and I will be able to make a small video so you can see how it all works ;D
This may not be the best way to create a Jogging/Pendant Interface but I will be able to connect switch based pendants to Mach4 through an Ethernet Smooth Stepper and have cool images reflect what is going on ;D
-
sounds good tim when you get it working you may be able to supply pendents to go with your code just a idea
-
That sounds awesome Tim! You guys are doing great! :)
Brett
-
thats one good thing about M4 just some switches and a bit of Lua code and you have a mpg or just a signal table
-
...Don't forget the bit of work learning Lua if you don't know it already. ;D
I am working on cleaning up the code; then I will post it. (I created some bugs when I cleaned up; so I have to do a little troubleshooting later tonight)
There is a signal script, a Lua Panel script and image files that make it all happen. I will keep you posted
-
get there with learning lua, you are ahead of me to many other things to learn 3D cad. I am testing the tool height probing today hopefully nothing will get broken
-
This is the latest version....Sorry, I don't detect the MPG motion yet...nor do I scale images or radio boxes...but neither does Mach4 ;D
You will need to add some switches and ensure that you copy the signal script.
Summary of Software Architecture...
The Screen Load script detects the changes in the switch settings and makes changes to the Mach4 core software settings (MPG Axis, Jog Increment settings)
The MaintTab JogTab Lua Panel Script populates the Lua Panel with the Images and RadioBoxes. This script is called by a timer event every ~200mSec and calls a panel refresh. The refresh calls the onPaint function which updates the images based upon what the Mach4 core software settings are. If you use the RadioBoxes the images will be updated based upon the settings in Mach4 core software. Note if you modify this script and pieces disappear or are jumbled you did something wrong :D...I did so many times.
The MaintTab JogTab Lua Panel Script gets copied to a Lua Panel script
--Add a MainTab Tab to the screen
--Insert and scale a Lua Panel
--Update the Lua Panel script with the MaintTab JogTab Lua Panel Script
This Software is provided without warranty. :D Goodluck
-
That it so cool Tim! Thanx for sharing! I'm definitely gonna learn something from studying this :)
-
Thanks Tim, that's awesome! :)
Brett
-
This is the latest version....Sorry, I don't detect the MPG motion yet . . .
. . . This script is called by a timer event every ~200mSec and calls a panel refresh. --Insert and scale a Lua Panel
--Update the Lua Panel script with the MaintTab JogTab Lua Panel Script
TimGS,
Sorry I have not had time to follow your progress on this project. I was going to suggest you take a look at a sample 'mouse jogging' setup provided some time ago by Brian Barker and is floating around the forum. This sample uses the MPG functions and also is useful to review the difference in a floating wideget and one in a Lua frame both from the same code.
However, it seems you have had success in figuring this process out for yourself. Bravo! I have read the posts and noted that you are methodical in your approach and eat the elephant a bite at a time. This is a good model for readers to follow.
I have downloaded your code, but have not had time to peruse it. However, based on your description I do have two directions you may want to investigate.
First is to use signals rather than polling. 'Signals' in M4 seem analogous to interrupts and would be a better way to collect data from your hardware. Using this process prevents missed data and also eliminates the tremendous resource hog that polling will induce.
Second, although integrating a widget into an M4 screen is a great exercise in learning both M4 and Lua and wxLua, I don't think this is always the best approach for every application. Consider the advantages of a floating on-demand anytime jog window. For an on-demand anytime process like Jogging, why cripple the utility of it by chaining it to a specific screen or tab whereby other functions are now inaccessible?
-
stick it in the bottom bit then you can use of it from every screen just change yours for the jogging page when you have it at 100%
>:D :'(
-
I plan to put it in a separate window next and/or both just replace the current jog tab. You are correct the way it is implemented now is not practical nor very usable; a separate window will be much better.
Polling was not the best choice but it was the only way I could see at the time to update the widgets on the screen. Please note that the jog controls and jog input currently use signaling so the control inputs are not delayed by polling. ONLY the images on the screen are updated by polling Not the controls themselves.
-
I plan to put it in a separate window next and/or both just replace the current jog tab. You are correct the way it is implemented now is not practical nor very usable; a separate window will be much better.
In my view, a significant portion of our effort is an investment in learning the system. To that end, it makes perfect sense to experiment with multiple ways to do things. For example, I went a little nuts with the screen load script and signaling, but soon it became evident that not every action that CAN be moved to that location, is best suited to that method, nor is it convenient AT ALL to have the variables declared in a completely different place than where you will use them. So, I spent nearly as much time moving things BACK to the PLC from whence they came and unlinking processes from signaling.
Ultimately, it all contributes to knowledge of the system, so I don't consider it time wasted.
By your effort, you now have experience and knowledge of incorporating widgets into the MACH4 screens and also leaving them to float in their own window. Some processes will favor one over the other, and now you can do either, as you see fit.
Polling was not the best choice but it was the only way I could see at the time to update the widgets on the screen. Please note that the jog controls and jog input currently use signaling so the control inputs are not delayed by polling. ONLY the images on the screen are updated by polling Not the controls themselves.
An approach to consider is to have the command side act on interrupts (signaling) and then have a 'last act' be updating the display data and/or resetting controls. In this way, you still eliminate polling, very little processor overhead is added to the (overall) interrupt response and the data display is always current and also acts as a monitor of the underlying actions.
An example: On my motor controller, the user (or an embedded macro) enters the desired RPM into a MACH screen DRO. It would be simple to consider that DRO to be the current RPM, but the RPM is collected from that DRO, sent to the controller, the controller compares it to an number of parameters and current operating conditions, calculates and sends a command to the DSS to alter the step stream frequency, and then reports the actual set RPM (which may or may not be what was requested) back to MACH for display in a separate 'current RPM' DRO.
In this scheme, the entire process is 'in effect' monitored and the returned RPM is an indication that the function was carried out. Also, if the RPM returned is different from what was requested, that indicates that an invalid (usually exceeding the motor's maximum) RPM was requested.
I don't know at this point if MACH signaling is uber sensitive to the complexity of the response (as are processor interrupts generally), but it is a good practice to keep the responding function as short as is practical. Unless there is a compelling reason to do otherwise, on interrupt, I typically just set a flag and return. The flag is then picked up, reset, and the actual response is executed. This adds some micro seconds to the response, but that is generally less consequential than running an interrupt response too long.
This may not all make sense to readers, but in a nutshell, if you are using interrupts or signals and you start getting system hangs, the likely culprit is the length of the functions being executed. In the specific case of an MPG, you would replace:
InterruptEvent -> process encoder input, have a beer, update screen, have another beer, reset controls, watch the game, -> return
with
InterruptEvent -> EncoderDataReadyFlag = true; -> return
A few millis may pass here, but it would require an extremely critical timing event to make a difference - very unlikely to effect an MPG. Most importantly, other interrupts can come in during this period and be processed and the system will not hang.
Here is the 'catch net' routine, which can be anywhere the program continuously loops:
if (EncoderDataReadyFlag) then
EncoderDataReadyFlag = false;
process encoder input, wash the car, visit aunt betty, etc, etc
Now do all the controls stuff that used to be done by polling;
end
or if you are into functions:
if (EncoderDataReadyFlag) then
EncoderDataReadyFlag = false; -- don't forget to always reset the flag!
DoEncoderStuff
end
Function DoEncoderStuff -- I don't remember the correct syntax here
blah blah blah
end
-
I really like using event flags (ie. if flag = some value then reset or reassign flag value; call some fancy function end <- in the PLC) and then defining global flag variables and associated function in the screen load up script therefore all that is needed is to set some action or button press to flag = 1 for example.
It is really interesting that you have observed greater latency with signals, whereas for example.... once a signal is sent/received the signal script will reference the signal table and execute the associated function.
Both processes will execute an action based on an event. It's really the samething in my mind. signal states = flag values...if 'true' then reset; execute else 'false' end. I noticed the greatest latency when using functions in button scripts to adjust DROs. Then using the button to set a flag value in which the PLC catches and references a function in the screen load up script was still a little off but not as much. The best method was just to write the function in the PLC, so the PLC will only execute the function if the flag's value is true. I observed this with in->mm conversion DRO's. The best return is six ten thousands off exact value. Now, if you are in mm to begin with (config settings) it will be exact.
I mean as far as processing.. (this is my question)...everytime the PLC runs it tests only the conditional statement. If false then the PLC will skip to the end and continue. The PLC will not even go over the event function. Therefore, the only additional time required by the PLC is to evaluate one line...until, the condition is true. Correct?
So if timing is an issue shouldn't we just write our functions in the PLC? ...and then events in which time is not an issue, those functions can be defined and referenced from the screen load up script.
-
I really like using event flags (ie. if flag = some value then reset or reassign flag value; call some fancy function end <- in the PLC) and then defining global flag variables and associated function in the screen load up script therefore all that is needed is to set some action or button press to flag = 1 for example.
It is really interesting that you have observed greater latency with signals, whereas for example.... once a signal is sent/received the signal script will reference the signal table and execute the associated function.
'Latency' in this case would be the time between the command and the execution at the top level. There is more 'under the hood', but I would not know what that is. In terms of scripting, the delay would be the time it takes until the next pass of the PLC to pick up the flag. The frequency of PLC runs is user configurable.
Both processes will execute an action based on an event. It's really the samething in my mind. signal states = flag values...if 'true' then reset; execute else 'false' end.
Yes, but as I mentioned, I do not know how the signals work internally in MACH4, so whether they are 'released' or are interrupting the processing is a question for the developers. It is possible that the 'signal' is generated along with a 'return' and sent along its merry way so the processor is not interrupted, but I do not know that rather important detail, so I err on the side of keeping the response functions as brief as possible, as is required for 'real' interrupts.
I mean as far as processing.. (this is my question)...everytime the PLC runs it tests only the conditional statement. If false then the PLC will skip to the end and continue. The PLC will not even go over the event function. Therefore, the only additional time required by the PLC is to evaluate one line...until, the condition is true. Correct?
If I understand your question correctly, then yes. I have read what I could find on this forum and the available docs relative to signaling and I do not recall any references to timing, but it would be good info to have if the developers chose to disclose that detail.
So if timing is an issue shouldn't we just write our functions in the PLC? ...and then events in which time is not an issue, those functions can be defined and referenced from the screen load up script.
The PLC runs at specific intervals and signals can hit at any time. The signals, as I understand it, can call a function made 'resident' by the screen load script, so that chain of events is not limited by some arbitrary frequency as is the PLC.
I want to be clear that I am not arguing for or against the use of signals. There are applications where the immediacy of signaling is important and applications where it is not. My suggestion was a 'best practice' method to use signals (to the extent they mimic interrupts), not when they are appropriate to use.
-
I totally understand you are not arguing. I appreciate your time and response. This is how I learn. I mean, I was legitimately asking these questions. I really wanted to expand my knowledge with m4, especially in this scenario (MPG/jogging/resource conflict/timing/processing, etc). It is important to me to respect all views and alternatives. Sharing lessons learned and best practices is why I choose to be apart of this forum. It's the communication and topics like these that I am proud to apart of the m4 community. Thanx!
-josh
-
I totally understand you are not arguing.
-josh
A poor choice of words on my part. Probably one of the most troublesome words in the English language (that is if you can conceive of English as a language ), given the diametrically opposed definitions, both of which are accepted and used commonly. Mr. Webster states:
: to give reasons for or against something : to say or write things in order to change someone's opinion about what is true, what should be done, etc.
: to cause (someone) to decide to do or not do something by giving reasons
: to disagree or fight by using angry words
My use was the first definition. i.e. to 'make a case for' as opposed to contradict.
This forum needs new members and new ideas and new questions and people who are not afraid to post for fear of the last definition of 'argue'. I don't want to discourage anyone from posting an idea, no matter how silly it may seem to them, because you never know where the next great idea will come from, and it is often from a most unexpected source.
My wife is a project manager for a large Heath Insurance Company and is not technically versed in any of the activities that I swim in every day. It happens that I am developing a product that has 'cells' which contain what I will call 'action items' for the sake of discussion. I asked for an opinion of the process of individually changing the contents of the 5 cells ( in lieu of having pre determined sets of five). Her first response was "can you have 'favorites' ? ". This is a brilliant idea that never occurred to me at all, but has now on been added as a design goal.
While I would not term such a feature as 'favorites' per se, the concept of having a certain useful grouping of actions to go with a particular process is really no different than having a particular set of tooling for that process. Often the best ideas are the ones that seem all so obvious . . . once they are presented.
Enthusiasm is as important as skill or knowledge in actually accomplishing a goal. In this thread, Tim has demonstrated quite frankly amazing leaps forward in mastering a complex task and you have provided endless enthusiasm about anything and everything that even remotely resembles MACH4.
I hope that these examples are contagious and a career lurker or two will chime in. I'm always looking for the next great idea . . . from that most unlikely source.
-
the way crazy lou`s LOL (black screen of death) going he might get a job out of what he is doing he seems to be picking it up very fast
-
Positivity is contagious.
-
yer man you are doing quite well you should do your own screen set and other bits as you are and sell so you can take the girlfreind (mistress) out
-
I'll take her on vacation to New Zealand and leave her with you. Then I can actually get some work done then ;D
-
my wife would not like that idea
-
:o
-
its all good
-
TimGS,
I tried your code as I was attempting to setup a pendant in MACH4. I was able to build the LUA panel as you described and copied all your PNG images into an image directory under Wizards, etc. The code dies when it hits line 22.
panel:SetBackgroundColour(wx.wxColour(255,255,255));
I am struggling to figure out what is wrong. It never displays your images. I am using screen set WX4, this code seems to reference wx. but I looked online and saw many other examples that do the same thing so I am kind of stumped. I can not find these commands in any of the LUA manuals or the MACH4 script manual. Any guidance? thanks
I know this is an old thread but looked like a good learning tool.
Thanks
Russ
At Breakpoint line: 21 file: C:\Users\rdlarson\Documents\MACH4\mypanelscriptRev5.mcs
At Breakpoint line: 22 file: C:\Users\rdlarson\Documents\MACH4\mypanelscriptRev5.mcs
mcLua ERROR: Lua: Error while running chunk
[string "C:\Users\rdlarson\Documents\MACH4\mypanelscri..."]:22: attempt to index upvalue 'panel' (a nil value)
stack traceback:
[string "C:\Users\rdlarson\Documents\MACH4\mypanelscri..."]:22: in function 'main'
[string "C:\Users\rdlarson\Documents\MACH4\mypanelscri..."]:415: in main chunk
mcLua ERROR: Lua: Error while running chunk
Debug session finished.
-
I apologize for not responding. After being laid off, I had take some time to get my life together.
Look like a lot has changed in Mach 4 and I will have to dust off my controller and get busy :D
-
TimGS,
Sorry to hear about you losing your job. Trust me there is a lot of that going on here in the USA. Yeah MACH4 has had numerous changes, I still do not have my Pokeys based pendant all working but I do have some things working. I did get your code to work finally, can't remember exactly what I did to get it to work. LOL
Been busy at work and need to get back so I can finish up my new ESS based controlled on my machine down stairs and pull out the older parallel interface. It is all wired up and tested and ready to swap as soon as I get the pendant stuff working again.
Russ