The problem is that there's no joined up easy to understand way to find out about how Mach4 hangs together. I don't ask questions because I'm lazy or stupid, I ask them because they aren't obvious.
So far, I've not made any sense of how Mach4 decides what size jog increment to use, how to set that with a script and how to read it back. That's not for lack of trying, it just doesn't appear to work. Maybe I'm missing something that's blindingly obvious, but mcJogSetInc() returns an error and mcJogGetInc() doesn't return the value of the increment it's currently jogging at.
Well, technically speaking, it isn't how Mach 4 hangs together, but rather how the GUI hangs together. Mach 4 has a core that can be run by any GUI that is written using the Mach 4 API. We ship an example GUI called wxMach.exe that is basically a static front end. So what we are technically talking about here (now) is the functionality of the GUI. Mach4GUI.exe is the GUI that is dynamic and can be customized. It provides FAR more functionality than the static wxMach.exe GUI does. For instance, there is no LUA scripting in the wxMach.exe and you can't add or change the display beyond that of any other windows program.
So we have established that the Mach4GUI.exe provides a lot of functionality that the user needs to run a machine. One of the functions it provides is jogging. But it is important to note that it is a SCREEN implementation of the jog. So the internals of the GUI keeps track of the increment in its' own container. It calls API functions such as mcJogSetIncr() etc... This is done per axis in the core so the GUI is actually doing something more than setting just one global increment. It is doing it for ALL coordinated axes. But that is not all it does. It also keeps track of the jog mode (incremental or velocity) too. So that when you press the jog button on the screen, it does that particular jog mode. So there is a lot built in here.
mcJogSetIncr() and mcJogGetIncr() are basically APIs to use to STORE and RETRIEVE a jog increment. They don't, in fact, DO ANYTHING. When you cycle the Jog increments in the GUI, the GUI will use mcJogSetIncr() to store the jog increment that is selected. Mainly as a means of communication to the rest of the Mach world what increment it will use the next time an incremental jog is performed. But it also tracks what it was told to use in its' own internal variable. Why? Because there may be an MPG or some other control device (panel) that has jog buttons on it. The increments my be chosen by a buttons or some rotary knob. Say the user has an MPG and they switch to the .001 increment. Then they do some jogging and stuff with it and put it down. Do they want the MPG to always control the jog increments? Or do they want the jog increments to remain set by the device that is actually used for the current jogging activity? Most want them separate and that is the default behavior of the screen.
Some MPGs may only have a hand wheel and no increment switching available. This is the reason for mcSetJogIncr(). It allows for the screen to set the increment and the increment to be retrieved by whatever is running the MPG with mcGetJogIncr(). So the GUI's stock behavior WILL update mcSetJogIncr() if you toggle the jog increments with the stock jog control buttons. To let the rest of the Mach world know what the screen's current increment is. mcSetJogIncr() has no other function than that. The stock jogging implementation doesn't use mcGetJogIncr() to retrieve this increment before jogging. It uses its' own internal variable. So that the screen's jog increment can be different than the other devices that my be used to jog the machine.
Now, let's take a look at the API function that the GUI (or any other thing that may be running a jog will use) uses. Namely mcJogIncStart().
In LUA:
number: rc = mcJogIncStart(number: inst, number: axis, number: dist)
Notice the distance parameter. This is what drives the incremental jog's distance! Not what was set by mcJogSetIncr(). There is no function like mcJogIncStartUsingLastSetIncr().
Mach 4 was designed so that no scripting is required to use the stock screen sets. It is meant to cover 98% of the use cases. One can wire up a machine to a motion controller, map the necessary I/O to signals, and run the machine from just the screen and mouse. All of this functionality is "canned" or "shrink wrapped", if you will. However, it also provides a means of changing the default behavior, for whatever reason. Don't like it? Not applicable to the task at hand? Rather do it your own way? All of these are valid. But understand this: Now the work and functionality is up to you. So to change the jogging functionality, you will have to write your own and provide ALL of the functionality. Fortunately, you have the tools of the API to accomplish this. What I think you are wanting to do is do your own thing but also use the stock jog actions. We all want to have our cake and eat it too, right?
What does the stock jog functionality do?
1. Provides a jog mode variable. (incremental, velocity)
2. Provides a jog increment variable. (for the increments)
3. Provides a table of jog increments.
4. Provides canned actions to drive the jog buttons based on the above variables. (toggle jog mode, jog an axis, toggle increments).
5. Calls mcJogSetInc() to let the rest of the world know what the screen is doing.
So all of this will need to be duplicated/provided. Or... you can try and use the stock functionality and merge it with yours. HOWEVER, I do suggest that once you deviate from what is stock that you would be better off doing it all. So that YOU know what is going on all of the time and don't get bit by some stock behavior for which you may not have accounted. Because if you do "modify" the stock implementation, you pretty much need to know how it all works AND how to manipulate it to begin with. That is something that is in my head and it will probably NEVER be documented because 99% of the people using Mach don't kneed to know it. EVER.
Never the less, I have attached the test file that I used in the video to show how to do what I think you are wanting to do. But to do it right, you would need to edit all of the jog buttons, remove the stock actions, and write scripts to do all of the required functionality.
But can you guys imagine what kind of crap would be on this board if the stock jog buttons/actions didn't exist? I mean, it would be apocalyptic! "You mean that I have to write LUA code to jog an axis!!!", etc...
In the attched file, the SetJogIncrements() function now uses a screen API called scr.DoFunctionName(). You can open the screen editor and use the names of the stock button actions to get the name. This function ONLY works with the primary instance (no instance parameter), so multiple instance controls definitely need to handle this type of thing differently.
Steve
Guest
Show Posts