Plasma Questions

This is the point, re-design the THC component to accept the motion.current-vel signal and use it for the calculations

Hello

The current THC component can/does use the motion.current-vel as the input to determine torch velocity.

linuxcnc.org/docs/devel/html/man/man9/thc.9.html

John

islander261 wrote:

rodw

I think everyone that has considered the THC problem has looked at that AWS article. From what I have been able to tell unless you are cutting quite thick plate the arc source point movement get swamped by the accumulated system errors and filtering. This is a good intellectual exercise, I was advised by HT guru to not worry about it, a working solution is much simpler.

Just monitoring the the step output of the controller only provides the information to solve the speed problem on slow down at the end of the cut. It has no way of knowing what the target speed is during acceleration. Of course you can just use a fixed time at initial cut height or make a bunch of assumptions based on recent motions to get around this. Now if the THC can accept an analog or digital representation of the Feed Rate then it can work. With LCNC this is no problem, but with most closed commercial system and MACH your out of luck.

John

The research above used 1.6mm & 6.4 mm plate. Their graphs are based on cutting 6.4mm plate. They don't say anything about the process not working on 1.6mm (which is probably the thinnest I'd cut). I did a bit of searching for voltage sampling and found 2 approaches. One samples the voltage near maximum velocity and the other averaged the voltage over the first 1/2 " (12.7 mm) of travel. I thought the velocity linked sampling was the better approach. Which I think leads us back to:

This is the point, re-design the THC component to accept the motion.current-vel signal and PID and use it for the calculations

I had a bit of an idea driving to work today. I went looking for the one I made years ago but could not find it so I'll have to buy an Arduino SD card shield tomorrow.

By changing the prescaler, the arduino can sample at up to 50,000 per second and Atmel says while accuracy suffers a bit accuracy is still quite acceptable. We only need to measure at 25,000 per second so we can get away with a slightly more accurate prescaler setting that will sample at up to 31,000 times per second. See:
www.microsmart.co.za/technical/2014/03/01/advanced-arduino-adc/

Now becasue I was planning on using an internal 50:1 voltage divider in my plasma cutter, a simple 2:1 voltage divider will let me scale the output to 5 V for the Arduino to read. I might play with that a bit becasue there is also an internal 16:1 divider in my plasma which might allow improved accuracy..

So here is the idea:
There are 3 states:
IDLE
CUTTING
WRITING

So the Arduino would monitor the Torch on signal via a 24 v to 5 v voltage divider probably attached to a hardware interrupt. Starting in an IDLE state, we would wait until we moved to a CUTTING state (ie torch on signal enabled).

While in CUTTING state, the Arduino would sample the torch voltage at 25,000 Hz (40 usec sample period) for say 10 seconds or until the torch was turned off. We would only work with the raw integer data (0-1023) to save time as we won't have a lot of spare time in our interrupt service routines.

We'd do a couple of simple integer calculations on each reading so we can ensure we can calculate the minimum, maximum, average and moving average every 1000 readings. Then store the summarised data in an array. This summarised data should help offset the possible sampling error due to the prescale setting we have to use. There will only be 25 summarised readings per second (at 40 ms sample period for summary data) so for 10 seconds we will only have about 250 entries Possibly 10 seconds can be extended a fair way.

Once the sampling is complete, enter the WRITING state. Disable all interrupt processing and convert the data back to floating point at a leisurely pace and write out the maximum of 2500 entries to a file on the SD card in .csv file format for later analysis.

Return to the IDLE state and wait for the next run.

I think the Arduino will have enough memory to do this but if it has to be limited to a shorter period, so be it.

So that would let us look at plasma cutting in a way that average LCNC users have never been able to do in the past. It might prove to be a waste of time, but at least we are not basing decisions on second and third hand comments by supposed experts.

How does that sound? Am I mad?

It would be nice if this data stream could be synced to LCNC height and velocity data but communication overhead would probably prevent it.

rodw

