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...

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?