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