Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: Bob49 on October 10, 2016, 06:40:51 PM
-
Hello,
Been messing with Mach4 and trying to get my console switches to all work using LUA scripts. These all operate through my modbus devise. And that portion of things work fine, or appears to. Let me be very clear here, I know pretty much zero about LUA. But by using examples and lots of trial and error, I have 15 of my switches working now after a few weeks of effort. One switch is kicking my butt and the other 4 are completely over my head. The 4 in question are rotary switches that use various pin combinations for each position.
I stumbled in to poppabear's script somewhere that seems to deal with multi inputs for a function. It shows 2 inputs, but for two of my four switches, I have 3 pins each. So me, being simple minded, figured if two were good, then adding a third should be no problem. Here's the original I started from:
local Input14 = 0;
local Input15 = 0;
local Input17 = 0;
local hSig = 0;
hSig = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT14);
Input1 = mc.mcSignalGetState(hSig);
hSig = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT15);
Input10 = mc.mcSignalGetState(hSig);
hSig = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT15);
Input10 = mc.mcSignalGetState(hSig);
if ((Input14 == 1) and (Input15 ==1) and (Input17 == 1)) then
local inst = mc.mcGetInstance();
mc.mcCntlSetRRO(inst, 100.0);
end
All the pins in the modbus reflect the values as I have them stated, but I get no response in Mach. And the script debugs with no errors. I'm guessing here that I'm missing a lot of statements to make this work. This is just for one of the switch positions, but i figured that if I got one, I may be able to get the rest. And this is really the easiest of the 4 rotary switches. The others get more complex, one for jog control type and increment value, one for FRO and one for SRO.
The one switch that has what seems like good script is the cycle start function. Seems to me the scripts I'm using for Enable, single block and the like should work for cycle start. But I get nothing when trying to operate the switch. The others with that same scripting work fine. I used 1 as the variable, did I guess wrong there?
Any thoughts on how to get over this hump? I'd appreciate the help.
Thanks
Bob
-
I guess I need to back up on my stated problem with the cycle start function. I had been testing it with the MDI. And it doesn't start the g-code in the MDI. But it will do a cycle start on a g-code program and restart either movement of that g-code or movement initiated via g-code in the MDI. So I'm thinking this is designed in and different than how Mach3 worked. Further guessing on my part that I'd need a different button to activate input I make in the MDI. But I don't see a function for doing that.
Thanks
Bob
-
I realized earlier today that the script I inserted was the first capture and not completely correct as far as the inputs. Here's the corrected script I've been testing. I've tested the individual pins changing state with the Set RRO statement and it works fine. And I've tried the below script with just two inputs and can't get it to work, so i'm thinking it's not the three inputs that's giving me a problem, I think there's something wrong in the wording of the script.
local Input14 = 0;
local Input15 = 0;
local Input17 = 0;
local hSig = 0;
hSig = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT14);
Input14 = mc.mcSignalGetState(hSig);
hSig = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT15);
Input15 = mc.mcSignalGetState(hSig);
hSig = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT17);
Input17 = mc.mcSignalGetState(hSig);
if ((Input14 == 1) and (Input15 ==1) and (Input17 == 1)) then
local inst = mc.mcGetInstance();
mc.mcCntlSetRRO(inst, 100.0);
end
Bob
-
Well ive run the script on my machine and the code works fine, try a bit of debug info in the the script to see what part is not working on your screen.
DazTheGas
-
Where are you defining the inst = mc.mcGetInstance(); before getting the hSig's?
-
Well ive run the script on my machine and the code works fine, try a bit of debug info in the the script to see what part is not working on your screen.
DazTheGas
DazTheGas,
So it ran fine and actually caused the function to operate? Wow! On my mill, it just gets ignored it seems.
Debug info huh? I've been trying to absorb some of thats stuff, but I'll admit LUA makes my mind go numb. But I've mainly been focused on what makes up a correct working script.
Where are you defining the inst = mc.mcGetInstance(); before getting the hSig's?
I've been thinking some assignment wasn't getting made, I've tried various things. But not that. I struggle to follow any logic in some of these scripts.
But I gave it a try this morning adding it between the SignalGetHandle and SignalGetState statements for each of the three inputs. It debugged fine, but had no bearing on the operation of the switch itself. Still no responce from the switch after restarting Mach.
If I take this RRO portion of the whole screen load script into a new McLUA window and do a debug on it, I get this error:
At Breakpoint line: 7 file: C:\Mach4Hobby\LuaExamples\RRO test script.mcs
mcLua ERROR: Lua: Error while running chunk
[string "C:\Mach4Hobby\LuaExamples\RRO test script.mcs..."]:7: wxLua: Expected a 'number' for parameter 1, but got a 'nil'.
Function called: 'mcSignalGetHandle(nil, number)'
01. mcSignalGetHandle(number, number, lightuserdata)
stack traceback:
[C]: in function 'mcSignalGetHandle'
[string "C:\Mach4Hobby\LuaExamples\RRO test script.mcs..."]:7: in main chunk
mcLua ERROR: Lua: Error while running chunk
Debug session finished.
That whole portion of only the RRO script I tested read as below, and yielded that noted error. But if it's in the complete Screen Load Script, I get no errors.
--Set Rapid Over Ride Value, 0%, 25%, 50% and 100%
local Input18 = 0 --Clear local Input18
local Input19 = 0 --Clear local Input19
local Input20 = 0 --Clear local Input20
local hSig = 0 --Clear local hSig
hSig = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT18)
inst = mc.mcGetInstance()
Input18 = mc.mcSignalGetState(hSig) --Get state of input 18
hSig = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT19)
inst = mc.mcGetInstance()
Input19 = mc.mcSignalGetState(hSig) --Get state of input 19
hSig = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT20)
inst = mc.mcGetInstance()
Input20 = mc.mcSignalGetState(hSig) --Get state of input 20
if ((Input18 == 0) and (Input19 == 1) and (Input20 == 0)) then
local inst = mc.mcGetInstance()
mc.mcCntlSetRRO(inst, 100.0) --Set RRO to 100%
end
if ((Input18 == 1) and (Input19 == 0) and (Input20 == 1)) then
local inst = mc.mcGetInstance()
mc.mcCntlSetRRO(inst, 50.0) --Set RRO to 50%
end
if ((Input18 == 0) and (Input19 == 0) and (Input20 == 1)) then
local inst = mc.mcGetInstance()
mc.mcCntlSetRRO(inst, 25.0) --Set RRO to 25%
end
if ((Input18 == 1) and (Input19 == 0) and (Input20 == 0)) then
local inst = mc.mcGetInstance()
mc.mcCntlSetRRO(inst, 0.0) --Set RRO to 0%
end
Bob
-
Where are you defining the inst = mc.mcGetInstance(); before getting the hSig's?
OOOppps - I tested the code in my personal editor and forgot the instance is declared automatically so I dont get errors..
try something on these lines
--Set Rapid Over Ride Value, 0%, 25%, 50% and 100%
local Input18 = 0 --Clear local Input18
local Input19 = 0 --Clear local Input19
local Input20 = 0 --Clear local Input20
local hSig = 0 --Clear local hSig
local inst = mc.mcGetInstance()
hSig = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT18)
Input18 = mc.mcSignalGetState(hSig) --Get state of input 18
hSig = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT19)
Input19 = mc.mcSignalGetState(hSig) --Get state of input 19
hSig = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT20)
Input20 = mc.mcSignalGetState(hSig) --Get state of input 20
if ((Input18 == 0) and (Input19 == 1) and (Input20 == 0)) then
mc.mcCntlSetRRO(inst, 100.0) --Set RRO to 100%
elseif ((Input18 == 1) and (Input19 == 0) and (Input20 == 1)) then
mc.mcCntlSetRRO(inst, 50.0) --Set RRO to 50%
elseif ((Input18 == 0) and (Input19 == 0) and (Input20 == 1)) then
mc.mcCntlSetRRO(inst, 25.0) --Set RRO to 25%
elseif ((Input18 == 1) and (Input19 == 0) and (Input20 == 0)) then
mc.mcCntlSetRRO(inst, 0.0) --Set RRO to 0%
end
If I get time later I will look at some debugging for ya.
DazTheGas
-
Thanks for that, but still no love from the switch. :'( But that version actually makes sense to me. More sense than how it was before, but I'm LUA stupid, so take that with a grain of salt. :)
That would be fantastic for some help in debugging this.
Bob
-
Ok, here is the thing, in the call hSig = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT18) inst is the first parameter required. What is inst? In your script it does not know because you have not defined it yet. You edited it to define it after it was needing defined. So any variable you are using for a parameter must be defined before using it.
The reason it works in the screen load script is because inst is defined at the very beginning of the screen load script.
inst as you can tell by the api call mc.mcGetInstance() is the instance of Mach. Because Mach4 can have multiple instances you need to know what instance you want to get or set. With the exception of a few, all api calls will use the instance parameter for the first parameter.
You only need to define it once within the scope of whatever it is your doing.
That error message is telling you exactly what is going on. It was looking for a number for the instance parameter (defined as mInst for Mach Instance in the api docs) but got a nil because the variable you were using for the instance ("inst") was not defined. All variables in lua are given the value of nil until you overwrite it with something else. So it got a nil when it was needing a number.
But listen, don't feel bad about this. I did this jut a week or so ago myself. :-[ Tunnel vision may be the death of me. Thankfully another fella loaned me his eyes for a bit and caught it right off.
-
I realized earlier today that the script I inserted was the first capture and not completely correct as far as the inputs. Here's the corrected script I've been testing. I've tested the individual pins changing state with the Set RRO statement and it works fine. And I've tried the below script with just two inputs and can't get it to work, so i'm thinking it's not the three inputs that's giving me a problem, I think there's something wrong in the wording of the script.
local Input14 = 0;
local Input15 = 0;
local Input17 = 0;
local hSig = 0;
hSig = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT14);
Input14 = mc.mcSignalGetState(hSig);
hSig = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT15);
Input15 = mc.mcSignalGetState(hSig);
hSig = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT17);
Input17 = mc.mcSignalGetState(hSig);
if ((Input14 == 1) and (Input15 ==1) and (Input17 == 1)) then
local inst = mc.mcGetInstance();
mc.mcCntlSetRRO(inst, 100.0);
end
Bob
So what inputs are you using? 14,15,17 or 18,19,20?
Daz's script should work a treat but if your using different inputs edit the script so its looking at the right ones.
-
Also, where are you putting this script and how are you running it?
Seems to me the script Daz gave you would need to be in a function in the screen load script. Then you would make sure your inputs are setup in the sig lib in the screen load script so that when any of the inputs change states they would run that function.
-
Ok, here is the thing, in the call hSig = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT18) inst is the first parameter required. What is inst? In your script it does not know because you have not defined it yet. You edited it to define it after it was needing defined. So any variable you are using for a parameter must be defined before using it.
The reason it works in the screen load script is because inst is defined at the very beginning of the screen load script.
inst as you can tell by the api call mc.mcGetInstance() is the instance of Mach. Because Mach4 can have multiple instances you need to know what instance you want to get or set. With the exception of a few, all api calls will use the instance parameter for the first parameter.
You only need to define it once within the scope of whatever it is your doing.
That error message is telling you exactly what is going on. It was looking for a number for the instance parameter (defined as mInst for Mach Instance in the api docs) but got a nil because the variable you were using for the instance ("inst") was not defined. All variables in lua are given the value of nil until you overwrite it with something else. So it got a nil when it was needing a number.
But listen, don't feel bad about this. I did this jut a week or so ago myself. :-[ Tunnel vision may be the death of me. Thankfully another fella loaned me his eyes for a bit and caught it right off.
Thanks,
I wouldn't call all of that crystal clear, but it makes lots of sense. And I can wrap my pea brain around it. I just wouldn't try to pick an argument with anyone over any of it...I'd lose. I've tried moving some of this stuff up and down in the RRO portion of the Screen Load Script and then in the RRO section itself taken out of the Screen Load Script.
There is actually two sections in the Screen Load Script similar to the RRO portion. The first that I've stopped messing with for the time being deals with jogging. Changing from Cont to Ince and changing the increment values. I decided some days ago dealing with the RRO portion was easier than the jogging section. And that if I could conquer the RRO section, then I'd go back and take on the jogging section again.
So input14, 15 and 17 are part of the jogging scripts that I copied to then add the RRO portion. But before that, I copied the script that poppa bear wrote that included input1 and input10. And built the jogging section from that. That's how I go crossed up on the inputs. But for the RRO section, I use inputs 18, 19 and 20. And in that section, all the statements agree. In the jogging section, 14, 15 and 17 are used in all the statements or arguments. But just to make absolutely sure, I'm going to go out there and take another look at them.
All of this is in the Screen Load Script unless I break it out to do some local debugging. But I've pretty much given up doing that as the Screen Load Script is where it needs to be in the end. And now I feel a bit more comfortable dealing with the Screen Load Script than I did some days back. I haven't broken anything I haven't been able to fix yet as the mill will still run after I save the script and quit the screen editor.
And I'll warn your now, this is part of a larger exercise. I have two more switches, one for FRO and one for SRO that I'm going to have to deal with. In Mach3 brains, I've had all this working and working great. In brains, i assigned values to the switch states via a bit of math. took the state value and multiplied the 1 or 0 by a value. In the case of input18, that would be x's 1, for 19 x's 4 and for 20 x's 2. Then I added all the answers and that new sum was then compared to stated values. When the sum equaled one of those stated value, then the instructions were to do a function related to the stated value. And that all made great sense to me back then. It would be fantastic to pull that off in LUA if that's possible, as the FRO and SRO, from what I know right now, would only work using that sort of scheme.
Bob
-
Just to clarify things, I've included the complete Screen Load Script that is the current one in Mach4 and actually interfaces many of the switches in my console. The easy ones work, none of my rotary switches currently work. Keep in mind this is a work in progress, so there are things needing cleaned up before I call it finished.
-
See if this sorts it.
-
Well, that took me a bit to figure out how to load that, I finally copied and pasted over the other one. Saved that and closed it. Re-opened it to check I had the correct script. Restarted Mach then. But nope, same results, the switch pins show their correct state in the modbus diagnostics, but won't drive the RRO function. I then removed the -- in front of the local inst = mc.mcGetInstance() and tried it. Still no love from the switch while Mach is live, enabled or not. I proved to myself the function will work whether Mach is enabled or not and that's how I expected it to work. And I did verify the correct inputs and modbus pin assignments agree with the specific scripts. So that's all cleaned up.
Bob
-
Do you have your inputs mapped to the modbus registers? Just because they are getting to modbus registers does not insure they are being seen as inputs in Mach. If you open diagnostics, logging pin and play it....... do you see the signals change states as you change them? Do that, save the log file and post it here. If your using the wx4 or wx6 screen set you can also watch their states change on the diagnostics page.
-
Man, that's a handy function. Been so focused on the scripting I missed that. Find the log file below.
-
By the way, that log should show all the inputs from the 4 rotary switches functioning.
Bob
-
Well, a miracle just occurred. The RRO switch now works. And it seems the first iteration wasn't that far off. And Chaoticone had it right at his first suggestion. That GetInstance statement just needed to go for every one of the GetSignalHandle statements. Just using it once prior to the three GetSignalHandle statements wasn't enough.
Of course it's taken me around 14 hours of doing everything I could dream up to get there, even causing a bunch of errors on restarting Mach. But on page 16 of the scripting manual it lays out what's needed. My problem was I took the original at face value and figured the problem was somewhere else.
Thanks for all the help and advise, if anyone desires it, I can upload the working screen script. Now on to the jogging function.
Bob
-
Woke up this morning and knew how to write the scripts for the FRO and SRO. Got out to the shop and got it done and those two switches now work. FRO gives me a range from 0% to 250% in 12.5% steps. SRO gives me a range from 40% to 250% in 15% steps. FRO uses 5 inputs, but I was sure that was no problem.
Yesterday I got some of the jogging functions working. But there are a few minor issues. The jog type argument to use is a mystery to me. But I've seen that what I've got so far for increment values is only working on X, so I got to add some statements to include Y and Z as well. That's easy enough.
Bob
-
Bob: I have been following your progress. Glad to hear of your success. I would like to see how your put it together if you would not mind posting your final screen script. I am working on a similar set of controls to update an machine from Mach3 to Mach4. Any other words of wisdom are appreciated.
Thanks, Jim
-
Not a problem. Words of wisdom? I got none. But I can tell ya what works and what doesn't in this script. RRO, FRO and SRO all work 100% and work quickly. I set the values to match the graphics I created for my console back when I built it. Those step values came from a commercial control I bought to get the switches. Good thing is you can change them in the script to whatever you like. Just follow the whole or decimal values where they appear.
The jogging is still a mystery to me though. The first two chunks are to control the jog type, either continuous or incremental. But I've not cracked the values needed to set them in the jog panel. So that's a work in progress yet. The increment values all work to change the text window DRO where they appear in the jogging panel. But none of them will toggle the CycleIncrementValue function to make the button active in the jog panel. And I've found that's required with the version of Mach4 I have, that might be 3124. I personally don't like how the jog panel works due to that. It's a bit quirky I think. So if you set the increment value via a hard switch, then used the mouse to make the CycleIncrementValue active and had jogging set to incremental, then you could jog the value that's showing in that text window DRO. But if you change that value via the hard switch, the jog increment value will still be what it was before you just changed it. You would have to go back with the mouse and make that CycleIncrementValue button active again to use the new increment value.
So I'm still trying to sort through that. And me, I'd like to change the jogging panel to eliminate the need to make that button active. Just make it do what it says it's supposed to do, cycle the value, nothing more. If incremental jogging is already selected, why would I need another button to activate anything. Mach3 never worked like that and I think now that early versions of Mach4 didn't either.
So that's about the extent of my knowledge so far. I do have another opinion on jogging though, I don't like the method that's required to setup the keyboard keys for jogging. The manual hints that the keyboard is already set for using the old standard Mach3 keys for jogging. That's not the case, you have set that up in the keyboard plugin. And then they're tied to mach and can't be used for other uses. I think Daz has a work around for that, but I've not explored any of that to much depth. So it remains a work in progress while I sort it all out.
In the signal table, you'll see some inputs that don't appear to be being used. And they aren't right now. I think there are 4 of them. All the rest of the 31 or 32 inputs work for their intend functions. And the way the script for each are written, they either leave a function active or toggle it. Most of my switches are momentary switches, like cycle start, feed hold, single step and so forth. The way the statements are written deal with the need to either leave the function persistent or toggle it off. Spindle range is one such. Range 0 stays 0, range 1 stays range 1.
Hope that helps you get where you want to go.
Bob
-
Bob: Thanks so much. I got my Cycle Start and Feed Hold buttons working. A good start!
FRO and SSO are next. Are you using a rheostat for analog voltage or some kind of encoder for those?
I am using a Pokeys57CNC board and using their plugin which includes the MPG control and axis and step value selectors.
I'll study some LUA for dummies to make some sense of what is going on. The last programming for me was a little C in the previous century.
Thanks again
Jim
-
My switches for FRO, RRO, Jogging and SRO are all multi position rotaries that use a combination of the internal contacts for each position. They are Fuji AC09 real binary switches. Some just have more positions than others. Hence the additional inputs in the script. So for each input, it's just a question of is the state 1 or 0.
Bob
-
Bob: I reread the postings and checked out the switches (very interesting) as well as your code. Starting to make sense. (sorry for the stupid questions) That is a very clever way to control the overrides!
Thanks, Jim
-
Thanks Jim.
The switches are nice and pretty industrial. Actually until Friday morning I had no clue how to do them. Then in an instant it was crystal clear. Do them just like the RRO. Don't know why I couldn't see that before then.
I messed with the mill today to make a couple of parts. And in doing that had to mess with jogging. Verified there is no keyboard jogging without setting that up in the keyboard plugin. The standard x and y jogging keys only move the jog rate slider if nothing is set up in the plugin. In the plugin you have to set up const jogging, or incremental jogging or by using more key combo's you can have both. Same goes for rapid jogging. So I'm a ways from having jogging control via my console and the keyboard like I had in Mach3.
And there ain't no stupid questions. We weren't born with this knowledge and if you don't ask, you may never have it. That's how I got over the hump on it. And a couple kind soles threw me a clue or two.
Bob
-
you can use a num keypad for a jogging keypad then you can use it like a pendant
-
Guys, here are some signals I added to the sig library and the function it runs if any of their states change. You might find it helpful. But remember, this is out of the screen load script and inst is defined at the beginning of it.
--------------------------------------
-- CNC4PC Pendant --
--------------------------------------
-- These simply run the CNC4PCPendant function if their state changes.
[mc.ISIG_INPUT10] = function (state)
CNC4PCPendant()
end,
[mc.ISIG_INPUT11] = function (state)
CNC4PCPendant()
end,
[mc.ISIG_INPUT12] = function (state)
CNC4PCPendant()
end,
[mc.ISIG_INPUT13] = function (state)
CNC4PCPendant()
end,
[mc.ISIG_INPUT14] = function (state)
CNC4PCPendant()
end,
[mc.ISIG_INPUT15] = function (state)
CNC4PCPendant()
end,
[mc.ISIG_INPUT16] = function (state)
CNC4PCPendant()
end,
[mc.ISIG_INPUT17] = function (state)
CNC4PCPendant()
end,
[mc.ISIG_INPUT18] = function (state)
CNC4PCPendant()
end,
[mc.ISIG_INPUT19] = function (state)
CNC4PCPendant()
end
}
---------------------------------------------------------------
-- CNC4PC Pendant function.
---------------------------------------------------------------
function CNC4PCPendant()
local hSig, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT10) -- Is mapped to Port 2 Pin 4 *X Selection
local XSelection, rc = mc.mcSignalGetState(hSig)
local hSig, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT11) -- Is mapped to Port 2 Pin 5 *Y Selection
local YSelection, rc = mc.mcSignalGetState(hSig)
local hSig, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT12) -- Is mapped to Port 2 Pin 6 *Z Selection
local ZSelection, rc = mc.mcSignalGetState(hSig)
local hSig, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT13) -- Is mapped to Port 2 Pin 7 *A Selection
local ASelection, rc = mc.mcSignalGetState(hSig)
local hSig, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT14) -- Is mapped to Port 2 Pin 8 *.001 Selection
local Step001, rc = mc.mcSignalGetState(hSig)
local hSig, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT15) -- Is mapped to Port 2 Pin 9 *.010 Selection
local Step010, rc = mc.mcSignalGetState(hSig)
local hSig, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT16) -- Is mapped to Port 2 Pin 10 *.100 Selection
local Step100, rc = mc.mcSignalGetState(hSig)
local hSig, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT17) -- Is mapped to Port 2 Pin 15 *Estop
local PenStop, rc = mc.mcSignalGetState(hSig)
local hSig, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT18) -- Is mapped to Port 2 Pin 12 *B Selection
local BSelection, rc = mc.mcSignalGetState(hSig)
local hSig, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT19) -- Is mapped to Port 2 Pin 13 *C Selection
local CSelection, rc = mc.mcSignalGetState(hSig)
local PenJogOn, rc = mc.mcSignalGetHandle(inst, mc.OSIG_OUTPUT10)-- Is mapped to Port 2 Pin 1 *Jog on LED
if XSelection == 1 then
mc.mcMpgSetAxis(inst, 0, 0) --X Axis
mc.mcCntlSetLastError(inst, "X Selected")
mc.mcSignalSetState(PenJogOn, 1)
elseif YSelection == 1 then
mc.mcMpgSetAxis(inst, 0, 1) --Y Axis
mc.mcCntlSetLastError(inst, "Y Selected")
mc.mcSignalSetState(PenJogOn, 1)
elseif ZSelection == 1 then
mc.mcMpgSetAxis(inst, 0, 2) --Z Axis
mc.mcCntlSetLastError(inst, "Z Selected")
mc.mcSignalSetState(PenJogOn, 1)
elseif ASelection == 1 then
mc.mcMpgSetAxis(inst, 0, 3) --A Axis
mc.mcCntlSetLastError(inst, "A Selected")
mc.mcSignalSetState(PenJogOn, 1)
elseif BSelection == 1 then
mc.mcMpgSetAxis(inst, 0, 4) --B Axis
mc.mcCntlSetLastError(inst, "B Selected")
mc.mcSignalSetState(PenJogOn, 1)
elseif CSelection == 1 then
mc.mcMpgSetAxis(inst, 0, 5) --C Axis
mc.mcCntlSetLastError(inst, "C Selected")
mc.mcSignalSetState(PenJogOn, 1)
else
mc.mcMpgSetAxis(inst, 0, -1) --No Axis
mc.mcCntlSetLastError(inst, "No Axis Selected")
mc.mcSignalSetState(PenJogOn, 0)
end
if Step001 == 1 then
mc.mcMpgSetInc(inst, 0, .001)
elseif Step010 == 1 then
mc.mcMpgSetInc(inst, 0, .010)
elseif Step100 == 1 then
mc.mcMpgSetInc(inst, 0, .100)
end
if PenStop == 1 then
mc.mcCntlEStop(inst)
end
end
-
you can use a num keypad for a jogging keypad then you can use it like a pendant
Took me a while to come to grips with this jogging thing. I did end up using the number pad for continuous and rapid jogging of X, Y and Z, then used the standard arrow keys and page up and down keys for incremental jogging. No idea what I'll use when I get the 4th axis mounted back on the mill, probably just the mouse and jog panel.
So I do have console control of the incremental value, but still no control on selecting incremental or continuous jogging from the console switch. And I still don't understand what the enable or disable keyboard jogging button is supposed to do. It does still allow the keyboard jogging, only it seems it's all continuous in spite of what the keys have been set up for.
Maybe adding a pendant would be the way to go. Put it all in one hand held devise. May have to look into that.
Bob
-
pendants make life very easy