Problems with PoKeys57CNC Plasma plugin

[none]

Hi,

We are trying to setup our plasma gantry and was the time to look for a suitable THC. As far as I see CandCNC no longer sells stand alone THC only in a package/kit and from the US so we decided to go with PoKeys57CNC motion controller.
It's been 5 months and we still have issues with the plasma. I thought it's time to seek some advice.
We have a Hypertherm 45XP and running on Mach3 (paid license).

When we bought this device we saw that their plasma plugin is only in "experimental" state but we've been positive about this and hoped that it is going to work out of box. Unfortunately we were struggling from the beggining.
Their user manual is extensive but still quite basic. Plenty of information but eventually it gives very little guidance on settings. It provides just general info of their plugin but settings, options are not explained at all. We didn't know what option to select or opt and why.
We stepped further a little by contacting support and asking questions each time however Im not sure how this works out for them instead of adding working examples to their PDF.

I don't want to go through all problems we were having rather just point straight to where we are at at the moment.

Currently we have 3 problems.

1. Dwell time problem. In their plugin we should be able to add pierce delay (dwell) but the output is always in seconds and never in milliseconds regardless we use whole numbers or decimals eg. 0.1, 0.01. The output is always 1 or 2, 3 seconds. This causes a huge burn at piercing.
Yes we are aware of Mach3 Config ---> General Config choose G04 Dwell in ms option but it changes nothing. Output is always in seconds. We have contacted their support and although they always reply and try to help this hasn't been resolved and they didn't answer this problem.

2. I don't think this issue is Pokeys related but we have made a simple drawing that we try to cut on a 1mm mild steel. This must be Mach3 related but we just cannot find what causes this problem. Here is a drawing below that we used to generate G-code from Sheetcam:



Mach3 recognises the holes and simulates the movement however the results have been pretty terrific:



We started to wonder that the practical output could be different and this is why we never get a decent holes. We used a pencil on a paper and run the code again:



It shows that the biggest (20mm) and the smallest (5mm) holes are drawn by X and Y but the 10mm and 6mm holes are distorted and this is why we got quite bad results on the sheet metal.
Does anyone have any idea what causes this problem? Ive attached the G-code.

N0010 (Filename: 5cm-test-2.tap)
N0020 (Post processor: Mach3 flame with THC - G31.scpost)
N0030 (Date: 23/04/2019)
N0040 G21 (Units: Metric)
N0050 G53 G90 G40
N0060 F1
N0070 S500
N0080 (Part: 5cm-test-2)
N0090 (Process: Outside Offset, 0, T1: 1mm Mild - FineCut - Slow nozzle)
N0100 M06 T1  (1mm Mild - FineCut - Slow nozzle)
N0110 G00 X13.5848 Y29.7165 Z10.0000
N0120 G31 Z -100 F500.0
N0130 G92 Z-0.0800
N0140 G00 Z1.4000
N0150 M03
N0160 G01 X13.5848 Y29.7165 Z0.6000 F1000
N0170 G03 X17.4248 Y25.8765 I3.8400 J0.0000 F6000.0
N0180 X17.4248 Y25.8765 I0.0000 J9.7000
N0190 X19.4107 Y26.0820 I0.0000 J9.7000
N0200 M05
N0210 G00 Z10.0000
N0220 X15.5400 Y13.6451
N0230 Z1.4000
N0240 M03
N0250 G01 Z0.6000 F1000
N0260 Y11.2451 F6000
N0270 G03 X15.5400 Y11.2451 I0.0000 J2.2000 F6000.0
N0280 X17.2757 Y12.0932 I0.0000 J2.2000
N0290 M05
N0300 G00 Z10.0000
N0310 X35.9414 Y12.2332
N0320 Z1.4000
N0330 M03
N0340 G01 Z0.6000 F1000
N0350 Y9.2332 F6000
N0360 G03 X35.9414 Y9.2332 I0.0000 J2.7000 F6000.0
N0370 X37.7634 Y9.9407 I0.0000 J2.7000
N0380 M05
N0390 G00 Z10.0000
N0400 X39.1000 Y35.9943
N0410 Z1.4000
N0420 M03
N0430 G01 Z0.6000 F1000
N0440 Y30.9943 F6000
N0450 G03 X39.1000 Y30.9943 I0.0000 J4.7000 F6000.0
N0460 X41.0402 Y31.4134 I0.0000 J4.7000
N0470 M05
N0480 G00 Z10.0000
N0490 X54.1400 Y3.8400
N0500 Z1.4000
N0510 M03
N0520 G01 Z0.6000 F1000
N0530 G03 X50.3000 Y0.0000 I0.0000 J-3.8400 F6000.0
N0540 G01 Y-3.3000 F6000
N0550 X53.3000 Y-0.3000
N0560 X-3.3000
N0570 X-0.3000 Y-3.3000
N0580 Y53.3000
N0590 X-3.3000 Y50.3000
N0600 X53.3000
N0610 X50.3000 Y53.3000
N0620 Y-3.3000
N0630 X53.3000 Y-0.3000
N0640 X48.4712
N0650 M05
N0660 G00 Z10.0000
N0670 M05 M30

