Advanced Search

It is possible to do ohmic sensing from the tip. At least it is on a Hypertherm 30XP using relay ohmic, I imagine it would work the same with a THCAD. I have been doing this for a few years now without any issues. The only mod to my torch from memory was to insert a diode, the inspiration was from   here  and  here .

Got a THCAD2 from www.welectron.com in Germany a few days back, not installed yet as it was freezing lately.
Updates when i get to using it a bit, although i see no apparent reason for any difference from THCAD10 and THCAD300 i used before.

For now I am using the period as a base for calculating the frequency. Looks good so far. I will have to test for a while, but I think it should be fine now. Thank you for all your inputs!

there is no comparison. Linuxcnc's QTplasmac, a Mesa 7i96 and a THCAD2 will give you a high end system for almost nothing. Its feature set is very extensive. The difference is that the THC is managed internally by Linuxcnc, not an external THC so the system knows much more about what I'd going on and has much more ability to provide consistent results.
This is quite an old video but it shows what you can do

And the cut recovery features

nothing comes close!

Hello, my name is Daan Bent, 28 years old, and I’m from the Netherlands.
At the moment, I’ve started working on the mechanical design of a DIY plasma cutting table, with an option for a 4th axis to also cut tubes. For now, I want to focus on cutting plates, but I’d like to have the hardware prepared for a 4th axis later on.This brings me to the first problem I’m facing: I’m hesitating between Mach3, myplasmac, and LinuxCNC software/hardware. Given the forum, most of you will probably suggest going for Linux. My programming experience is very minimal, but I’m willing to learn and find it quite interesting. Do you think it’s doable? The advantage of myplasmac and Mach3 is that they seem easier to use in my opinion, but the options with Linux seem endless.Here’s the start of the design for my table, tips are of course very welcome! Over the next period, I’ll be focusing on the design of the mechanical part and diving deeper into the hardware and software.

 

I think one can not take for granted that EL3061's signal ground is the same potential as the workpiece ground. If you are lucky it might work, but to be on the safe side the torch signals should be isolated and free to float.

I had a quick look at the manual and I saw something that indicated the drop to zero was an index mark. My guess is that one of the PDOs needs to be set to remove it.

As I said earlier in the Ethercat world, a 0-10 volt analog input is probably a better choice but I have not tried one (assuming the plasma cutter has a voltage divider).. The EL3061 for example offers 500 volt isolation which is similar to the Mesa THCAD. To scale the voltage you would just need to use a mult2 component, send the output to QTplasmac and set the Qtplasmac offset to zero and the scale to 1.

If the pulse length method works for you it is even better. 100 ns resolution between two rising edges gives 0.1 Hz resolution and seems to be updated every cycle.
 

Yes, indeed. However since the drops seem to be random, I am not sure if it is related.

The manual also states that no frequency measurement is possible if the counter is blocked by the gate, but that in this case the period can be measured regardless.

And further: If an encoder signal is only present at input A/A and the frequency/period is to be measured, the terminal must be set to “Enable FWD count” in CoE 0x8000:03 [} 155].

   

I looked through the EL5101 docs and - did I get it right? - it measures frequency by counting number of edge rises during a 10 ms window? Could be where 10 ms comes from. Seems low resolution also, frequency will be in steps of 100 Hz.

Yes, it consistently appears to be around 10ms.

However, I believe I’ve found a workaround. I have noticed, that the EL5101 outputs the encoder period which is an absolutely stable signal. So I wrote a custom component to calculate the frequency based on it, which in turn can be used in PlasmaC. In the attached Halscope screenshot, you can see the troublesome frequency signal with drops from the EL5101 in red, the encoder period in cyan, and the calculated frequency in green.

Is this possibly a EL5101 bug or latency /communication issue?

Is the dropout always 10 ms? If so that more suggests a bug  or
communication/driver problems than electrical issues.
 

I have redone the cabling between the EL5101 and the THCAD300. Unfortunately I was unable to measure the min/max voltage on the 5V supply from the EL5101. So I have switched to a dedicated 5V power supply to power the THCAD and used a new twisted pair of cables to connect the differential signal to the A+ and A- phases of the EL5101.

Unfortunately the issue persists. Drop length is about 10ms and seems to be at random intervals. Frequency goes from 1824 Hz at 0V down to about 25 Hz. Divider ratio on the THCAD is currently at 1/64.

The second EL5101 with the THCAD2 for ohmic sensing behaves the same way. However for ohmic sensing, the drops are not really critical and and functionality is still given. Different story for the THC which raises the torch on every drop.

As the OP said, the missing piece in an Ethercat build is affordable encoder inputs for spindles. There are very few options outside of Beckhoff. I have some Beckhoff I/O but have not bought an encoder module.

There are a few I/O modules generally with 16 inputs and 16 outputs. There must be a cheap Ethercat chip they use. Examples from Deiwu and Rtelligent (I have both). Rtelligent includes some PWM outputs.

But lets face it, the main reason one goes with Ethercat is to use Ethercat servo and stepper drives so the Mesa cards with analog and step/dir interfaces are not particularly useful any more.

Using Ethercat drives reduces the need for I/O because most drives have some included I/O for home and limit switches and brakes etc. These can also be used for general I/O.

Whilst using hm2 over Ethercat should  improve network latency issues with Mesa cards due to the more efficient transport layer, adding the additional complexity of Ethercat just for this does not make sense to me.

Perhaps Mesa could look at an Ethercat 7i92 equivalent that supported some existing daughter cards to give I/O, encoder, counters for MPG and analog voltage by adding a THCAD2 with its Calibration data stored in Ethercat registers? Perhaps this card would include some  smart serial interfaces too?

Anyway, I'm gonna go back to fiddling with Ethercat internal homing now...  After a long hiatus, I got my homing lab working last night and homing commenced as it should. I just have to work out why it didn't respond to the homing switch when it came on...

THCAD-2 two pieces just ordered. Regarding CPC port: are we talking about Hypertherm Part Number ‎428653?