Messages

81

Mach4 Videos / Re: Mach4 - Arduino and Touchscreen

« on: May 17, 2015, 10:08:58 AM »

The one in the video is an arduino leonado emulating a keyboard thus connected by usb, this was purely to show that the keyboard plugin can be used if required.

My question was not clear. The Arduino typically uses the USB physical connection to the computer, but it is not a native USB device. When it is plugged in, the USB buss discovers it and a driver loads which then emulates an old style serial COM port. The conversion is done on a single chip, usually from FTDI, but Atmel now makes a similar chip as found on the newest MEGA (and I think also the DUE).

It is my understanding that the Arduino can become a native USB device. I have not done this, so I know little about it, including if it requires a separate 'shield' like Ethernet.

So to ask the question another way, does the keyboard plug-in talk to a COM port or only native USB devices (typical keyboard)?

And they do a Ethernet version.

An Ethernet version of what? The Arduino or the plug in.?

Yes the keyboard plugin does have its drawbacks, only this morning mach4 was in the background whilst I came to have a look at this board (did you and daniellyall stay up all night??)

Can't speak for anyone else, but I am a consulting engineer and my hours typically match the location in the world where the project is. I've tried getting 20 other engineers on-site to teleconference with me at 3AM their time, but so far, not much luck with that . . .

Although even that dont put me off the keyboard principle, its all down to what you can achieve in the PLC script, IE most things are safer to run in the PLC a simple function, if wxlua screen lost focus then dissable keyboard plugin etc.

I don't know much (actually nothing at all) about the keyboard plug-in, but certainly it is another avenue into MACH that does not require programming, so that's a good thing. I am not, however, a fan of USB.

I think it would be correct to say that fundamentally there are three ways to get stuff in and out of MACH4, those being a plug-in (usually only made for a specific device), plugging into an actual or pseudo screen button and launching the desired actions from the button (either by 'action macro' or scripting), or via the PLC script. BTW, 'action macro' is my own term. I don't know if there is an 'official' name for these guys, but the term 'action' is used in the button setup, so there you have it.

For those who know how to program, the PLC script is extremely flexible and powerful. The MACH team recently added a separate thread (processor thread, not forum thread) dedicated to running the PLC script, so there is almost no practical limit on what you can run in there, and there seems to be access to everything from there.

82

Mach4 General Discussion / Re: MACH4 - Modbus

« on: May 17, 2015, 07:36:41 AM »

This is a MACH3 Modbus question, but is related to MACH4. I have done a forum search and did not find an answer.

I have been tinkering with 'bitpacked' registers in MACH4 TCP Modbus and it all seems to work fine . . . BUT . .

My device currently works with both AMCH3 and MACH4 and before I change over to using bitpacking in MACH4, I would like to know if the same function is working reliably in MACH3 TCP Modbus. I have read variously that is works and also that it is broken. Certainly I could just try it, but even if it works, that does not necessarily mean it is reliable.

What is the current status of bitpacking in MACH3 TCP Modbus?

83

Mach4 General Discussion / Re: Mach 4 Bug Reports

« on: May 17, 2015, 07:14:36 AM »

If you have physical switches tied to your jogging inputs and you touch a switch prior to enabling Mach 4 the motors will start moving and not stop!!!!!!

Type of controller: ESS

Looks like the "Enable/Disable" state isn't being checked in the Jog Function

My jogging device is interfaced more or less directly with MACH4 thru Modbus and the PLC script and I am not having the same issue. There are several people building and using jogging interfaces thru the keyboard plug-in and that seems to be working fine.

Since you are interfaced thru the ESS, it might be possible that the problem lies with the ESS and not with MACH4.

It sounds like an Uber-Nasty bug so you might consider posting it in the Smoothstepper area (if you have not done so already).

84

Mach4 General Discussion / Re: MACH4 with Pendant

« on: May 17, 2015, 07:01:03 AM »

Awesome. Good to hear someone is making progress.

I have made the decision to go with a standing pedestal with simple button controls rather than a joystick or dial. The only thing I wish I knew how to do would be to have DROs on the pedestal for Machine status and operator actions. But that will come in due time.

With the intent to replace a bunch of switches, buttons, a rotary knob and a 4 line LCD on one of my products, I bought a touch screen well over a year ago. By the time I started into that project, the MACH4 demo was out and the speed and power of the GUI was a game changer. I decided to nix the touch screen and use the real estate to add pendant functionality to the device.

