I've posted a video on youtube of the user interface for the Arduino THC I'm developing for my PP50. The video is at:
This gives an overview of the interface and functionality of the THC. I'll do a video later showing it in operation.
Printable View
I've posted a video on youtube of the user interface for the Arduino THC I'm developing for my PP50. The video is at:
This gives an overview of the interface and functionality of the THC. I'll do a video later showing it in operation.
I bet you feel like an expectant father, all the time and doctor visits are done. Now waiting for delivery time to see if it has 10 fingers and toes. Thanks for all your work we will wait for the finishing video and data.
Tom
Looks like it is coming along! The time you've spent on this will benefit the CNC plasma community - I know I'd like to use something like this sometime in the fu
I got the boards back for OSHPark.com in less than three weeks. They look really good and I couldn't help myself and had to immediately build one. The assembled Arduino w/ display and THC shield on the left is a reasonable size.
Attachment 9052
As you can see from the picture, I did find an error that I had to run some wires for. It's for the serial port. With the wires the transmit from the Arduino works, but the receive doesn't. I had trouble with the receive wire and think I burnt out the chip. On the transmit side, the max speed of the serial port on the bench (not the noisy environment of the plasma table) is 38400. Going faster would require changing that opto isolator.
I checked out the control button wiring and that all works well.
I checked out the op-amp filter with steady voltages (I skipped the voltage divider so I could test with 3.3v and 5v) and that worked okay.
I also checked the Arc Good, Torch Up and Torch Down outputs to the CNC that are opto isolated and they all worked.
I still need to test the Torch On input from the CNC and the plasma signals for Torch On ouput/Arc Good input.
Once those last three signals have been tested, I'll be ready to start testing it on the table.
Earlier, I used the Arduino to capture voltages while starting the pilot arc. I used those voltages to play with a lightweight software filter algorithm. I have a first pass, but that's clearly going to be where all the work is.
That looks nice. I will have to add OSHpark to my list. Looks like a very reasonable way to get boards made.
I bet there are some THC manufacturers crapping their pants right now!
I doubt that. :)Quote:
Originally Posted by SeanMurphy265
There's a lot of software to do as I learn more about how the torch responds while cutting. I know kerf crossing will be an issue.
Probably the biggest "drawback" of this design is that is relies on having a CNC interface on the plasma that provides an isolated positive torch voltage (like the PP50 does).
I finished rewiring the new proto. I'm hoping to get some time soon to give it a whirl on the table.
I've been trying to really understand how well the filtering is doing, but I kept getting corrupted data. I thought it was an issue with the terminal program I was using to capture the Arduino output. That was a little too convenient. On more thought I realized I was running into a hardware limitation.
The opto-isolators I used on the serial port can only support 38,400 baud. With 10 bits to a byte (start and stop bits are added to the 8 data bits with serial data), you get about 4000 characters per second. I was printing both unfiltered and filtered voltage in ascii every iteration of the control loop. The control loop runs every 1 millisecond. It ended up being over 10 characters per loop. So, I was trying to print over 10,000 characters/sec on a link that supports less than 4000 characters/sec. That was what was causing the corrupt data.
I have found new opto's that will support 10 Mbits, but I'll have to wait until the next hardware pass to implement them.
So that I could continue working, I spent the weekend making changes so that only one voltage is dumped per loop, and it's dumped in binary instead of ASCII. I also had to write a PC program to capture and decode it. On the plus side, It's the beginnings of a decent extended interface. (Picture below shows how it looks currently. Not all functionality implemented yet, but it can decode and capture voltage and status to a file.)
Attachment 9088
The other thing I realized is that I made a stupid mistake that could have a big impact. For the first prototype board, somebody gave me a filter cap to use on the voltage divider filter. It was similar to a ceramic capacitor. When I ordered parts for the second and third boards, I ordered electrolytic.
I've been used to using electrolytic in power supplies I'd build because they filter the voltage more by taking a charge and then releasing it as the voltage drops. That could be the reason the second and third prototypes have a slow response.
Now that I've finished the data capture app, I can test with the electrolytic and then take it off and see if the signal gets better.
That's probably not too big of a deal. candcnc sells a "RAV-01" arc voltage divider card for $41.50.Quote:
Originally Posted by EmptyNester
That card could give a better signal than the PP50 does anyway??
I would think running the loop at .01 second intervals would be plenty for torch height control. If you wanted to, you could go a little faster (.0008 or so) as well.
How many samples does the controller look at to compare and act?
Sorry for the delay Sportbike - just crazy at work.Quote:
Originally Posted by sportbike
I haven't used the CNC enough to know average cutting rates, but it seems that 200 inches per minute is the top speed I could find on tables recommending settings.
If you assume 200 ipm, you then have 3.33 inches/sec, which seems pretty fast when you think about the delays in signalling the steppers and getting them to start moving. It doesn't seem like its too fast when you consider that its only 0.0033 inches per millisecond. I guess it all depends on how much height distortion you want to deal with (my goal was a commerial THC demo that showed the torch stepping up and down a washboarded piece of sheet).
The other factor to figure in is the filter delay. In the Spice models, the hardware filter delay was around 15 ms. Then, there's a software delay on that. I just don't know enough about typical plasma cutting profiles to know what's appropriate. It seems that the fastest the Arduino can go is 1 millisecond. I want to run it as fast as I can because it will only slow down as I add more software capability.
I did just find a post on another board from a very sharp Hyperterm guy that said you only have to control to within 2 volts. So, I'm glad to know that and I think it's pretty reasonable to accomplish.
I've only had about 20 minutes a night to spend on this.
I did voltage captures with the new software with the electrolytic capacitor. I then removed it and did another capture. Turns out that the data was corrupted on the first capture, so I only have it without the electrolytic cap.
I also did another capture with a different resistor value in the op amp circuit. The Spice circuit simulator showed that it should have given dramatic improvement on the 60 hz noise on the line. Reality was very different. If ruined the signal.
So, I'm back to the original op-amp circuit resistor values. The captures are very clean and look really good. There appears to be 60 cycle noise on the line. I've ordered a couple common mode chokes to test and see if that will clean it up. If not, it's not a problem to filter in software.
Below is a capture of the raw "analog counts" value in red (it's about 7 counts to a volt). The green line below it is the value after software filtering. It's small, but on close examination you can see that the green line is very smooth. The filtering works great. It reads about a volt or two low, but that's easy to compensate for.
The filter algorithm is very lightweight, so it's fast for the processor. It is:
- new-value = old-value + (new_value - old_value)/20
Attachment 9116
The next chart shows the values read as volts.
Attachment 9117
From that chart you can see how stable the voltage is.
I'm really pleased with the performance. I just want to see if I can clean up the noise with a filter choke.
Because of the tip outside diameter there will always be a limit to how fast a transition the THC will be asked to deal with. The best example I saw of rapid transitions was hitting the diamonds on a piece of treadplate. You could see the torch making height adjustments going over them. At the other extreme is the corrugated roofing material that everyone seems to use for THC demos. I notice most use the sine wave type, I wonder how some of the more squarewave patterns would do.Quote:
Originally Posted by EmptyNester
It's funny, but I had never thought about how the diameter of the tip would be a factor. Sometimes you get your head so deep in the software, you ignore everything else.Quote:
Originally Posted by Rambozo
I would expect the square wave type wouldn't be nearly as good. What do you think the top speed is for a home CNC Ram?
Not without a 5 axis or better machine. ;) http://www.youtube.com/watch?v=q42zN2iFD5EQuote:
Originally Posted by EmptyNester
As far as speeds, I would say with good motors you can probably expect rapids around 200 inches a minute or better. A lot depends on the mass of the unit as far as motor tuning. For actual cutting speeds, I expect that to be limited by the output of the plasma cutter. Maybe in 16ga. or lighter you will hit full speeds, but it all goes down from there.
The 5 axis machine was pretty impressive.
I just got the nightly test done and tried two different common mode chokes (80uH and 200 uH). It looks like 60 cycle noise, but the chokes didn't make a difference.
I think what I have now is good to go with for a while. I think it might be time to do the second pass of the board to fix a couple things.
Can you send a copy of your data file to Pmantegna@gmail.com there are a few filters we use at work that won't cost much more processor time but will probably work a little better. I would lime to play around a bit with it.
I will - thanks.Quote:
Originally Posted by agent4573
Working on making the torch control algorithm a little better.
I'm not sure how fast the steppers will respond to on and off commands. I figured I'd set a larger "delta value" before torch up/down is requested, and a smaller "delta value" before it is turned off.
The "voltSetPoint" is currently in A/D counts, and about 7 counts is 1 volt. So I currently have the following values:Code://
// Run the voltage control.
//
//
// Handle case of where Torch Up is active
if (currentStateData.torchUp)
{
// Check to see if the torch is high enough.
if (currentStateData.currentVoltage >= (currentStateData.voltSetPoint - VOLTAGE_OFF_HYSTERESIS))
{
// Update display that torch is at height.
TorchGood(display);
// Set flags for torch at height.
currentStateData.torchUp = false;
currentStateData.torchDown = false;
}
}
//
// Handle the case where Torch Down is active
else if (currentStateData.torchDown)
{
// Check to see if the torch is low enough.
if (currentStateData.currentVoltage <= (currentStateData.voltSetPoint + VOLTAGE_OFF_HYSTERESIS))
{
// Update display that torch is at height.
TorchGood(display);
// Set flags for torch at height.
currentStateData.torchUp = false;
currentStateData.torchDown = false;
}
}
//
// See if the voltage is too low, and if so, move the torch up.
else if (currentStateData.currentVoltage <= (currentStateData.voltSetPoint - VOLTAGE_ON_HYSTERESIS))
{
// Update display that torch needs to go up
TorchUp(display);
// Set flags to signal torch up.
currentStateData.torchUp = true;
currentStateData.torchDown = false;
}
//
// See iF the voltage is too high, and if so move the torch down.
else if (currentStateData.currentVoltage >= (currentStateData.voltSetPoint + VOLTAGE_ON_HYSTERESIS))
{
// Update display that torch needs to go up
TorchDown(display);
// Set flags to signal torch down.
currentStateData.torchUp = false;
currentStateData.torchDown = true;
}
This should turn on torch movement when off by a volt and turn off torch movement when within half a volt.Code:#define VOLTAGE_ON_HYSTERESIS 7 // 7 counts = 1 volt
#define VOLTAGE_OFF_HYSTERESIS 3 // 7 counts = 1 volt
I tried some test cuts with THC control.
I started using a SheetCam post processor that would turn the THC off at corners when it slowed down. Then after the corner, it should turn it back on. For some reason, it turned if off and it never came back on.
I disabled the THC on/off in the G-code and did some cuts. It was "sawing" up and down a little too much during flat cuts. I ended up changing my control loop to tighter values to improve the sawing. I also increased the THC speed in Mach from 20 to 40, but I'm not sure if that was the right thing to do or made a difference.
After tightening the control loop to within 5 a/d counts (5/7 volt) it still "sawed" a little, but looked okay. (I think I need a better filter for tighter control.)
So, I inclined some sheet to see what would happen. I still have the problem that Mach won't allow the torch to go lower than the initial Z home value. So, I had to make sure the cut started at the lowest point. I was cutting 2" x 0.5" rectangles.
You can see the incline in the pictures. It is about a 3/4" elevation over 4.5". The right-most cut was the last one I did. On the very top of the cut you can see the rough edge from the torch going up and down.
Attachment 9221Attachment 9220Attachment 9219
I've had minimal time to work on this because my day job is really interfering with my hobby time. But, any time spent is forward progress - so I'm pleased with that.
I'm anxious to see if agent4573 can suggest a better filter algorithm.
This is a heck of a project - very cool! I'm envious - wish I had more time to devote to something like this. My first job out of college was real-time servo control of a high-speed (~100KHz frequency) high-accuracy (.0000625-mm) vertical actuator, quite similar in operation to the THC you're developing here. That may have been my favorite job to date! I didn't have too much of and hand in the filter design, but more of the software architecture around it and higher-level algorithm work. However, I believe that a properly-tuned PID controller loop (http://en.wikipedia.org/wiki/PID_controller) could be what you're looking for, if you haven't already tried it. I'm not the guy to help tune the various coefficients (sounds like agent4573 has expertise here), but I might be able to help implement and optimize the code, if you like.
This is dangerous for me - one more thing to put on the list of cool projects that I want to work on and occupy my time. I'll be watching with great interest - keep it up!
Thanks MuttonHawq.
I've implemented a number of PID's, but I'm more of a software guy than a math guy. I figured that the filtering would have to get more complex as time went on to deal with stuff like kerf crossings. I always like to start simple - but you are right, I probably need to start looking at PID's (though, that makes it more like work than fun).
I do need to do data collection on this so that I can see what the filtered voltage data and torch control signals look like. I just didn't have time last night.
I have been thinking about moving the the "Freescale Freedom" platform with a Kinetis processor because its cheaper ($12) and much faster (Kinetis, which is a 32 bit Arm processor), but it's 3.3 volts - so I thought I'd take it as far as I could with the Arduino before making that jump.
I really want to do the next pass of the hardware, but I just haven't had the time. Maybe if I get snowed in this weekend I can work on it.
Sorry for taking so long, got busy at work and all. Started looking at your data, but I couldn't get very far without one key piece of info. What was the sample rate of the data file you sent me? 10 samples/sec, 60 samples/sec? Can't do FFT's without sample rate. Thanks.
EDIT* Also, you gave the counts per volt, but what is the volts per inch value? Thanks.
No problem, I completely understand.Quote:
Originally Posted by agent4573
I assume that the sample rate is 1 millisecond. In past testing I found that it varies from under 1 millisecond to up to 7 ms. But, the average seemed to be around one. I updated the code so that it will run no faster than 1 ms. (The baud rate isn't fast enough to dump timestamps with data. I hope to fix that in the next rev of hardware.)
I can only guess at the volts per inch based on what i've read, but I'm under the impress it's around 0.015 inches/volt.
Do you mean the sample rate varies from run to run? Or varies continuously? Every digital filter I've dealt with needs a fixed time base, otherwise the filter doesn't work right. I'd think you really need to pin down that sample rate to something you absolutely KNOW, or you'll have a hard time getting stable results from your control loop.
I was seeing variability within runs. When I was capturing time stamps it turns out that I was dumping more data than the UART could handle due to limited data rates. Given that the code path didn't change, the occasional delay in loop time did fit the UART overruns.Quote:
Originally Posted by MuttonHawg
After fixing the data output, the variability appeared to be gone. But I'm limited in the amount of data I can output, so I didn't do any specific timing testing. And, in other testing the timing seemed okay.
But, if it were for work and I was asked by the FDA, I'd have to that I don't have any definitive testing to prove that.
So after looking at your equation, I think you're going to have a harder time correcting for "being low" than you think. Its low because it started at zero, and if you only had 1/20 the value of the next point, it will take a long time to pull the value to the "true" value. However, if you started with a high count value, you would be biased high and would be trying to pull to a lower count value. The problem is, without more code, you won't know if you started high or started low and which way to offset to correct.
I would use either of the following options instead. I didn't bother doing the FFT, because after fooling around a little bit, I think you're right that most of your noise is ~60Hz. The first option is to switch from using your equation to a rolling average equation. The first plot shows a 20 point rolling average, the second plot shows a 50 point rolling average. Assuming a sample rate of 1000 Hz(1 milisecond), this will give you .02 or .05 seconds of lag. If you're cutting at 20fpm (4 inches/sec), that gives you a 0.2 inch lag. I don't think any material will change a huge amount of height in 0.2 inches.
Formula:
value = average(value(i-19):value(i)) - for 20 point
value = average(value(i-49):value(i)) - for 50 point
Attachment 9232
Attachment 9233
I think a better option would be to just create an analog low pass filter with an RC circuit. I used a 2 pole Butterworth digital filter to create the following two plots. The first one has a cutoff frequency of 35 HZ, the 2nd one has a cutoff freq of 80 Hz. You can see how much noise is left in the 80 Hz plot. Any low-pass analog filter with a cutoff below ~30 Hz should completely remove the 60 Hz noise without it falling in the transition band. Here is a link on how to come up with the RC values of various order butterworths. http://www.electronics-tutorials.ws/.../filter_8.html
I tried higher order, but the higher the order, the higher the phase shift of the data and the more laggy it will become. Using the analog filter will also allow you to remove the lines of code from the control software and free up some processor power for other things.
Attachment 9234
Attachment 9235
As a final note, you may have better luck going to an open loop control mode. Instead of trying to control between 0.5 and 1 volt, you may want to try setting an upper and lower bound, and when you hit the bound, just move it ~.010 inches to correct. This will also free up processor power and give you a more stable sample rate, as it doesn't have to monitor voltage constantly, but just check it every 0.05 seconds or so.
A couple of points.
THC should not start collecting samples until after the pierce, so it will not be starting from zero. It will have the baseline height set in the CNC and should be at close to optimal cut voltage. In fact that might be the place to pick up the desired cut voltage as the control should have an exact height above the workpiece at that time. It all depends on if you want to enter a cut voltage or a torch height as your baseline.
Thin material like HVAC parts are often cut at frighteningly high speeds of several hundred inches per minute. (some can reach over 1000 ipm) They also have more extreme warping issues, where the THC has to make fast changes. So that amount of lag may not be acceptable.
I would also go with analog filtering as the best approach to filter the noise.
For a few bucks you can pick up a 4 or 8 Mhz pic chip and once the start up routine finishes and you get into the control routine you ahoud be on the order of 20 lines of code, that's maybe 100 processor cycles, add in 10 more for the digital to analogue conversion and you have maybe 150 processor cycles max between samples. On a 4 Mhz processor, that UPS your sample rate to over 26000Hz from 1000 Hz. that's cuts your delay on a 50 sample rolling average down to 0.002 seconds, or at 300 inches a minute, a .01 inch delay.
I'm currently using an Atmega2560 that runs at 16 Mhz.
I've done a lot of "old school" microprocessor stuff that's needed to be developed for speed. I figured this should be able to handle software developed for readability and extensibility (since I plan on open sourcing it when it works). So, while there's not a ton of processing in the loop, it's definitely not written for speed. (I used C++ classes to handle the different modes of operation.)
I had expected the op-amp butterworth filter to take care of everything, but it had a 100 hz cutoff (based on a recommendation from a "consultant"). After looking at some of the 2 pole butterworth filters I found a calculator that said for a 35 hz cutoff to use a 470 ohm and 10 uF. I can solder those on the existing board and just tie them into another analog input. So, I'll give that a try this weekend.
I had done some averaging over different ranges from 10 to 50 or 60. The problem with the rolling average is that to get a cleaner signal you ended up adding too much delay for high speed cutting.
Based on earlier discussions with Rambozo - I've been hoping to get sufficient performance for over 100 ipm.
All the voltage captures I do only start after the torch on signal. I know when Arc good is, but the voltage is still on the initial climb when that happens. I've assumed that the initial drop in voltage is when the arc transfers. AFter that there's a brief jump up. I don't know if that's after the pierce completes and before movement starts. I haven't been able to make sense of the timing.
The "cruise control" does work well though. You can set it in that mode and once it starts cutting, just hit the "select" button and it uses the current voltage for the control voltage. That was a great idea Ram.
Rambozo - assuming I'm just doing 18 guage mild steel as the thinnest, any idea on how what the maximum height change over a distance would be? It seemed like the 3/4" over 4" was pretty significant. I didn't seem to have any problem with that, though I was only cutting at 60 ipm.
I've seen one video where there was a pretty thin part and it sorta curled up from the heat and the heat sinking of the slats. When the torch finished I would say the edge was probably close to 2 inches above the slats. Now while I'm sure a lot of that was bad settings, the THC running that table had no problem in maintaining that cut. Of course there is that corrugated roofing material that everyone likes to demo. I think the PlasmaCAM demo has some that looks to be 3 or 4 inches tall, with a peak to peak of around 6 inches.
Any idea what kind of distance the torch travelled for a 2" height gain?Quote:
Originally Posted by Rambozo
Of course I can't find the example I was looking for, but here is another that illustrates the control required.
http://www.youtube.com/watch?v=txGP-Qbii2E
And here is another. I would shoot for being able to accommodate any change that the torch nozzle diameter will allow. If the nozzle contacts the material, this will trigger the E-stop on many designs. There is no point in being able to handle a faster rise time. I think most home/hobby machines have pretty slow travel speeds, but I'm also sure that will increase as servos get cheaper and easier to use, and displace steppers.
http://www.youtube.com/watch?v=aVlAPmMZu3U
I would say the speed of the plasmacam one shown in the video would be adequate.
Most home brew machines may not be capable of the z-axis speeds shown with the tracker machine.
If it were mine Nest, I woudl focus on getting something fairly robust at a modest speed. The accuracy of interpreting the voltage and providing the height adjustment is more important than the all out speed.
Once you get the logic figured out and become a THC expert, if the speed is really an issue, I am sure the same or similar logic can be built into a faster response system.
Thanks Sport. I guess I'm still not sure what "modest speed" is. I'm still doing test cuts on 16 ga and I'm running at 60 ipm. I saw a reference from somebody else's machine that said to run at 240 ipm and 30 amps or 180 at 20a. I'm not even close to that. But based on that, I figured that 200 ipm would probably be max.Quote:
Originally Posted by sportbike
Of course, I fall prey to the "American Way" - more, bigger and faster is always better:)
The big challenge is trying to learn so many things all at once (basics of using the CNC, SheetCAM, Mach, hardware design and THC theory). I'm having fun, but its just slow.
I took Agent4573's advice and put in a 2 pole filter. I used a calculator I found on the web and it said for a 35Hz filter to use a 470 ohm resistor and 10 uF capacitor.
I put those on and did a couple cuts with data captures. They were worse then the previous cuts. I realized the only other difference on that run was I had my o-scope on the circuit both before and after the new filter. I tried another capture without the o-scope and it was really good. I guess the o-scope leads were just "noise antennas".
A blow-up of the raw analog to digital readings (no software filter) is below.
Attachment 9246
You can see that the signal is now typically +/- 1 count from the baseline. Couldn't ask for anything better.
A full trace of cutting a 1/2" x 2" rectangle is below:
Attachment 9247
I did look at the timing. I'm currently dumping data every time through the control loop. I have a delay so that it won't run more than every millisecond. The software currently waits 1200 ms from an "Arc Good" signal until it starts voltage control. In the capture it showed 1142 ms. between "arc good" and start of control. So, it's off by about 5%. I'm guessing that dumping all the data could have something to do with that, though, the display updates could also have something to do with that.
This is running on an Arduino Mega that uses an ATmega2560 that is an 8 bit processor running at 16 mHz. So, it's not a speed demon but looks like it may do okay for an entry level system.
I think after I have the first pass running well and all the source posted, I may move to the Freescale Freedom. It's a 32-bit arm processor with a $12 board.
On the THC front, I have to figure out the best algorithm for up/down. Since it's a digital signal instead of a up/down speed - I'm guessing that I should just continue with the set "trip points". I think the biggest impact is the response time of Mach and the steppers, but I have no idea what that is. Given the latest capture I think that maybe I should trip torch movement if it's > 3 off and turn it off if its within 1 off. Anybody have any thoughts on that?
I still need to figure out how to setup Mach. It currently won't allow going below the height of the initial height sensing. Also, I have to figure out the "THC Rate" to use.
Thanks for all the help everybody!
You could also look into Raspberry Pi. I haven't used it, but it will operate at 800mHz and has 512MB onboard memory for $35. Might need a bit of thought to get an onboard display, but you may be able to stream via Ethernet to the PC and just use it as an interface box. They even have an "apps store"
http://www.raspberrypi.org/faqs
Nicely done, EmptyNester! I remember how happy I was whenever I got a control loop working and stable. Watching it work always feels like magic!
You know that when I get the time and space to build my own CNC plasma cutter, I'm calling you for hints, right? If you ever need a hand doing any of the software work as you port your controller to a different platform, let me know.
sportbike, thanks for reminding me about the Raspberry Pi. I've been looking for an excuse to get one of those boards/kits, anyway. I haven't checked since just after their release, and at that time they were sold out for awhile. Glad to know they're available now. Heck - you could probably run an entire CNC operation from one of those.
There is a post in the Pi forum about running multiple servos from the board.