Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: Bob49 on June 06, 2017, 02:11:50 PM
-
Hi all,
I've been messing about with my screen script for many months with some successes. But some failures at the same time. One of the things that stumps me a lot is in the CoreAPI, the descriptions of the parameters at times state an integer is required. Take mcJogSetInc for example, the axisID is stated to be an integer. But in th usage example given at the bottom of that particular page, it states "mInst, X_AXIS, .010". Now just to make sure I was thinking correctly, I actually looked up the meaning of integer. I found what I thought it to be, "a whole number; a number that is not a fraction".
So just where are these integers explained in the CoreAPI? I never have found any in the looking I've done. I actually have this function working in my script, but it was mostly by trial and error trying to figure out what exactly I needed to have in that portion of the statement. I ended up using the motor numbers and got things to working. When I tried using X_AXIS there, I got an error stating basically a number was expected and it didn't get it.
Is there a listing of the integers used in these portions of the functions somewhere? I hate for things to be a guessing game, but that so far has been the only way I've got much of this to work. Another example would be the mcJogSetType, again it states in the LUA syntax for that function number, number, number for the three parameters and for axis it specifies an integer as it does for the type. But in the usage at the bottom of the page is has no such thing and using that results in an error, again with it expecting a number in the second and third portions of the statement.
So unless I'm completely daft, I think I need to supply an integer for these statements. Is this something I need to make an assignment for somewhere? I didn't for the axis in my statements to set the jog increment value. Maybe I got lucky using the motor numbers there, I got no clue. And I really don't like operating like that.
Thanks for any advise you might have.
Regards
Bob
-
unless you set your variable X_Axis=0 then your variable X_Axis will equal "Nil"
the integer value are shown in () for each axis
-
Thanks for that, that's where I got the idea to use the integers I used for the axis. Motors = axis. But like I said, it was a guess at best. I lucked out. Before I used 0, 1 and 2 in the script, I got nil returned.
So where would the jog type integers be hidden? Like for MC_JOG_TYPE_VEL and MC_JOG_TYPE_INC. I've tried 1 for INC and 0 VEL and get no action for changing the jog type button. I've been trying to use the message box to get them displayed, but so far my simple script doesn't work. All I get is an error message. Pretty sure there's something missing in it. Even copied one that Daz did in a video and get errors. He got the axis id number to reveal itself.
Starting to think there may be more to it than my pea brain is coming up with.
Thanks
Bob
-
A lot of the examples within the API docs are C++ however where you see something like X_AXIS you can put an mc. infront IE mc.X_AXIS and this will give you the correct result.
MC_JOG_TYPE_INC = mc.MC_JOG_TYPE_INC
MC_JOG_TYPE_VEL = mc.MC_JOG_TYPE_VEL
DazTheGas
-
Thanks DAz,
Ive tried that and was getting an error when i positioned my switch for either VEL or INC. Had to edit the screen script to eliminated the errors, so I commented the lines out. I'm starting to wonder if it's not something related to the jog function in my script that is causing it. But like I mentioned, I have the set incremental function working perfectly. So from that, I have tried building onto it for the jog type. All in the same function though, maybe that's wrong.
Thanks
Bob
-
Take a look in the Screen Load Script at the function ButtonJogModeToggle() ;-)
DazTheGas
-
Been looking at that, but having a tough time figuring things out I see there. What does osig's have to do with toggling between INC and VEL? And what's feeding the osig? That's the part that has me puzzled. I have two input's that each are either on or off. And that's what I'm monitoring to choose between INC or VEL. In one case, one pin is high and one is low, in the other both are high. Would it then make sense to take that combined input and feed it to an output and let that toggle the jog type?
Or somehow tie what I'm trying to do to that function? Or could I have a second ButtonJogModeToggle function in my portion of the script, thinking not on that thought. How that function works is hard to wrap my head around right now, and I've been looking at it on and off for a long time. Just guessing here that a mouse push of the on screen toggle button outputs a signal that does it. So have thought that could be what I need to be doing too.
Thanks
Bob
-
Been looking at that, but having a tough time figuring things out I see there. What does osig's have to do with toggling between INC and VEL?
In this case replace the word signal with flag when you think about. Most things in Mach4 have an associated signal. Checking those signals (flags) is a way to find out what mode it is in.
The core knows what state its in...... its an osig because it may need to send that state out to motion controllers, pendents, screens, etc. or all of the above. Mach4 gives you lots of tools.
A lot of the examples within the API docs are C++ however where you see something like X_AXIS you can put an mc. infront IE mc.X_AXIS and this will give you the correct result.
MC_JOG_TYPE_INC = mc.MC_JOG_TYPE_INC
MC_JOG_TYPE_VEL = mc.MC_JOG_TYPE_VEL
DazTheGas
Yup, these are constants. It's good practice to use them. Think of them as an alias. The benefit of using them is that updates could change the integer values but if your scripts are using constants it wont brake the script because the constant can be pointed to the correct integer. If you check their value it will be == to some integer.
This is a nonsensical example that I can't see ever being a reality but a good example scenario so here goes......
The error message table for instance....... the constant mc.MERROR_NOERROR == 0. So today the script could use something like.......
if (rc == 0) then.....
or
if (rc == mc.MERROR_NOERROR) then
and they would both do the exact same thing because today mc.MERROR_NOERROR == 0.
Now pretend that for some reason the core code had to be changed because for whatever reason the error table must be changed so that 0 == mc.MERROR_GINORMOUSERROR and mc.MERROR_NOERROR == 1. If your script used the constant "if (rc == mc.MERROR_NOERROR) then" it would still work after the update. It would return a 1 now but the script would still work exactly as expected. However, if you were basing a decision on the error returning a 0 "if (rc == 0) then" your script would not work as expected because the meaning of 0 has changed from "no error" to "ginormous error".
I hope that makes sense.
I probably need to update the Mach4 lua language package I did for notepad++ but it does have all of the Mach4 constants in it (that existed when I did it).
-
Why yes, that makes lots of sense. And it's something I never ever considered. One new thing puzzling me since late yesterday though, I had tried the mc.X_AXIS and so forth in this script before only to get a message it was expecting a number. That I needed to correct the script to agree with that. Same for mc.MC_JOG_TYPE_VEL or mc.MC_JOG_TYPE_INC. But yesterday I used MC_JOG_TYPE_INC in that statement with Daz's MC_JOG_TYPE_INC = mc.MC_JOG_TYPE_INC and did not get that message. Now I'm wondering if I can go back and use the constants for my axis ID's instead of the motor numbers. May try that in a bit this morning.
So, finally not getting a message that there was something wrong, I took a look at the registers diagnostics panel and seen that my switch was toggling the jog type for all the axis I had set up in the script at that point. Then I went back in and extended the script to include all my axis. So now I know, or think anyway, that my script, as is, toggles the jog type through MC_JOG_TYPE_INC and MC_JOG_TYPE_VEL. But the actual Jog Type on screen button doesn't change state, so in actuality I don't really control the physical jog type yet. That's where the hints at tying this to the ButtonJogModeToggle bit in the screen script are pointing me.
And I messed with trying to do that then yesterday. It seems like I need to somehow send the state of my switch to Mach's Jog Inc and Jog Cont output signals. Then those signals would toggle the actual button via the function ButtonJogModeToggle? But that then brings up another question in my mind, if that's what I need to do, what good does it do to mess with setting up the mcJogSetType function at all? I guess a bit more confusion arose out of yesterdays trials. But I do see the need to tie the switch to the function ButtonJogModeToggle. That is, after all, what the actual on screen jog toggle button is controlled by.
Thanks
Bob
-
Yup, your jog type function will not change how any of the screen buttons work, what they do or display. Again...... another great and powerful thing about Mach4. You can set your pendent up to do one thing and your screen to do another. They can run their own totally independent functions or you can have them both run the same function. Just because a button press does an incremental jog doesn't mean a screen button press must do the same thing.
-
After pondering this all night, I decided the mcJogSetType function was maybe the wrong approach to the end game for my needs. So I stripped the statements relative to that function and installed statements to do it through the ButtonJogModeToggle and the related osigs. And in short order I got the Jog Type Toggle Button performing from my console switch. Not that tough after I drilled through all the advise given.
But; you knew there would be a but, that now has messed up my toggling between the increment values that I had working perfectly before. Part of what I expected from the Jog Type button proved to be true, in that the jog type would be persistent. It would be one until changed to the other. I was banking on that being the case. So in my one switch that handles jog type and jog increment, coming off the jog type inc, that jog type stays. But as I then progress through the incremental values, the only value that effects the jog amount is .001" if I use the on screen axis jog buttons. Now that I say that, I can't say that was 100% the case as I never tried the on screen axis buttons before.
But I plan on adding a Shuttle Pro for those buttons and I tested the jog functions via the keyboard and they work as they should, so it's just the on screen buttons that have an issue. But I don't plan on using them anyway. I guess it would be nice if they did just because, but I'm not going to worry too much about that caveat.
So, I got things worked out, many thanks for the words of wisdom here. Now on to order me a Shuttle Pro.
Regards
Bob
-
The reason I mentioned the function from the screen load script was that you can use the same principle within the SigLib, take a look at the following code that can be inserted into the SigLib using the inputs you have assigned to your 2 buttons.
local cont_in = mc.mcSignalGetHandle(inst, mc.OSIG_JOG_CONT);
local inc_in = mc.mcSignalGetHandle(inst, mc.OSIG_JOG_INC);
SigLib = {
[mc.OSIG_MACHINE_ENABLED] = function (state)
machEnabled = state;
ButtonEnable()
end,
[mc.ISIG_INPUT0] = function (state)
if (state == 1) then
mc.mcSignalSetState(cont_in, 0)
mc.mcSignalSetState(inc_in, 1)
end
end,
[mc.ISIG_INPUT1] = function (state)
if (state == 1) then
mc.mcSignalSetState(cont_in, 1)
mc.mcSignalSetState(inc_in, 0)
end
end,
DazTheGas
-
Hi Daz,
That's similar to what I ended up with, but started out with a bit of a mess. The mess was yesterday and last night, it got cleaned up and working this morning. I'm not using buttons, I have a 7 position rotary binary switch that has positions for jog types and jog increments. So the pin combination was throwing my thinking off. Until I ditched the function I started with, then things got clear.
Here's the jog portion of the screen script as it is now, and I think I'm mostly done tinkering with it as all my console functions work that I care about. Though some might get changed around down the road.
Regards
Bob
end
}
---------------------------------------------------------------
function JOG()
---------------------------------------------------------------
--Set Jogtype and jog increment from console switch
local Input14 = 0 --Clear local Input14
local Input15 = 0 --Clear local Input15
local Input17 = 0 --Clear local Input17
local hSig = 0 --Clear local hSig
local cont = mc.mcSignalGetHandle(inst, mc.OSIG_JOG_CONT)
local inc = mc.mcSignalGetHandle(inst, mc.OSIG_JOG_INC)
local mpg = mc.mcSignalGetHandle(inst, mc.OSIG_JOG_MPG)
inst = mc.mcGetInstance()
hSig = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT14)
Input14 = mc.mcSignalGetState(hSig) --Get State of Input 14
inst = mc.mcGetInstance()
hSig = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT15)
Input15 = mc.mcSignalGetState(hSig) --Get State of Input 15
inst = mc.mcGetInstance()
hSig = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT17)
Input17 = mc.mcSignalGetState(hSig) --Get State of Input 17
if ((Input14 == 1) and (Input15 == 1) and (Input17 == 1)) then
local inst = mc.mcGetInstance(); --Jog Continous
mc.mcSignalSetState(cont, 1)
mc.mcSignalSetState(inc, 0)
mc.mcSignalSetState(mpg, 0)
elseif ((Input14 == 0) and (Input15 == 1) and (Input17 == 1)) then
local inst = mc.mcGetInstance(); --Jog Incremental
mc.mcSignalSetState(cont, 0)
mc.mcSignalSetState(inc, 1)
mc.mcSignalSetState(mpg, 0)
elseif ((Input14 == 1) and (Input15 == 1) and (Input17 == 0)) then
local inst = mc.mcGetInstance()
mc.mcJogSetInc(inst, mc.X_AXIS, 0.0001)
mc.mcJogSetInc(inst, mc.Y_AXIS, 0.0001)
mc.mcJogSetInc(inst, mc.Z_AXIS, 0.0001)
mc.mcJogSetInc(inst, mc.A_AXIS, 0.0001)
elseif ((Input14 == 0) and (Input15 == 1) and (Input17 == 0)) then
local inst = mc.mcGetInstance()
mc.mcJogSetInc(inst, mc.X_AXIS, 0.001)
mc.mcJogSetInc(inst, mc.Y_AXIS, 0.001)
mc.mcJogSetInc(inst, mc.Z_AXIS, 0.001)
mc.mcJogSetInc(inst, mc.A_AXIS, 0.001)
elseif ((Input14 == 1) and (Input15 == 0) and (Input17 == 1)) then
local inst = mc.mcGetInstance()
mc.mcJogSetInc(inst, mc.X_AXIS, 0.01)
mc.mcJogSetInc(inst, mc.Y_AXIS, 0.01)
mc.mcJogSetInc(inst, mc.Z_AXIS, 0.01)
mc.mcJogSetInc(inst, mc.A_AXIS, 0.01)
elseif ((Input14 == 0) and (Input15 == 0) and (Input17 == 1)) then
local inst = mc.mcGetInstance()
mc.mcJogSetInc(inst, mc.X_AXIS, 0.1)
mc.mcJogSetInc(inst, mc.Y_AXIS, 0.1)
mc.mcJogSetInc(inst, mc.Z_AXIS, 0.1)
mc.mcJogSetInc(inst, mc.A_AXIS, 0.1)
elseif ((Input14 == 1) and (Input15 == 0) and (Input17 == 0)) then
local inst = mc.mcGetInstance()
mc.mcJogSetInc(inst, mc.X_AXIS, 1.000)
mc.mcJogSetInc(inst, mc.Y_AXIS, 1.000)
mc.mcJogSetInc(inst, mc.Z_AXIS, 1.000)
mc.mcJogSetInc(inst, mc.A_AXIS, 1.000)
end
end