Have you considered using a video splitter (or dual output video card) and having a small (and hardened) monitor on your pedestal? It would then be a (relatively) simple matter to add screens to MACH4 GUI that would be appropriate for the 'slave' monitor with big DROS and whatever other goodies you wanted to monitor.

85

Mach4 Videos / Re: Mach4 - Arduino and Touchscreen

« on: May 17, 2015, 06:50:08 AM »

Well done. Both the interface and the video.

The first time I had occasion to mess with the keyboard plugin was in the current 2441 release and it is broken       however, I read that the plug-in from the prev version can be brought forward and it works. Have not tried that yet, but I have noted that the pre-defined jog entries on the setup screen do not include an explicit JogOFF command, so it must be built in to a macro that is actually what the plug-in is calling.

That might explain a user report that MACH4 will imitate a jog while disabled, but the jog does not stop. That would be a nasty bug indeed. Are you experiencing this?


Couple question, if you don't mind;

Are you using the Arduino driver to talk to the plug-in via a COM port or are you emulating a USB device?

The touch screen looks like a 4D. I found it difficult to choose between the built in graphics library and the Arduino library. I was not expecting two vastly different methods and the need to choose one over the other.  Each has advantages and disadvantages. Which did you choose and why? I have decided against using the touch screen, but the dual methodology is still a point of curiosity.

86

Mach4 General Discussion / Re: Jogging/Pendant Interface-What is the best way? Ramblings

« on: May 17, 2015, 05:42:37 AM »

the answer is in the Mach4 scripting manual

Glad to hear you found your answer.

Hopefully other readers will still benefit from the time I spent here.

87

Mach4 General Discussion / Re: Jogging/Pendant Interface-What is the best way? Ramblings

« on: May 17, 2015, 05:31:10 AM »

Daniellyall,

You have provided a good description of the process you want to create, so I can speak to that and provide a process for you to follow to create a solution.

Your process makes a good general example as it is a bit complicated due to the number of dependencies. Because of that, you should consider doing a flow chart as a first step and make sure you have all of the combinations accounted for.

In the coding, you will handle the dependencies with nested statements. The code fragment that I posted previously was in response to someone else's post which was quite simple and had no dependencies.

Here is a code fragment that demonstrates the solution you need:


-- ****************** JoyStick Jogging Routine *******************

  if  JoyStickActive == '1' then
      SpeedX, rc = mc.mcRegGetValue(JoyStick_X_RegHandle);
      SpeedY, rc = mc.mcRegGetValue(JoyStick_Y_RegHandle);
      --ByteZ,  rc = mc.mcRegGetValue(JoyStick_Z_RegHandle);
    if JoyJogHoldX == '0'then
     if SpeedX ~= 0 then
      IsJoggingX, rc = mc.mcJogIsJogging(inst,0)
      if SpeedX > 0 then
       DirectionX = 1;
      end

  . . . . . AND SO ON

Please keep in mind that this is a fragment and not a program.  However it demonstrates one (of several) methods that are applicable to your project. only the 'functions' that begin with 'mc.mc' are specific to MACH4. The rest is typical variables and logic.

The basic process is to first collect the data into variables and then plug those into the logic.

In the example above (which is actual code from my PLC),
'JoyStickActive' is a variable that is set 'true' if the I/O line that carries that signal is high (value of 1 or true).
'JoyJogHoldX' is 'true' if the X axis is on hold (the joystick controls all axis simultaneously, so 'disabling' one axis allows fine positioning of a single axis).
'SpeedX' is a variable that contains the desired jogging speed.
'DirectionX' is self explanatory.

In this fragment, you can see the actual code used to collect the data from MACH. Of particular interest to you would be the variable 'IsJoggingX' and how and where it gets it's value from.

So, you will create your own variables using descriptive names and use the appropriate MACH4 function to fill the variables with the date. Then arrange your nested conditional statements (if this , then do that). Finally, when all of the conditions are met, you perform the action.

88

Mach4 General Discussion / Re: Jogging/Pendant Interface-What is the best way? Ramblings

« on: May 16, 2015, 10:51:05 PM »

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.

89

Mach4 General Discussion / Re: Jogging/Pendant Interface-What is the best way? Ramblings

« on: May 16, 2015, 10:07:26 PM »

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.

90

Mach4 General Discussion / Re: Jogging/Pendant Interface-What is the best way? Ramblings

« on: May 16, 2015, 09:01:24 PM »

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.