Halscope of dv/dt during a kerf crossing
02 Jul 2019 23:31 - 02 Jul 2019 23:41 #138459
by mkardasi
Indeed, however, dv/dt is currently computed using (tvolts - avgvolts)/fperiod. Unless I can clean up tvolts increasing N samples will have little affect on a stable dv/dt. I have a much better capture attached see the annotation below.
My thoughts exactly! Phil mentioned what to modify to increase the range of his algorithm, which does exactly what you described. I will revisit it once I have a chance. I agree a moving avg inherently adds to delay to the resultant signal and intuitively that might cause problems when "real-time" is a consideration. I just don't have enough Halscope time to corroborate...
Here is my most recent capture of kerf crossing using dv/dt. I concluded that the noise is from the PAC supply so I disabled encoder.filter. plasma:arc-voltage-out is raw, thcad10.torch-volts is filtered with lowpass.gain 0.145, N samples = 10. To me this reflects a far better signal from which we can extrapolate.
Replied by mkardasi on topic Halscope of dv/dt during a kerf crossing
For mkardasi I'm a bit worried about the variation in the signal. I wonder if you should repeat the test with 100 readings and 1000 readings for the moving average. In theory, that should smooth out the average more.
Indeed, however, dv/dt is currently computed using (tvolts - avgvolts)/fperiod. Unless I can clean up tvolts increasing N samples will have little affect on a stable dv/dt. I have a much better capture attached see the annotation below.
Thinking that if there are no fluctuations bigger than 5 to 6V with the THC on, setting the THC to lock if the voltage changes by over 8 or 10V should do the trick nicely. Setting that inside of 2 readings might not work properly, but inside of 5 to 10 reading might work.
Averaging 1000 samples is not an option as that is 1 second and when cutting at 6m/minute that would happen after 100mm of cut. At 100 samples that is still 1cm and at 10 samples 1mm .
My thoughts exactly! Phil mentioned what to modify to increase the range of his algorithm, which does exactly what you described. I will revisit it once I have a chance. I agree a moving avg inherently adds to delay to the resultant signal and intuitively that might cause problems when "real-time" is a consideration. I just don't have enough Halscope time to corroborate...
Here is my most recent capture of kerf crossing using dv/dt. I concluded that the noise is from the PAC supply so I disabled encoder.filter. plasma:arc-voltage-out is raw, thcad10.torch-volts is filtered with lowpass.gain 0.145, N samples = 10. To me this reflects a far better signal from which we can extrapolate.
Attachments:
Please Log in or Create an account to join the conversation.
02 Jul 2019 23:45 #138463
by rodw
Replied by rodw on topic Halscope of dv/dt during a kerf crossing
Oops, I missed the note on the originating thread. So reposting below:
I agree 1 second might be too long but maybe 10 readings (0.01 sec) is too short....
This is probably as good a plot as any of an Arc establishment and cutting normally without THC (Everlast 50 amp)
And arc establishment, crossing a kerf and running off a sheet
Close up
And now with plasmac close up of the original one we've been discussing no THC (Thermal Dynamics A120)
So you can see the arc voltage peaks quickly during piercing (why we use a THC-on delay ) then stays very stable.
Also its clear that better quality machines have a much cleaner torch voltage but some of that could be due to me adding stuff to counter noise on the Everlast. So you have a much better process control signal if you spend the money.
The rate of change is a much better indicator of kerf crossing because it is several orders of magnitude higher than what can happen from normal warpage (but with the plasmac THC, this should be very little).
We are going to nail this eventually.
I agree 1 second might be too long but maybe 10 readings (0.01 sec) is too short....
This is probably as good a plot as any of an Arc establishment and cutting normally without THC (Everlast 50 amp)
And arc establishment, crossing a kerf and running off a sheet
Close up
And now with plasmac close up of the original one we've been discussing no THC (Thermal Dynamics A120)
So you can see the arc voltage peaks quickly during piercing (why we use a THC-on delay ) then stays very stable.
Also its clear that better quality machines have a much cleaner torch voltage but some of that could be due to me adding stuff to counter noise on the Everlast. So you have a much better process control signal if you spend the money.
The rate of change is a much better indicator of kerf crossing because it is several orders of magnitude higher than what can happen from normal warpage (but with the plasmac THC, this should be very little).
We are going to nail this eventually.
Please Log in or Create an account to join the conversation.
02 Jul 2019 23:51 #138466
by rodw
Can you tell us about your plasma hardware (make, model, HF or Blowback start, voltage divider?)
Personally, I think from my experience adding a mains EMI/RFI filter as the power enters your control box will make a huge difference to the noise in your signal. You really need to deal with that first if you can as its a very poor process control variable in its present state.
Replied by rodw on topic Halscope of dv/dt during a kerf crossing
For mkardasi I'm a bit worried about the variation in the signal. I wonder if you should repeat the test with 100 readings and 1000 readings for the moving average. In theory, that should smooth out the average more.
Indeed, however, dv/dt is currently computed using (tvolts - avgvolts)/fperiod. Unless I can clean up tvolts increasing N samples will have little affect on a stable dv/dt. I have a much better capture attached see the annotation below.
Thinking that if there are no fluctuations bigger than 5 to 6V with the THC on, setting the THC to lock if the voltage changes by over 8 or 10V should do the trick nicely. Setting that inside of 2 readings might not work properly, but inside of 5 to 10 reading might work.
Averaging 1000 samples is not an option as that is 1 second and when cutting at 6m/minute that would happen after 100mm of cut. At 100 samples that is still 1cm and at 10 samples 1mm .
My thoughts exactly! Phil mentioned what to modify to increase the range of his algorithm, which does exactly what you described. I will revisit it once I have a chance. I agree a moving avg inherently adds to delay to the resultant signal and intuitively that might cause problems when "real-time" is a consideration. I just don't have enough Halscope time to corroborate...
Here is my most recent capture of kerf crossing using dv/dt. I concluded that the noise is from the PAC supply so I disabled encoder.filter. plasma:arc-voltage-out is raw, thcad10.torch-volts is filtered with lowpass.gain 0.145, N samples = 10. To me this reflects a far better signal from which we can extrapolate.
Can you tell us about your plasma hardware (make, model, HF or Blowback start, voltage divider?)
Personally, I think from my experience adding a mains EMI/RFI filter as the power enters your control box will make a huge difference to the noise in your signal. You really need to deal with that first if you can as its a very poor process control variable in its present state.
Please Log in or Create an account to join the conversation.
03 Jul 2019 02:21 #138482
by mkardasi
Replied by mkardasi on topic Halscope of dv/dt during a kerf crossing
Following up to Rod's suggestions, that I might have interference on the mains...I plugged the control box and PC into a APC SurgeArrest Professional power strip with built-in surge suppression and EMI filtering. This is the resultant plot, I see no change in SNR: Note that thcad10.torch-volt is now the raw signal from the ESAB PAC supply, plasmac.arc-voltage-out is filtered with lowpass.gain = 0.118 & thcad10.average-volts is the moving avg of the raw signal with N=10 samples.
This is a zoom of the first kerf crossing.
My conclusion is that I don't believe that my signal noise is extraneous, there is nothing I can do about it in hardware (that I can figure out). Rather it is what is delivered by my PAC supply that is a design cira <1998. Going forward I intend on using lowpass to filter the incoming signal from the PAC and then route it into the component capable of dv/dt for further analysis.
This is a zoom of the first kerf crossing.
My conclusion is that I don't believe that my signal noise is extraneous, there is nothing I can do about it in hardware (that I can figure out). Rather it is what is delivered by my PAC supply that is a design cira <1998. Going forward I intend on using lowpass to filter the incoming signal from the PAC and then route it into the component capable of dv/dt for further analysis.
Please Log in or Create an account to join the conversation.
Moderators: snowgoer540
Time to create page: 0.287 seconds