Plasma Questions

rodw wrote:

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

Now I do! - From your earlier post thanks!

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

rodw

The GUI screen is really just a collection of possibilities. What you is similar to what I was thinking about doing with the up/down leds. I actually think they are there for people that have a Proma type external THC so you can see when the THC is commanding the the torch up and down. The z limit leds in the plasma tab where most likely met to interface with some soft limits for torch movement. Some of the Mach3 screens for THCs have limits you can set for when the THC is working. Under Mach you loose the real soft limits when using an external THC.

The torch crash switch is displayed on an led on my GUI and is connected to the estop logic.

John

John, thanks for your ongoing support.

The LED's not working on the limits was due to a wiring fault. (now power to the gantry). Next time remind me to look at the power indicator LED I installed on the top of my gantry before starting any troubleshooting! I saw it as I was adjusting what I thought was a faulty float switch!

Thanks to a screen dump of your setup you posted on another thread, I also finally worked out what the Gmocappy plasma torch button is used for and I and'ed it with motion.spindle-on so that the torch won't turn on until the screen button is pressed
So that leaves me with just the corner lock to do and you oultlined a way forward earlier before tackling the gcode interface.

In your setup, does the corner lock LED in the signals section just show that it is enabled or does it show when it is limiting dive during a cut?

rodw

I don't think there is any "right" way to do most of this. You can make most of the GUI and controls work the way you need them to. I set the corner lock led to on when the torch height is fixed for my setup. So corner lock led = not thc.vel-status.I did it this way because with the present THC component the corner lock function is actually always on unless you trick it with a value of 100.

Actually I have multiple buttons related to the torch on control.

There are global THC enable buttons on both the main screen and the plasma tab. These buttons are synchronized through their respective hals. There is a torch enable button on the main screen. The torch cannot fire unless this button is true. There is some addition logic in the hal that allows testing of part programs without the torch firing by using this button. Lastly there is a torch test fire button on the plasma tab. If the torch is enabled you can make the torch fire at any time with this button.

I am beginning to think that the global THC enable buttons are a bit redundant as I am intending on controlling the THC enable from the g code part file as well. This is done through the PP.

Now is the time to really look into the tool chain you are going to use for creating your part files. Plenty of learning here as well. Anything other than pretty simple rectilinear shapes with little extra controls get over whelming fast when you are beginning, especially if are trying to get good nesting for efficient sheet use. I use Inkscape ( poor mans Adobe Illustrator) for art work and simple mechanical drawing and Sheetcam for the CAM part. I have full blown commercial cad/cam from my previous employment that I use for real mechanical design, not plasma table parts. I know this will bring out the open source flame throwers but for the price Sheetcam is a good 2.5D CAM solution for plasma which is actively updated and supported.

A side note to those with any interest. I was having unsolvable by me occasional real time errors while running lcnc on an old Dell 745 box (free at dump). I have replaced the Intel 100E PCI nic with a Realtek RL8139 PCI nic (both from Ebay) and no realtime errors in the last day of running!

John

John, thanks for your patience and willingness to guide me. I really appreciate it. You've probably noticed I've been trying to document the major steps for those that follow.

I've implemented the corner lock override and it really did my head in. I settled on needing a mux2 and a mult2 component. But the first time through, I had them around the wrong way. (mux before mult instead of mult before mux.....)

I'm assuming that the output to thc.vel-tol is 1.0 at full scale, not 100. I'l review the thc.comp code when I get a chance. Let me know if my assumption is incorrect.

Anyway, If my assumption is correct, this code forces the output to full scale (1.0) if the checkbox is disabled and reduces it by the percentage amount if enabled.

I need to study up on the glade environment. The slider should be hidden or disabled if the corner lock is not enabled for a consistent user experience.

I don't understand what the logic was behind the Gmocappy plasma THC Speed settings. It ranges from 1% to 20% but 1-20% of what? Is it meant to be an override to thc.correction-vel? Surely the range should be zero based or span the zero point (eg -20% to + 20%)?

I think most of my parts will be cut from .DXF files that have been designed in professional software. I do have Illustrator but am not arty farty at all. I used to employ full time graphic artists and was immersed in postscript workflows. Illustrator is not really an application that suits occasional use.

Layout and post processing will come from Sheetcam. I'm debating whether to get a Windows or Linux license to it. We should never be concerned about being open source purists, we should select the right tool for the job.

As far as the toolchain goes, don't scare me again
In a perfect world, I'd like to have a table of materials (type and thickness) that load the correct defaults. eg. "3mm mild steel". somewhere in the workflow. It probably would be nice to select that on the machine interface in case you decide to cut a 3mm part from 4mm.

What a waste of time that was!

THC.comp in master defines a pin
but its never used....

github.com/LinuxCNC/linuxcnc/blob/master.../components/thc.comp

it sounds like a great experiment to collect data and make analysis based decisions in the plasma THC design.
maybe you can use the following ADC it is 16 bit instead of 10 that the Arduino have
I order one yesterday to start a play a little bit with the data acquisition.

mayhewlabs.com/products/extended-adc-shield

grijalvap wrote:

it sounds like a great experiment to collect data and make analysis based decisions in the plasma THC design.
maybe you can use the following ADC it is 16 bit instead of 10 that the Arduino have
I order one yesterday to start a play a little bit with the data acquisition.

mayhewlabs.com/products/extended-adc-shield

Thanks, that is very helpful. I had looked quickly for an external ADC and this one has the added advantage that it supports a 10 volt range which is a perfect match for reading direct from a THCAD-10.

Anyway, as you can see, I've still got plenty to do...

rodw wrote:

Anyway, as you can see, I've still got plenty to do...

But I ordered one