3. Today we wanted to run a simple test by cutting a straight line. Once the line is end to end the other moves back over the initial cut and turns off.
Each test shows some sort of delay. X,Y seem to stop earlier than torch would switch off. I think there must be a delay somewhere we just dont know what or what causes it.
Is it normal on thin metal or we missed some settings within Mach3? I assume this also contributes to the huge pierce delay (-> huge pierce hole) even when we don't have pierce delay set at all.



We asked Polabs. They claim that there is a delay in the pipeline of Mach3 that results delays but Im sceptical about it since others use Mach3 with plasma and they have pretty decent cuts.
I just would like to ask anyone if you can give help or advice that we could try. I really don't need THC recommendations.
Thank you

Similar Threads:

• Mach3 Galil Plugin ver 4.6 problems with servo motors and encoders
• Mach 4 and Pokeys57cnc
• Newbie- Pokeys57cnc connections
• Plasma THC & XBOX360 controller plugin
• Need Help!- Matty Zee HangyangVFD plugin - Mach3 --- Problems HELP!!!

[vmax549]

Are you using teh Mach3 THC plugin ?? Or something else ??

Check teh M3/M5 config setup and make sure there is no delays set for them.

(;-) TP

[none]

Hi,

I coulnd't find the settings that you have mentioned but I doubt we have anything set.
We investigated further this issue. We measured the delay between XY stop (arrive to end of cut) - M5 sent and see what time it takes to get actually an output on Pokeys CNC 57.
The delay we measured is 450ms. This delay is until Pokeys device output. After Hypertherm would probably need some time as well to turn plasma off. In our test we excluded Hypertherm.


Im not sure what causes this delay Mach3 or Pokey's but I have to assume that the main delay comes from Mach3 and some from PokeysCNC.
Whatever it is this half second delay causes a huge hole on thin metal such as ours. This is a good example when you purchase something in good faith hoping that it is going to work as intended to but the practical use proves otherwise.
Since it is important for us to solve and since I don't expect Mach3 fix (despite the news and videos Mach4 still doesnt support plasma and there is no proof that Mach4 would be any faster) we will give a try to UCCNC and Neuron THC.
Ive seen many good reviews of UCCNC and NeuronTHC. I hope they will solve it. If not I'll be back.

Still... if anyone has any ideas why we get different XY output on those circles please let me know. Would be a huge help.
Thanks

[Bob954]

Hi, I'm building a plasma table 2500X1500mm with the same breackout board. I'm coming from NVEM BoB and nowadays I still have a machine wich won't working.

I found your post because I have the same issue about dwell time. I'll keep you informed about any kind of solution.
Bye

[none]

I think we have given up on Mach3 and Polabs.
My support ticket of the dwell time hasn't been replied since and it's been 6 months now. I don't quite understand why a troubleshoot from the developer takes that long but we no-longer can wait.
I've contacted UCCNC if they have had any tests on the delay we also have (between XY stopping and M5 output) but they haven't replied neither. We have already received NeuronTHC and waiting for UCCNC motion controller.
If anyone is interested Im happy to sell our PokeysCNC57 setup which includes their voltage divider.

[Torchhead]

