I have been working on trying to get the latest plasma build to work and ran into some strange issues today.

My machine uses a PMDX-410 USB SmartBOB connected to a PMDX BOB. I am using PMDX plugin version 0.52.254 because I had signal problems with the latest update.  This machine is fully functional on the GA release of Mach4 (build 3804), obviously without the Touch and Plasma features.

I started today with a clean install of build 4225 and didn't transfer anything over from previous profiles.  I am using the  defaule Mach4_Plasma Profile.  Once I configured I/O, Motors, and the PMDX plugin, I added the latest configs for the slave Z motor, enabled the THC ON signal, and setup the new Plasma Screen Configuration panel.  Note: I have not connected an arc voltage signal yet so I am running in THC manual mode for now.  I will get back to that later.

Once I homed all axes, zeroed up a piece of stock, and loaded a test file, I started testing.  Some things seem to work as expected:
-With torch powered off, the code will halt at M3 because there is no arc OK signal.  It will timeout and stop.
-with the torch on, I noticed that M3 now has a touchoff routine built-in.  This is great progress guys, I need to learn more about it.

Here is what didn't work correctly:
-The "Omit Touchoff" button initially lead to a probe move down until probe signal comes on, hung the Touch function, and then crashed Mach.  Restart required to get back into action...
-With the Touchoff routine enabled, the machine would touchoff correctly, zero the Z DRO, move up to my pierce height, fire and make the first cut.  The second M3 command would initiate a Touchoff, seek down until probe signal on, then hang.  The errors are 'PMDX DEVICE ERROR 'SYSTEM ERROR(7): Motion Calc Underrun' followed by "MACRO ALARM:3 MERROR_NOT_NOW"

For unknown reasons, the Omit Touchoff button started working after several restarts of Mach, I didnt change anything.  Unfortunately the Touch feature still hangs after the probe signal lights up.

Can anyone help me step through the config, and debug the error I am seeing?  I feel like I am close to having a fully functional plasma rig, I just need to work out the kinks. 

Thanks a lot,
Jamie

Hi jamie325i

I am having similar problems to the ones that you describe...so I thought I would add them into the mix...

I am using MACH4 build 4225 (Plasma) with a UC400ETH motion controller... I am using a PROMA 150 for THC. I am trying operate using the Thc Mode == Digital.

The test file I am using looks like this...

F500
G0 G90 G54
G0 X0 Y0.000
M3
G1 X0 Y100
M5
M3
G1 X0 Y200
M5
G0 Z10
M30

When I run the program using the above file it runs fine when using Thc == Manual (effectively not using THC), and then when I run it using Thc == Digital it seems to be working fine until it gets to the second M3 command - at this point things get a bit random - sometimes it plunges into the steel, and sometimes it raises the torch above the "Max find distance" - the torch is moving up but the DRO is reporting that it is moving down.

Sometimes it seems like the program is getting conflicted between the OB1(6) motor and the Z(2) motor.

I seem to be fairly close to getting this going but it just isn't quite working yet...

I have be trying to get this going for some time now, so any help would be very much appreciated.

FYI...
I was getting concerned about the safety of my torch so I created a simple Arc OK signal emulator using an Arduino - it enables me to test the system without the torch or the PROMA connected. If anyone wants more info on this just ask. Hasn't helped me solve the problem

Thanks

Teak

Hi,

M3
G1 X0 Y100
M5
M3
G1 X0 Y200
Does the line X0 Y200 not mean that you are re-cutting a previous move namely X0 Y100?

I don't regard myself a plasma expert but I do know that if you attempt to recut or even cross over a previously cut line
the torch will tend to dive to maintain its arc voltage. Indeed 'anti dive ' strategies separate one THC system from another.

Second question......the THC module included in Mach4 is a Lua script and as such there is significant communication delay between
your motion controller and Mach (on the PC). As a consequence the speed of response (called bandwidth by control engineers)
will be low by comparison to a genuine hardware controller (also called realtime by control engineers).

Is it possible that you are expecting a speed of response that exceeds the capacity of the scripted solution?

Craig

Hi Craig,

Not sure why you would say that moving from X0 Y100 to X0 Y200 is cutting the same line - maybe I'm going daft.

