Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: plasmastein on June 25, 2016, 05:29:47 PM
-
Hey all. We have just about finished this build, but I'm stuck on one issue that I was hoping for some guidance on achieving. First off, I'm running a CNC plasma setup using Mach 4 with an Ethernet smooth stepper which is hooked up to a Gecko G540 (Port 1 on ESS) for the x and y axis, along with a Hypertherm PHC unit (Port 2 on ESS) that controls the THC externally. Currently all axis's work including the PHC unit.
The problem that we are having is I have to tell Mach 4 to hold motion of the x and y axis's until it receives a signal from the PHC unit that the torch is ready to start cutting which is currently not happening. So essentially the machine starts moving before the pierce and height sensing process is complete. For single pierce cuts I can add a dwell in to make it seem like its working, but it was just a theory test.
The signal being sent from the PHC into the CNC is coming in on Port 2 Pin 9 on the ESS, so I'm assuming I can just write code that halts x and y motion if that signal is off, and subsequently allows motion when the signal is on.
My question is basically how to do this properly. I saw some examples in the included write-ups with Mach 4 that all seem to be beating around the bush of how to do this type of function, but I'm not experienced enough with Mach 4 or lua yet to really accomplish this. Do I have to disable and enable the axis' individually? Is there a global Hold function of some sort that is intended to do this? Any examples of anyone currently doing something like this would be much appreciated, as well as any other help.
Thanks in advance.
-
Thc is not implemented on the ess yet.
Thc, or wait for arc Ok won't function
-
Sure, but shouldn't I just be able to write a signal script that tells mach 4 to engage feed hold whenever this signal isn't present considering the only time it isn't present is when the torch is doing its initial height sensing?
-
Yes, you could do it via script, but I suspect that you would need to do the freehold within the m3 (torch fire) macro, so the sequence of events is
Move to xy pierce point (g00 x%% y%%)
Touch off (g31)
Reset z to switch or ohmic offset(g92)
Move to pierce height(g00 z%%)
Then the m3 torch fire macro
Which will need to have a wait statement,
Before pierce delay (g04 p%%)
And drop to cut height
Rob
-
How is the thc up and down and g00 and g01. Z axis motion controlled
-
Thanks for the input Rob.
Luckily, since the THC is a standalone unit (Hypertherm Sensor PHC) as far as the CNC is concerned its a very simple input/output. Here is what the process of cutting will be from Mach 4's viewpoint using your example from above:
- move to pierce point (g00 x% y%)
- send signal to PHC to turn on operation (currently using coolant m-code m08/m09 that outputs this signal)
- wait for motion signal from PHC into CNC
- resume with cutting/reading from g-code
- turn off PHC operation (m09)
I haven't tried it yet, but I added a few lines to the signal script in mach 4 that basically activates feed hold when the motion signal from the PHC (mapped to input0) is inactive. Now, I know that that code will cause some undesired effects for machine operation, but I think its simple enough to test and see if it actually syncs up with the torch with the cnc.
I came up with quite a few different ways to accomplish this, but not sure of the best/safest way to go about it. To be honest, I would like to get this done in some custom mapped M-Codes because it would seem the most logical way to do it to me, but I need to find somewhat of a clear all variables code that would let it work, but I just haven't seen that browsing around in the API.
Am I on the right track with this? Thanks for the thoughts.
-
you are on the right track, unfortunately I'm not your man when it comes to lua and mach4 unfortunately...
I'd suggest M-codes are the way to hold this motion inhibit (whether its within M03 or M08)
I know there was a bit of a "bug" (maybe it was designed that way... ) within Mach3 where as whenever you use any other Mcode than M3 to turn the plasma torch on the THC functions don't or won't work within mach. Now I know that this does not apply to you as all your THC is within the hypertherm box, but its just a message for anyone else reading this in the future .... if and when THC becomes available in the ESS (more when ass I know it will be done).
Rob
-
Thanks again Rob. I'm hoping there are some lua guru's around that might have an answer.
-
Here is an idea - no scripting required. I haven't tested this, but it *should* work (famous last words) based on what I know about the spindle operation. You will need to change to using M3 to fire your torch and M5 to turn it off (i.e. map the "Spindle On" output signal to your "torch fire" output instead of the "Coolant On" or "Mist On").
(1) Go to Configure->Mach, and on the "Spindle" tab, in the first row (labeled "0"), set the "MaxRPM" to some non-zero value, say 100. Set the "Accel Time" to some VERY large number of seconds, way beyond the worse case time you expect the torch to be ready (say 3600, or 1 hour).
(2) In the "Input Signals" tab, scroll down to the bottom of the list and look for "Spindle At Speed". Map that to the ESS input that corresponds to the "Torch OK" input (ESS port 2 pin 9, according to your first post).
(3) In the "Output Signals" tab, un-map the "Mist On" or "Coolant On" from your torch fire output pin. Then map "Spindle On" to your torch fire output pin.
(4) Click on "OK" to save all of those changes.
(5) Edit your GCode file and change all of the M7 or M8 commands to "S100 M3". Also change any M9 commands to M5.
What this *should* do is when Mach4 executes the "S100 M3" commands it will turn on the spindle to 100 RPM (RPM is irrelevant to your use but crucial for the next step). Mach4 then waits for either 3600 seconds *OR* the "Spindle At Speed" input to go active, which ever comes first. When your torch OK signal goes active it tells Mach4 to stop waiting for the spindle accel time and go ahead to the next instruction. If the torch somehow is never able to start, hopefully 3600 seconds will be enough time for someone to manually halt the program.
If that doesn't work, or it too kludgy for you...
How about coding this in the M6 tool change macro? Or pick an otherwise unused M code (such as, say, M10 through M45, according to the "Scripting Manual.pdf" page 10 under "scriptable M Codes). Then just insert this M code in you GCode file after the M7 or M8 that turns on the torch. You will need to map the "torch OK" signal to one of the Mach4 "Input #" inputs, and then read the value of that input in your Lua code and wait for it to go to a "1".
Bob
-
Hi Bob:
Thanks a bunch for that walkthrough. That's actually how I originally had this machine setup, but I didn't mess with the spindle configuration, so I will definitely try this today. That might just work and eliminate the need for the extra code work.
I tried to sorta reverse engineer the idea of using a tool change macro through an M-Code yesterday, but I always seemed like I was missing a step. For example, I can make one M-code that would activate a feed hold command, but how would I make another M-code that could monitor an input signal to re-enable machine motion. I believe I'd need to make a register for that signal, but I'm just not sure yet.
I will try the spindle method though first today to see how it works along with some other ideas I came up with and will report back.
Thanks much for the ideas.
-
The external THC handles all Z motion, and lighting the torch. All you need in M4 is an output to tell the THC to initiate the cut. After the THC does it's thing and lights the torch, it sends a signal to M4 to move. At the end of the cut, M4 needs to signal the THC to end the cut cycle. THC will shut off the torch and retract to safe Z. The THC then sends a signal to M4 to continue to the next cut...and the whole thing repeats.
Basically, you need a M code that triggers an output then loops while waiting for an input to go active. I'd put a time limit on the loop so it the THC somehow fails, the M code will exit rather than locking up M4. The output is to initiate the cut sequence and the input is the signal from the THC that it's OK to move.
At the end of the cut, either fire another output to end the cut sequence or just turn off the output you turned on to start the sequence. Depends on how the THC handles those signals. After the THC turns off the torch and retracts, it should signal M4 to move to the next part. To do this, you would use another loop in the "end sequence" M code waiting for that signal.
-
Thanks rrc, that describes how I would want to do this in an ideal situation. But do M-Codes have access to I/O signals by themselves? Also, what would the syntax be for a looping process to monitor when the signal actually goes off. I believe I know how to script an initial check, and I think I saw an example of a timer, but not a loop itself. Sometimes the Lua syntax can be confusing for me still.
Anyway, finally have some time to be at the machine to test all of these ideas. I'll keep progress posted here. Thanks much.
-
The pre-releases mentioned here http://www.machsupport.com/forum/index.php/topic,27039.msg227697.html#msg227697 uses a coroutine in the ref all home script. You will want too look at the ref all home button script, screen load script and the PLC script. This may be a way to do what you want and avoid a loop.
You may also be able to use a signal script.
I would look at some of the scripts that come with the defaults to see how to do lots of things.
-
Update for anyone interested.
- None of my coding attempts worked to code the actual input signal. Either I am just that bad at code, it was in the wrong file / position, or it just plain didn't work.
- Bob at pmdx's solution with the spindle works very well. However, I had to enable reverse in the spindle setup screen in Mach, and I had to make sure Const. Surface was selected in the General tab, as opposed to Const. RPM. I have no idea why, but doing those things actually made it work well. Thanks very much Bob. Huge weight lifted off my brain.
Just to elaborate further for future reference. I have to set the torch to fire during the height sensing process due to a very slight delay from when the THC commands motion versus when the signal is sent for motion. This I believe is a THC/plasma machine issue that I think I can solve. If not, then I can add a half second dwell after M03 to fix it so I can save consumables a bit.
Also, very occasionally, Mach will get hung up on the M05 command. Its inconsistent, so I think its just the demo version of Mach messing with functions. Luckily, I can finally resolve that issue tomorrow.
Chaotic - I'll check out that information next to see what its all about, thanks for the info. I did try using a signal script earlier, but it was either in the wrong place or my code is just bad.