Here is the problem with MACH and any external motion system . Its not real time . The MACH parsing engine runs, sends the trajectory commnads to a buffer (typically on the motion card via the USB, or Ethernet chanel serially then the motion card reads the trajectory data and generates all of the pulses for each axis. So motion is delayed and runs after MACH That works fine until you have something that needs to happen in the motion stream or worse where an input has to be in sync with the actual motion . The external card has to handle the ouputs and the inputs (and THC voltage feedback to move the Z in real time) so its not a real simple timing equation. Warp9 (ESS card) spent a LOT of time dealing with the delay between MACH and the ESS card . We used their card for a long time (until we moved everything to LINUXCNC and their Real Time Kernel with no delays) and we had to get Art to come out of retirement and fix a bug to make it all work. That fix only works with our DTHC IV based THC. The Internal THC logic won't work with external pulse cards but you still have to use it for some features. As you found, doing real time THC takes a lot of knowledge about Plasma Cutting. Its not just routing with a flame. Lots of stuff and the simple MACH posts don't have a lot of features for higher end THC's. The Neuron guy has a quasi stand alone THC that does not need a lot of back and forth to MACH . UCCNC is motion card and software controller too and works with some of the less expensive THC's

TOMcaudle
CandCNC – CNC Control Electronics for Plasma and Router

[OlfCNC]

I'm using UCCNC and Proma 150 THC on my plasma table. I see non of the issues you described. I see no noticable delays.
Here are 2 videos where they use UCCNC and NeuronTHC and you can see no delays on this video either:

[none]

Thanks for the input. You can't just notice 450ms delay unless you use an oscilloscope to measure like we did. You wont notice and see the issue on thicker material eg. 2mm or above. Both video you linked is much thicker than 0.8 or 1mm.
Most of this delay may come from Mach3. What frustrating is that support ticket regarding dwell time hasn't been replied or resolved by Polabs.

[OlfCNC]

Thanks for the input. You can't just notice 450ms delay unless you use an oscilloscope to measure like we did. You wont notice and see the issue on thicker material eg. 2mm or above. Both video you linked is much thicker than 0.8 or 1mm.
Most of this delay may come from Mach3. What frustrating is that support ticket regarding dwell time hasn't been replied or resolved by Polabs.

450msec is about half a second, you can notice that in my opinion.

[rodw]

As Tom says, you need real time performance. By that I mean you need to guarantee that things happen when they are meant to happen with no latency. This is where LinuxCNC excels as it is the motion controller whereas with Mach, the ESS is the motion controller and it has far fewer resources at its disposal (eg. processing power and when compared with the awesome grunt of a 64 bit CPU). LinuxCNC has a servo thread that is typically called every millisecond (1000 times per second) and if that thread runs late, Linuxcnc will report it as an error.

But you don't need to purchase an external THC becasue LinuxCNC can do it all internally.

Here is an exampleon 2,mm steel around 2200 mm/sec



Sorry the probing is so slow, I was testing the probing accuracy for heights and had the probing speed wound right back and forgot to reset it.

[OlfCNC]

Mach3 and UC400ETH also controls the THC in realtime. What you wrote about mach3 is only true when using printer ports or maybe the ESS is also not realtime I don't know but the UC400ETH makes it realtime I know because that was my only question to the producers before I bought it.
But now I'm using UCCNC no more mach3 and I'm happy with it.

[rodw]

Sorry, you are wrong but I'm not really interested in prolonging an argument. Mach3 cannot possibly be real time when Windows itself is not a real time operating system. Windows is incapable of guaranteeing a process on a timer interrupt executes on time every time! Without any latency! The Linux PREEMPT_RT kernel can guarantee this and has some big backers behind it like BMW.
https://www.linuxfoundation.org/blog...nt-and-beyond/

The other Linux realtime kernel is RTAI But moving forwaard, PREMPT_RT will win the day.

So some of the latency experienced by the OP is a result of the operating system he's chosen to use, Some will be a result of the hardware he's connected. Take the time to read Torchhead's response. He's a THC manufacturer whose migrated from Mach to LinuxCNC. Tormach is another machine manufacturer who has gone down that path. There are a number of other manufacturers that have adopted LinuxCNC. I'm not aware of any machine manufacturers adopting UCCNC.

Seperately, I think perhaps the issue with the pierce delay is really a programming fault as t can't accept a fractional value (eg probably the wrong variable type used by their programmers.) This is not an issue with LinuxCNC becasue it can get down to milliseconds!

[OlfCNC]

You are wrong.The THC is handled directly by the motion controller hardware and not by mach3 so it does not have to be realtime. The microcontroller or FPGA works realtime on the THC signals.
The motion is buffered and therefor everything is realtime, because the motion controller has all motion information in advance before controlling the THC.

[rodw]

The difference is that a cheap arsed 64 bit Celeron CPU like the tiny J1900 I've mounted to the back of my monitor has so much more processing power than a simple FGPA. In any case, the ESS is attempting to be a motion controller yet is only capable of step generation at about 3 mHz. In my world I use the FGPA on my Mesa 7i76e to generate steps at up to 10 Mhz under the direction of THE_MOTION_CONTROLLER being LinuxCNC.

In my world, because the THC operates as part of THE_MOTION_CONTROLLER, I can do things that are simply not possible on a buffered environment becasue in my world, I know exactly what is going on every millisecond. eg. I know the current velocity v's commanded velocity, so I can hold the THC if velocity falls below say 90% of what was commanded. I can calculate the rate of change in volts per second so I can sense a void/kerf crossing, I can auto sample volts when I want to and I have the ability to use the power of LinuxCNC's High performance proven PID modules and the new external Offsets to take total control of the Z axis height (be it THC adjustments, pierce height or cut height) without any gcode. Heck, I can even sense when we are cutting an arc in THE_MOTION_CONTROLLER and calculate the radius and change cut parameters based on whatever algorithm I choose to code.

Furthermore, I can command precise adjustments to Z axis height based on the deviation of torch voltage from the desired set point (which I always sample so I don't need to worry about cut charts so much). For example, I know that torch volts varies with 99.8% confidence at 7.53 volts per millimetre. So rather than a dumb bit bang up/down approach used by most THC's to adjust the torch height, I can make a precise calculation on how much the torch height needs to be varied and apply that offset to the Z axis becasue I am THE_MOTION_CONTROLLER. Not only that, I can adjust that calculation every millisecond. It is these features that early adopters in the LinuxCNC world are throwing their external THC's in the scrapheap and are choosing to adopt LinuxCNC, THE_MOTION_CONTROLLER for THC.

Best of all, this system I describe is packaged and waiting for you to try on the LinuxCNC forum for free if you are not totally wedded to the Windows Operating System.

[OlfCNC]

Ohh, I'm not that fast that I could do things in milliseconds.
10MHz what the ... when most stepper drives can't take even 0.2MHz. I see that high frequency useless for my system and probably for most of the systems. Even 3MHz is much more than enough.

Thank you for the offer, it is kind of you, but I'm happy with my current system and I'm too old to learn a new operating system (Linux). How is it said? If it's ain't broken then do not repair it.

[joeavaerage]

Hi,

Here is the problem with MACH and any external motion system . Its not real time

That incorrect, the ESS handles THC on board without reference to Mach, ie realtime.

Warp9 have just released (approx. 10 May 2019) their new THC feature for Mach4.

Mach is still the supervisor and sends to the ESS the parameters to apply but the application of those parameters are done on board
without requiring intervention from Mach and therefore the communication delays associated with any buffered control system.

Craig

[shad71]

The Neuron guy has a quasi stand alone THC that does not need a lot of back and forth to MACH

TOMcaudle
CandCNC – CNC Control Electronics for Plasma and Router

Correct. Neuron this is a full stand alone THC and require to/from CNC only 3 IO signals - START (M3/M5), THCOFF and ARCOK - it's can be software or hardware signals - both can processed in same time.

Cortex ARM on board processor allow to make all calculations and controls in REALTIME. For example, the controller main cycle loop is 1 ms. This time is sufficient for measuring the arc voltage, filtering this value and processing in the PID controller.
From my experience I can say that if I increase controller main cycle loop to 15 ms and more - noticeable delay in torch height control.

Neuron plugin use Mach3,4 or UCCNC controls only as programming interface for operator. This is a cutting profiles (cut height, arc voltage, pierce height, pierce time and etc), plotting graphs for setup and diagnostics, controller engine settings.

[joeavaerage]

Hi,
the only problem with hardware THC units described by shad71 is they cause the loss of Z reference of the machine.

The machine has no idea how many pulses and whether they are up or down.

The current THC solution enacted by the ESS for instance accept up/down signals from a voltage measuring device and cause up/down
motion of the Z axis in realtime but additionally the number and direction of the pulses are copied back to Mach so that it
retains reference.

There is a delay (180ms by default in Mach4) between the up/down THC pulse and the DRO updating but the movement is realtime.

Craig

[shad71]

It does not matter, because Neuron is full stand alone. CNC controls doesn't even know about the z axis - only XY. Torch Z slide and plasma cutter under full Neuron control.

[joeavaerage]

Hi,
yes I fully understand, I have worked on several machines that have the Z axis that are controlled in that fashion and it works well for 2D shapes.

If you want 2.5D capability or the ability to vary the torch angle from vertical for the purposes of beveling then genuine Z (and more) axis control is required.

Craig