My intension with the plasma is to have enough THC so that I can move across a sheet of steel at fairly slow feed and the THC will keep up - I think that is probably what the majority of what THC is needed for - certainly in our shop. Often a sheet doesn't sit level on the table - some times 10mm side to side - I am fairly confident that the response time will be quick enough. If and when I have the need to cut thinner steel at a high feed rate I may need to re-assess - probably go to a smaller nozzle, lower amps and feed at the same rate.

The Mach4 Plasma module is a Lua script - does this mean that it is totally independent of the motion control board - my intuition tells me that all of the THC control is done with in the software module - each time there is a signal from the PROMA to move the torch up or down, the software issues an instruction to the out-of-band OB(6) motor - the software then issues a command to the motion controller to move the z-axis Z(2) - as far as the motion contoller is concerned there is no difference between an OB(6) move and a Z(2) move...the only difference is in the software and its recording of the z-axis position.

Hmmm... at this point I'm not really sure what is the point of OB(6) - why not just move the Z(2) motor - something is not right with my understanding!!

I am trying to understand the above issues so that I can narrow down the culprit for the erratic z-axis behaviour. Is it the software? Is it the motion controller? Or is it the interaction between the two?

My current understanding is that the Mach4 plasma module is independent of the motion controller and if it is responsive enough - fantastic!

Teak

Hi,

Not sure why you would say that moving from X0 Y100 to X0 Y200 is cutting the same line - maybe I'm going daft.

Start at x=0,y=0 and travel to x=0 y=100. Then go back to x=0 y=0 and travel to x=0 y=200. The second move traverses
over the first move.

The Mach4 Plasma module is a Lua script - does this mean that it is totally independent of the motion control board - my intuition tells me that all of the THC control is done with in the software module

My understanding is that THC is handled entirely within Mach. Thus if the Proma issues an up command it is received by the
controller/BoB and transmitted to Mach. Note the controller/BoB has done no more than pass the signal on.
Mach then detects the command and issues an instruction to the motion controller to move up one step.
At that point the controller issues the pulses necessary to move the Z axis up.

There is, to my knowledge, no out-of-band axis that has anything to do with it. In fact under default Mach axis numbering
motor six, the first out-of-band axis is the spindle?

Craig

Then go back to x=0 y=0

Not sure where the instruction is to do this?


Using the OB1(6) motor is what is recommended in the Plasma Confiuration document included in the 4225 build document folder.

I would get the latest dev build and do a clean install of it, copy the default plasma profile as something unique and configure that unique profile for your machine. Old screens modules, macros, profiles, etc. may cause problems.

Yes, the THC module uses an OB axis to control the extra moves of the Z to maintain the set distance from the material. The reason it uses an OBA is because the only way to control a coordinated axis is through Gcode. OBA gives us a layer we can control independent of what the coordinated axes are doing.

Sounds like you should be running in Digital mode with the up and down outputs of your THC is mapped to the thc up and thc down input signals in Mach. Also make sure you have set the configure/plasma screen config. settings. What ever OBA you use, its motor should have the same motor tuning settings as your Z.

Make sure you play with the THC settings to get it all dialed in for your machine. Adjust rate, min, max, etc. I would start with very low adjust rates and a large window (min, max).

Not all motion devices support OBA. I know THC works well with the ESS.

It is a software solution and while not as fast as hardware it should be fast enough for the vast majority of users.   

The way it works is really pretty simple. If the THC sends an up or down signal a velocity jog of the OBA at the adjust rate is started in the right direction. When no signal exist, your slower than anti dive rate, THC is off, etc. a velocity jog stop is called.

M5 basically just turns off the torch and moves the OBA back to 0.000 where it should have been when the M3 began.

Thanks Chaoticone

I understand it a bit better now - although I am slightly worried that it could be my UC400ETH motion controller's support of OBA that could be the problem.

I will try your recommendations on Monday morning when I am back in the shop and report back on how I get on.

Thanks again

Hi Chaoticone

I have been responding to this thread with the title ...build 4225... on closer inspection I have build 4162 - which is still the latest version available on the download page. You say in your post that I should get the latest 'dev' build - is that version 4225 or is this an erroneous number in the original post?

I will try downloading and installing the latest version on the website again - to see if a fresh install will help.

The download page doesn't seem to offer dev version downloads - is there a way I can get the latest dev version?

Thanks

On the machsupport page, go to downloads then scroll all the way to the bottom. There you will see the FTP site, home of dev versions and more.

Tom