A member has posted a warning in the bugs thread about his jogging project having a nasty behavior. Apparently if he has a jog button active when MACH4 starts, the axis begins to move continuously and he has to e-stop/disable MACH4 to get the table stropped.  I suggested he bring that issue to this thread where solutions are being discussed.

In the case mentioned above, he is apparently going thru an ESS, but it is unclear (to me) exactly how he has things connected.

Based on the topic of this thread, it seems that interfacing thru a popular motion controller should be part of the discussion. In the case of the ESS, however, I think the first step in diagnosis should be to determine if the problem is with the ESS or MACH4.

I have an ESS that was purchased only to test compatibility with my own TCP/Modbus device, and I do not know much about it operationally.

Since I have just completed interfacing an industrial joystick and rotary quadrature encoders to MACH4's jogging facility, I can offer some suggestions.

Probably the most important thing for Pendant developers to realize is that once a MACH4 jog is initiated, it continues until it is expressly terminated.  The behavior of the screen buttons is deceiving in that is appears as though MACH JOGS only as long as contact is maintained, but that is not that case.

Like most Windows mouse controls, a 'mouse click' is divided into several parts, most notably the initial 'click' from the downward movement followed by a completely separate event occurring when the mouse button is released. It appears that some folks are only sending a Jog start on contact of their button and expecting the jog to stop when the button is released. That will not happen. You MUST provide a jog STOP when the button is released, otherwise the axis will continue to move.

Initially, I tried actuating the standard MACH screen buttons using input data, but this did not work well at all for me. YMMV, but I abandoned this approach pretty quickly.

To partially speak to the thread title 'What is the best way', I would suggest that any way other than USB is best. There are a number of ways to get data into MACH4 using TCP interfaced devices and while they are somewhat more complicated to get going, once you have the comm established, it is much faster than USB and pretty much bullet proof. The best you can say for USB is that it 'seem to be working at the moment'. USB has a great spec and was a well planned replacement for the old serial interface, but it has been ruined by the veritable land-rush to use it's highway to transport converted RS232 signals instead of producing true native USB interfaces.  

I have dug into mach4 today in relation to the jogging, you can get bad behaviour from it, but all depends on the code that you implement with it.

if its using the keyboard emulator as I was today, even if the machine is disabled the machine could still jog... but it would be continuous and only by pressing enable then disable or estop could stop the machine. This is where it comes down to the backend of what you put in it. My answer was to map keys to an input signal  in a function that would only work if the machine state was enabled, this worked perfect with cycleing between constant and step.

other ideas I have in pipeline is to send an output signal to my touchscreen to enable/disable jogging depending on the machine state.

DazTheGas

you just need to find what the code is for pushed do this when not push stop it will go in clicked script

have a look at this

http://www.machsupport.com/forum/index.php/topic,27190.0.html

There are 'actions' and there are Lua scripts. These are different animals and screen buttons can do either or both.

'Clicked Script' would run Lua code one time when the button was used, and it sees a mouse click as a singular event. This would not work for jogging. There are a bunch of 'actions' defined for use with screen buttons. For example Jog X+ and Jog X off which are in the mouse down and mouse up entries in the standard MACH4 screen jog buttons.

To send a signal based on machine state would require monitoring. A way to do that is with the PLC script which runs continuously. All of my code for the joystick jogging is in the PLC script.

here is a fragment showing a way to monitor the machine condition:



--InTurn Code
EstopIssued = machEnabled;

-- Spindle power bar graph

--local EstopIssued = 0;
if (EstopIssued == 0) then
        mc.mcRegSetValue(EstopTOInTurnRegister,1);
       if ((scr.GetProperty('tbuttonSPIN','Button State')) ~= '0') then
          scr.SetProperty('tbuttonSPIN','Button State','Up');
       end
        local InTurnSpindleHandle = mc.mcRegGetHandle(inst, "modbus0/InTurnIN12");
        mc.mcRegSetValue(InTurnSpindleHandle, 0);
else
        mc.mcRegSetValue(EstopTOInTurnRegister,0);
end
       

have a look at this

http://www.machsupport.com/forum/index.php/topic,27190.0.html

This thread is no longer relevant. The problem being discussed was eliminated when enable was added to the buttons.

Buttons can be enabled by any of a long list of conditions.

I am not meaning using it for a on screen button yea you set it to idle under machine state to stop a button working when a Gcode is running

its to help work out a code so a button not on screen can be deactivated when a Gcode is running