I think you are going to need a bit more hp if you want meaningful data. For the 19khz anode spot movement signal you will need to sample at above 38khz if you want to avoid serious aliasing in you data steam. I have watched the arc voltage on my system with my old analog o'scope for many cuts. The arc voltage is very noisey. If you have access to a modern digital one with all of the signal analysis features I suggest that do this and see for your self what a mess this signal is ( it will also have a known A to D response and test analysis SW). The predominant noise sources are the 120hz (in USA) ripple from the plasma power supplies full wave input rectifier, switching noise at the frequency of power stage (this is different for every brand of power supply and sometimes changes with the current) this also wasn't a problem for authors of the article cited because the old machine they used was SCR controlled at line frequency, on top of this will be all the rf noise from the arc interacting with the output choke and all the stray inductance and capacitance. You will need your test table well grounded to a dedicated ground rod close to the table (yes drill a hole in the slab next to your table for the ground rod, the low frequency impedance will need to be less than 1 ohm, salt water in the hole helps) , your power line ground will not be good enough if you want meaningful measurements. You need to do this even with a modern "blow back" start plasma power supply and torch. Good luck.

Now for a bit of reality on how production cutting works with low cost equipment. The first thing you do when cutting a new material is to do test cuts at the anticipated cutting speed (material type, thickness, cutting current) and cut height (torch and consumable type) at a fixed height (THC off). If the cut quality is acceptable record the the arc voltage displayed on the THC and use this as your voltage set point. Then with the THC operating stop the machine in the middle of the test cut and check the actual cut height with a feeler gauge and block, if it is the same as your test cut height you are good to go if not rinse and repeat as they say. This is required when using low cost and hobby cutting systems because the sum of the errors in the system will cause incorrect cutting height if not adjusted to your equipment. If you have an industrial machine the manufacture has usually done all of this for you ahead of time.

John

John, thanks. I did make a mental note when reading that article that their sample frequency was based on the slower 3 phase ripple of 360 Hz and that single phase would be faster (100 Hz here). Thanks for the reminder about grounding the table. I still think the Arduino can do the job at up to 50 kHz. I'm not too concerned about the noise. Its been a long time since I have done any mathematical modelling but I do know that the moving average is a very useful smoothing technique when dealing with noise in the data. There are other techniques but the advantage of moving averages is there is hardly any maths involved which is good for this application. The limiting factor for the little Arduino will be is how long it can sample for without running out of memory. The reason for this is that offloading data to the serial port or SD card will be far too slow to keep up with the data stream. It might be possible to use a circular buffer so the SD writing starts immediately, but what do you do when the buffer fills up? I'm not going to tackle this for a while as I am still building my table but I don't think the programming would take long.... (famous last words)

I am fully aware that there is a lot of calibration to do for each material and plate thickness. I'm not really looking forward to it... Having a data log would be helpful I think.

Anyway, my current concern is to get the last couple of signals hooked up between Gmoccapy and the THC.

I Still don't understand how the various non-THC related plasma parameters are used and If I have to hook them up to something. I'm talking about THC speed, Delay, Corner lock and the various gaps.

rodw

Ok, here is how I have used the GUI values on my machine.

The Z axis speed is usually reduces from its maximum capability to keep the torch from over shooting on corrections. I know this is not the best but it is the way most lowcost systems cope with not needing to change the THC gain for each set of cutting conditions. So on my system I just multiply the Z max velocity from the .ini file by the GUI percentage and set the z axis pid max-output parameter to it when the THC is active. This really is working as a limiter to the velocity command to the 7i76e step generator.

Two of the GUI items relate to piercing and will be used in your part files or in O code subroutines. I use O code subroutines for probing and piercing. The pierce height (gap) is the height of the torch above the top surface of the work piece and is usually the last move of your probing sequence. The pierce delay is the time period between your control receiving the arcok or ok to move signal from your plasma power supply and the movement of the torch to the cutting height (gap).

