- Posts: 12170
- Thank you received: 4153
Another plasma component...
- rodw
- Offline
- Platinum Member
-
Less
More
7 years 11 months ago #120660
by rodw
Replied by rodw on topic Another plasma component...
Forgot to say that we can use fperiod to measure time in seconds per servo thread cycle.
From the halcompile docs:
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.
The following user(s) said Thank You: phillc54
Please Log in or Create an account to join the conversation.
- rodw
- Offline
- Platinum Member
-
Less
More
- Posts: 12170
- Thank you received: 4153
7 years 11 months ago - 7 years 11 months ago #120661
by rodw
Replied by rodw on topic Another plasma component...
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
Warning: Spoiler!
Code:
#include <rtapi_math.h>
#define BUFSIZE 100 // number of readings to average torch volts
//float avgarcvolts(double tvolts, int iscutting);
float avgarcvolts(double tvolts, int iscutting)
{
// Calculates the moving average of BUFSIZE readings
static double buf[BUFSIZE];
static double *b, *p = &buf[0]; // pointers for beginning of buffer and current position
static double *e = &buf[BUFSIZE]; // pointer for end of buffer
static int wascutting = 0; // cutting state last time
static double sumvolts = 0.0; // Sum of readings in buffer
static int numreadings = 0; // number of readings in buffer
if(!iscutting && wascutting){
// Torch just turned off, so reset the variables
p = b;
sumvolts = 0.0;
numreadings = 0;
wascutting = iscutting; //and save the state
return(0.0);
}
if(iscutting){ // Arc_OK is on so lets start gathering data to average
*p++ = tvolts; // Save volts to the buffer and increment pointer
if(numreadings < BUFSIZE)
numreadings++;
if(p > e) // if we've gone past the end of the buffer, wrap to the beginning
p = b;
sumvolts += tvolts; // add the new reading
if(numreadings >= BUFSIZE)
sumvolts -= *p; // subtract the oldest reading (which is the one we are pointing at now)
}
wascutting = iscutting; //and save the state
if(numreadings)
return(sumvolts/(double)numreadings); // return Average volts
else
return (0.0); // catch divide by zero errors
}
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
Last edit: 7 years 11 months ago by rodw.
The following user(s) said Thank You: phillc54
Please Log in or Create an account to join the conversation.
- rodw
- Offline
- Platinum Member
-
Less
More
- Posts: 12170
- Thank you received: 4153
7 years 11 months ago - 7 years 11 months ago #120662
by rodw
Replied by rodw on topic Another plasma component...
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.
Code:
return(sumvolts/((double)numreadings + (double) 1.0)); // return Average volts
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.
Last edit: 7 years 11 months ago by rodw.
The following user(s) said Thank You: phillc54
Please Log in or Create an account to join the conversation.
- phillc54
- Offline
- Platinum Member
-
Less
More
- Posts: 5711
- Thank you received: 2100
7 years 11 months ago #120663
by phillc54
Replied by phillc54 on topic Another plasma component...
Thanks Rod, you have given me a lot to digest in those replies.
My cutter is a Powermax30XP which is a hand torch machine only. I will need to do a few mods on it if I ever get my table finished, although I have got a bit more done on it over the last few days.
My cutter is a Powermax30XP which is a hand torch machine only. I will need to do a few mods on it if I ever get my table finished, although I have got a bit more done on it over the last few days.
The following user(s) said Thank You: rodw
Please Log in or Create an account to join the conversation.
- rodw
- Offline
- Platinum Member
-
Less
More
- Posts: 12170
- Thank you received: 4153
7 years 11 months ago #120664
by rodw
Replied by rodw on topic Another plasma component...
Just back to the graph for a moment. What is being measured is the difference between average volts and current volts over the change in time (volts/sec.).
The torch stable operating voltage at about 102.5 volts before the kerf crossing.
With our guessed dv/dt threshold of 500, the kerf crossing would kick in at about 106.7 volts and the average at that time is 103.3.
We were not using a THC so I have no idea what affect that might make. I'm not sure, but I suspect that the servo thread is too fast for THC operations so it might be worth moving the THC to its own slower thread. This implies that it needs to be broken out of the component and run as a separate component. So a kerf crossing component in the servo thread might see the change before a slower THC component had time to change the height....
The torch stable operating voltage at about 102.5 volts before the kerf crossing.
With our guessed dv/dt threshold of 500, the kerf crossing would kick in at about 106.7 volts and the average at that time is 103.3.
We were not using a THC so I have no idea what affect that might make. I'm not sure, but I suspect that the servo thread is too fast for THC operations so it might be worth moving the THC to its own slower thread. This implies that it needs to be broken out of the component and run as a separate component. So a kerf crossing component in the servo thread might see the change before a slower THC component had time to change the height....
The following user(s) said Thank You: phillc54, tommylight
Please Log in or Create an account to join the conversation.
- phillc54
- Offline
- Platinum Member
-
Less
More
- Posts: 5711
- Thank you received: 2100
7 years 11 months ago #120725
by phillc54
Replied by phillc54 on topic Another plasma component...
Item 1:
A bit more research has turned up another variable, transfer height....
It seems that after touch off the torch should go to transfer height then fire. After ark ok and a delay it should then go to pierce height...
Should I add this in or should I stick to going directly to pierce height?
If I add it in then I guess the height and the delay need to be user selectable.
Item 2:
I have another idea about torch touchoff (or probing or whatever it should be called):
Add another input named probe which can be used for either ohmic or some other type of probe.
Add a variable named probe_offset which is the offset of the probe when activated to the top of the workpiece.
When probing:
If: we get a probe input then use this as the probe success.
Else: if we get a float_switch input then use this as the probe success.
A bit more research has turned up another variable, transfer height....
It seems that after touch off the torch should go to transfer height then fire. After ark ok and a delay it should then go to pierce height...
Should I add this in or should I stick to going directly to pierce height?
If I add it in then I guess the height and the delay need to be user selectable.
Item 2:
I have another idea about torch touchoff (or probing or whatever it should be called):
Add another input named probe which can be used for either ohmic or some other type of probe.
Add a variable named probe_offset which is the offset of the probe when activated to the top of the workpiece.
When probing:
If: we get a probe input then use this as the probe success.
Else: if we get a float_switch input then use this as the probe success.
The following user(s) said Thank You: billykid, tommylight
Please Log in or Create an account to join the conversation.
Moderators: snowgoer540
Time to create page: 0.745 seconds