this is about pendant`s not screen buttons your codes for modbus you can use a key sniffer type of pendant with out using modbus that what a keyboard is button bla,bal being pushed means do this

so what i have done is I have a key on the keyboard that puts the machine in estop what needs to run all the time, and i will have a button on the keyboard that zeros the dro`s i would not wont to nock it when the machine is running it. needs a code to stop the keyboard key working when a Gcode is running.

if there a another way to do it I am all ear`s

The purpose of the code fragment is 'showing a way to monitor the machine condition'.

Once the condition is detected, the data can be used in any way you want. In this particular case it was sent to Modbus because the device needing the data was on the Modbus. Obviously, you would just as easily send the data to a MACH output pin, thru any number of devices that have accessible plug-ins, and so on.

The PLC script supplied with MACH already has a lot of examples to study. A great deal of it revolves around enabling and disabling controls, however, there is not a lot in the way of communication with external devices, hence the fragment. My PLC monitors a bunch of stuff and communicates with several external devices. The fragment I posted is related to monitoring the enabled state.

Modbus really makes no difference in LUA scripting other than the registers have a different identifier.   Replace 'modbus' with 'gRegs' in the fragment and the data goes to a different place, but the code is the same. There is no mobus specific code in the fragment.

I am not familiar with the keyboard plugin, but presumably it is bi-directional and there is some method of communicating with it. Replace the screen button calls in the fragment with whatever the appropriate commands are for the keyboard plugin.

Likewise, if you want to monitor G-code, you would replace the machine state with the appropriate call to detect G-code execution.

I am not meaning using it for a on screen button yea you set it to idle under machine state to stop a button working when a Gcode is running

That's not actually what it does. Mach being enabled does not indicate that it is running G-code. The screen button is just switched off, not enabled or disabled.

If one considers a control as a whole, then the break (disable) can happen anywhere between the input and the resulting action. In my device, the joystick features encoders instead of pots and it communicates over I2C using interrupts, so it is not a good place to try to pull the plug on communications. Therefor the 'break' is done in the MACH PLC.

In other words the data flows in continuously and the PLC simply ignores the data if the joystick is 'disabled'. An Arduino DUE processor is collecting the data and running Modbus, so that device could also 'disable' the joystick. It would need (as an earlier post suggested for a touch screen) a signal from MACH to 'disable' and it could then simply stop sending data. There are a couple  of other ways to accomplish a 'disable' and it is up to the developer to decide which is 'best' in a particular application.   I'm just throwing some ideas on the table.

so what i have done is I have a key on the keyboard that puts the machine in estop what needs to run all the time, and i will have a button on the keyboard that zeros the dro`s i would not wont to nock it when the machine is running it. needs a code to stop the keyboard key working when a Gcode is running.

if there a another way to do it I am all ear`s

As I described above, you should not restrict your thinking to 'disabling a key', but rather as a signal path that needs to be broken somewhere between the user's finger and the final action taken by the machine.. There are undoubtedly a number of ways to accomplish that goal.  If you can describe, in detail, exactly how the data gets from the key to MACH4 and how you plan to collect it inside of MACH, then I can assist.

well how about this I needed a code what will run under a type of state

be it a key board key connected to input 0 through the key board plug so when you pouch it, it stop`s the machine running only when the machine is enabled and a Gcode is running

or a key on the keyboard that will zero all axis connected to input 1 through the keyboard plugin having it working only when the machine is enabled and no Gcode is running

the other way is how I have the Estop key done input 3 through the keyboard plugin it is on a key on the keyboard and I have no extra code with it what means it will work anytime the machine is on but it wont enable the machine just disable it I have it set in M4 config under inputs as Estop keyboard at input3 in keyboad plug its Estop, selected key

so there is two types of state code needed, one when enabled only, one where if the machine is enabled and a Gcode is running it wont work, but will work when a Gcode is not running and the machine is enabled

setting a screen button to idle under machine state does stop a screen button from working when a Gcode is running its the simple way of doing it I tested it with the Estop screen button it did not work when a Gcode was running it did when no Gcode was running.

your fragment is not quite the correct fit for this yes the code will have to go in the PLC for different state control of the non screen buttons

this is with a keyboard only nothing else setting a key to a action in the keyboard plug tyed to a input in M4 inputs.

when it does not matter what state the machine is in it does not need any code, unless you needed it to change the state of the machine.

the other blocks will know how to do it they just give hints here and there, daz may well have worked it out I am not 100% sure how I wont to go about it yet so I cant be more clearer than what I have put above