My code is full of stuff like:

hAxis_X, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT4)

Is this (below) legit LUA?

local XAxisSelectSwitchInput = mc.ISIG_INPUT4

hAxis_X, rc = mc.mcSignalGetHandle(inst, XAxisSelectSwitchInput)


Basically I want to define all the inpuut/output handles in one place rather than sprinkle configuration through the code

Hi,

local XAxisSelectSwitchInput = mc.ISIG_INPUT4

That is not illegal but it does not gain you anything. mc.ISIG_INPUT4 is just a number, I think in this case the number is 3. Its called an ENUM. It means that you do not have
to remember that Machs #4 input has the numeric equivalent of three.

What you really want to do is have the handles assigned to a variable. This is problematic. Lua is a self-memory manged language. When a variable goes out of scope then it will
be 'Garbage Collected'. If you wish it to stay permanent then you have to use a global variable....but that means that Lua has to stop and resolve the address of the variable each and every time
its required.....poor programming.

A handle is effectively a memory address of the variable concerned. What happens when the whole Lua chunk goes out of scope? The variable gets garbage collected. When that chunk is read back into the
CPU when its required some time later that variable will be assigned anew....with a new address, aka handle. Lua makes use of stacks, and these stacks contain data variables that are in use at the moment,
but these stacks can and do shift around. So if you had a global variable that pointed to a specific memory address you're going to have trouble because that memory address is not the variable that you thought
it was....it may be another variable or piece of instruction code altogether and really screw things up.

I make it a habit to use a variable only if its handle is calculated/resolved WITHIN the same scope. I'm not sure that is strictly necessary....but on the other hand I know it works. I would say that having
handles all over the place is the price you pay for having  dynamically allocated memory and autonomous garbage collection.

Craig

>but it does not gain you anything.

Sure it does - it lets me set up a little table where I assign inputs to meaningful variable names at the start of the script, and don’t have to worry about hunting input numbers if the wiring changes.

PanelStartSwitch = mc.ISIG_INPUT4
PanelFeedHoldSwitch = mc. ISIG_INPUT5

Etc

Hi,

Sure it does - it lets me set up a little table where I assign inputs to meaningful variable names at the start of the script, and don’t have to worry about hunting input numbers if the wiring changes.

Ok...if you think thats important but each assignment has to be made within the same scope, so they are going to be scattered around in your code because they'll get garbage collected otherwise.

Craig

Hi,
 and remember PanelFeedHoldSwitch is still not the handle....you still have to get the handle....and agin it must be done within the scope of the function.

Craig

Yeah. I do global variables that rename the signal numbers, then use the new names to get handles whenever I need them. The handles are still scattered all over, but the definition that a specific switch is associated with a specific signal is in one place.

Ideally they’d be constants, not global variables, but I’ll use the tools I have.

Have you seen the question about how to read an MPG as an input device?

You may be better off creating a global table of the handles rather than the input/output numbers. This way you will only need to call mcSignalGetState with the appropriate handle rather than getting the handle each time.