Another plasma component...

phillc54 wrote:

Thanks John.
It looks like plasma is more complex than I thought, the more I learn the less I know...

x 2 Absolutely. I feel your pain. Its not really a good candidate for a beginner as his first CNC build. But what you are building will really kick ass when done!

If I knew what I know now when I started, I would have done another machine!

phillc54 wrote:

Thanks John.

Do you toggle the torch on and off or is it a momentary button so the torch is only on while the button is held.

Cheers, Phill.

I think I would toggle it. Press once for on and press again for off. The reason I say this is my Everlast plasma has a button on it that enabled this functionality.

My torch fire button is a momentary switch. If I where to do this again I would use the GUI switch to trigger a one shot so the torch can't be forced on too long.

John

phillc54 wrote:

Rod, have you done any more with your database?
I wouldn't mind trying to incorporate it in this config but I am not very database literate...

Phil, Its been busy so I've not done any more. I will try and get some more done on this by the weekend. What Plasma cutter do you have? Do you have cut charts for it? If so, send them to me or post here.

I was hoping to get a couple of different machines entered.

Whilst I'm very database literate and understand SQL well (I used to anyway), I've always had high level development environments to create the user interfaces. Its probably not that hard in Python but I'm relatively new to it. You need to think in terms of browsing a table (with up, down, add, edit, delete buttons) and a form to add and edit the item under the currently selected row.

Anyway, the good news is that I managed to get a 3 phase power point beside my plasma table this week but I just bought a lathe and need to catch my breath before buying a new plasma cutter!

Also, I had a good look at your code. We will need to do some work on the kerf crossing part. Rather than just looking at a change in volts, we need to look at a change in volts over time (dv/dt). From tests I did, it looked like a threshold of around +500 volts/second might work for void sensing. Once the void is crossed, dv/dt becomes negative (falling) so I think perhaps, the THC is enabled following a delay after the first positive dv/dt reading. But you have to have a working machine before you can tackle this.

This chart shows dv/dt at a kerf cross at 200 ms per reading. Horizontal scale is reading number (per 200 mHz)

I'm not sure that there will always be such a pronounced negative reading

. I've also written some non looping moving average code using c pointers. For use in kerf rrossing and torch sampling

Forgot to say that we can use fperiod to measure time in seconds per servo thread cycle.

From the halcompile docs:

Functions which use floating-point can also refer to fperiod which is the floating-point time in seconds, or (period*1e-9). This can be useful in components that need the timing information.

Found my averaging code



So in theory, this is what happens:
Once it sees an arcOK, it starts saving readings into a circular buffer using a pointer *p
Once the buffer is full, the pointer wraps to the beginning again. Effectively, this means that buf[BUFSIZE+1] = buf[0]
So in theory, the buffer should be full with an average calculated before the THC timeout enables THC operation.
Once the buffer is full, the oldest reading will be value in front of the current buffer position (eg. at *p+1).
So we calculate the sum of the readings by adding the latest reading and subtracting the oldest reading
We maintain a count of the number of readings so if the buffer is only partially full, it will still return a valid average

Just a couple of notes about the averaging. I only had one brief play with this and published numreadings to a debugging pin. I noted that numreadings was never > 99. This makes sense when you allow for C's zero baasd arrays. So I think we should return the following:
I have no idea about how big the sample should be and 100 is just an arbitrary number I chose. It might be 10 or it might be 1000, I don't know!

I was not keen on dynamically allocating memory with malloc() but I think you could do this in the EXTRA_SETUP() and deallocate in EXTRA_CLEANUP() functions. I did think of adding a pin to define the number of readings to read into a fixed sized buffer (of maybe 1000 maximum). I think that might be a good approach.

Anyway, I did think this was a pretty cool algorithm and code for an interrupt service routine.