The Corner lock is on of the keys to good cutting, it is also called Velocity Anti-Dive by some. The value from the GUI is the amount of reduction from the requested velocity. If the current speed is below this set point the movement of the z axis is frozen until it is equal or greater. Connect the GUI pin to the thc.velocity-tol pin. The corner hold function is always on in the current THC component. You can trick the enable check box into actually doing something by having it force the threshold value to 100 when disabled.

The G0 gap is also known as the safe Z height. I am actually not using this right now because this is set by my PP in the G code part files.

The correction pin in the GUI is connected to the thc.offset-value pin.

I haven't done the limits yet. The Z up and down LEDs are from the up/down inputs from an external thc. I haven't set up the calculated values yet to drive the leds from the THC component.

I'll post my configuration files in a few days after I clean them up some. Lots of messy stuff from experimenting to get things to work together. Starting lcnc from the terminal and halshow are your friends.

John

John, thanks for your detailed reply. It was very helpful and it helped me to connect a few more pins. I think I've got all the THC pins connected but wanted to check them all off to check.

I think I can see a way to simply generate the up and down LED's. The Mesa stepgen velocity pins change sign based on the direction of travel. In my setup, down is negative and up is positive.

The HAL abs command has a pin for the sign. 1 = negative, 0 = positive. One signal will need to be inverted. I'll have a go at it in the morning and if I have a win, I will post the code.

I understand the heights and delays feed into the touchoff o procedure but do we need to connect them to something or is that already done in the config files? I saw that there were some digital pins that connect hal to gcode so wondered if there was something similar we needed to do. (be gentle, a couple of weeks ago, I knew nothing about gcode and I've only learnt about 4 of them so far.)

rodw

None of the pins from the GUI are connected for you! When I made the decision to go with the plasma version of Gmoccapy I thought things would go fast and easy because all the stuff that requires detailed operation knowledge of the control was done for you, wrong, it has been a tough steep road but I am getting to the end. Now I am thinking of scraping this and starting over doing things much cleaner instead of fixing each case and moving to the next one. While most everything you need to know is in the docs finding it and understanding it when you don't really know where you are going is not always easy.

There are several ways to connect the pin values into you operation. They all go through the hal one way or another. I am using O codes (sub routines) to do probing and piercing right now. Keeping the probing and piercing motions out of the main line G code part file makes them easier for me to understand and trouble shoot. Also it helps to keep the part file smaller, many of my part files are between 12,000 and 15,000 lines long for a sheet of parts. Look in the documentation here:

linuxcnc.org/docs/devel/html/remap/remap...i_file_configuration

And in the next two sections for what you need to know to read .ini and hal file values in to G code files. Why this information is in this location escapes me but it is covered. I read both .ini and hal values into my files. Of course you don't have to do any of this if you just control everything with your PP. I actually could do that because I only use two different sets of torch consumables, they run at the same cut height but pierce differently.

One thing I still have not figured out is how to read values from the .ini file into hal files other than the main one. I ended up having to make pins in the main hal file (actually install components) and then use them in the later hal files (the ones to connect your GUI tabs to the world).

John

Thanks, John I knew it wouldn't be as easy as it looked! gmoccappy seduces you withits cool interface and then you really have to work hard!

There is a caution in that link that says

this section doesn’t really belong here but since it comes with the same branch, here it rests for now until its clear this will be merged. It should go into the gcode/overview Named Parameters section.

So now you know why!

I sorted the Z up and Z down signals withThe LEDs now turn on whenever the axis is moving.

I hooked signals from the Z axis limit switches on the plasma tab toBut the screen LEDs don't change state despite being able to see the state change on the pin in halshow so I don't know whats going on there. Is that the intended purpose or it it meant to be THC related? It does not seem to be a particularly useful feature the way I've done it when linuxcnc raises an estop window anyway.

I think the torch breakaway switch need to come out on the GUI somewhere. Whilst mine generates an estop, it would be nice to know why it stopped from the console.

I still don't understand what plasma.hal-lbl-corr is meant to display.

I think I've had enough for today's session!