Useful Plasma Thread
- rodw
- Topic Author
- Away
- Platinum Member
- Posts: 10715
- Thank you received: 3534
forum.linuxcnc.org/38-general-linuxcnc-q...-for-linuxcnc-motion
So I thought I'd create a link to it in the plasma section here becasue it covers how to fix gremlin displays and also how to sense if you lose the arc while cutting and pause the running program.
Please Log in or Create an account to join the conversation.
- Grotius
- Offline
- Platinum Member
- Posts: 2232
- Thank you received: 1948
Good idea to split off the topic !!
I am filosofying about the best plasma, laser and waterjet solution for the future of linuxcnc.
A solution that is usefull for starting and experienced users.
The most usefull way is maybe to write one good component that is suitable for all plasma, laser and waterjet machines.
The thcud / thcad / thc components are outdated at this moment to my opinion and not usable for all machines,
but are usefull to rewrite so they can be suited with the external offset branche. This branche is the perfect basis for machine's that need a correction at the z axis during operation.
I think a new component can interact with the external offset branche without doing one thing in your hal config. So i will do a
test to interact directly coming week starting with the simplest signal : axis.z.eoffset-enable
Please Log in or Create an account to join the conversation.
- rodw
- Topic Author
- Away
- Platinum Member
- Posts: 10715
- Thank you received: 3534
The other way is to build one big component that includes everything as grijavap has done. Harder to program but easier to install
The problem with the first approach is that there is some parts of the algorithm that can be shared among components (average torch volts for example for torch sampling and kerf crossing). Actually, maybe Average Torch volts should be a separate component.
I think that the first approach is probably the better way to go initially as you can add one piece of the puzzle at a time and then once its all understood, consider folding it into one component.
Please Log in or Create an account to join the conversation.
- Grotius
- Offline
- Platinum Member
- Posts: 2232
- Thank you received: 1948
I was thinking about your view related to the do and don'ts.
This will also result in a more robust solution as each small piece can be compartmentalised.
It's the way you write the code cq. component. A component can do 5 or more independent tasks if you write it that way.
The other way is to build one big component that includes everything as grijavap has done. Harder to program but easier to install
The only need of a component is the real time function. It is possible to load multiple components in linuxcnc without doing 1 line of postgui hal signal connection code. The component's are written to connect themselfs. This can only be done if the signal names are always the same related to their purpose. The uniform names are close to the linuxcnc program style.
In considering is the following :
If new users want to use linuxcnc plasma, at this moment it is almost a no go area. Even with mesa hardware i think it is to difficult to start up within a few hours. If you use axis with toma thc, you are limited and outdated, with my respect for the Toma code.
So if we want to change that, we can make 2 configurations. One for Parport and one for Mesa, configurations that are ready to go.
This will change the whole linuxcnc plasma useage exponential.
Please Log in or Create an account to join the conversation.
- tommylight
- Away
- Moderator
- Posts: 19386
- Thank you received: 6490
Thank you for the respect, Grotius !In considering is the following :
If new users want to use linuxcnc plasma, at this moment it is almost a no go area. Even with mesa hardware i think it is to difficult to start up within a few hours. If you use axis with toma thc, you are limited and outdated, with my respect for the Toma code.
Personally i would not consider it a no go area under any reasonable limits, it works perfectly and extremely reliably, but i understand why you consider is such, it uses Axis as GUI, then again you are using a version of heavily modified Axis.
It also works with Mesa hardware, i can provide configs for that too, namely it will work with 5i25/6i25/7i92 in stepgen mode (as parallel port ), works with any of the above and the 7i76 or 7i76E.
Yesterday i made a config for 6i25/7i77 but used the parallel port to control the Z axis, everything else is servo driven with +-10 controllers and loop closed in Linuxcnc. It can be made to use the second port on the Mesa for that easily.
Hopefully this week i will have a fully functioning servo driven config.
I have been following all of your work ( others too ) on the plasma side of things, hoping to help where i can, but...................never mind.
How hard would it be to take that config and put it in a nice comp ?
Bottom line is, talking about things that do not work does not help Linuxcnc, ignoring things that do work makes it even worse.
I would like to name all the good things about that config ( BTW not my config, i just made it work properly and using a single parallel port ), but i did that several times and after being flat out ignored i stopped naming them.
I can say this:
Make a drawing in inkscape, export it to ngc, open in Linuxcnc and press start. Nothing, absolutely nothing more is needed during work. No modifications to inkscape either. Nothing.
The automation that person who made put in it, is nothing short of magnificent.
I will upload those configs in coming days on a new thread, and will move on to the servo part. Maybe give it a go at making it a comp.
The following is in the interest of Linuxcnc, not personal at all as my machines do work every day all day:
Stop referring to Linuxcnc as useless for plasma, that is simply not true.
Please do read ALL the posts you referred to it as such, before you comment on that.
P.S.
As usual, Admins if you think this is inappropriate do delete this post, i just can not put get any milder. Thank you.
Please Log in or Create an account to join the conversation.
- Grotius
- Offline
- Platinum Member
- Posts: 2232
- Thank you received: 1948
I did your Toma config in the first beginning, and it worked fine for me on the plasma, no problem. It only takes time to understand
how linuxcnc is working. You can not do this in a few hours as newby, if you only have windows experience.
It has nothing more to do with a Axis source code. This is completely different written. The axis source code is very outdated if you look at this type of coding. In that day's they coded like pyvcp (xml) code's to fill the screen.then again you are using a version of heavily modified Axis.
I also use inkscape. Very nice program. Mostly for converting google pictures into dxf.
I think if you say something is not working, the github linuxcnc experts can help maybe to solve the problem?Bottom line is, talking about things that do not work does not help Linuxcnc,
Most problem's are coming out of update's that are not tested.....
In all the time i have been member on this forum, i never saw one modification by an admin. This forum is also very outdated in options and possibilities. But i don't care about that, i only say it.As usual, Admins if you think this is inappropriate do delete this post, i just can not put get any milder. Thank you.
Tommy, the goal is to get a nice linuxcnc plasma configuration. Without doing this together, it can take much more time.
Please Log in or Create an account to join the conversation.
- rodw
- Topic Author
- Away
- Platinum Member
- Posts: 10715
- Thank you received: 3534
Here is the list of proposed Plasma components:
THCAD parser - simple way to connect and calibrate the Mesa THCAD cards
UP-DOWN LED - A convenience function that displays LED's for up and down movement on the Z axis
AVERAGE VOLTS - a function that determines a moving average of the torch volts (for torch sampling and kerf crossing)
CORNER LOCK - A velocity hold function that senses when THC should be disabled on velocity slow down
GCODE ENABLE - Receives and acts on a Gcode to enable and disable THC
ARC FAIL - sets motion.feed-inhibit when ArcOK is lost while cutting
TORCHSAMPLE - samples average volts after THC servo delay expires and enables THC
KERF CROSSING - Senses dV/dT change in torch voltage over time and disables THC when crossing a void
PROBE-SENSE - disable the probe signal when cutting so it can be used for error sensing while cutting. (today's idea)
THC - Does the actual height adjustments
THC will have 4 enable signals (a,b,c,d), all of which need to be enabled to function
a. Torch Sample/THC Servo Delay
b. M3 enable (required to turn torch off on estop)
c. Gcode enable
d. GUI enable
Additional Gcode modifications required.
Remap F code to send original cutting speed to an analog input
Reverse adaptive feed (needs to be included in master branch)
Will use the External offsets somehow
Requires a dedicated GUI
Many thanks to all who have had input on all of this (Islander261, Grivaljap, Grotius, Tommylight, Samco, PCW and others)
So I still don't really know what the THC looks like but by keeping all of the support functions separate is a big step forward in simplifying the design of it.
But I will be working through the list of code.
Please Log in or Create an account to join the conversation.
- rodw
- Topic Author
- Away
- Platinum Member
- Posts: 10715
- Thank you received: 3534
Please Log in or Create an account to join the conversation.
- tommylight
- Away
- Moderator
- Posts: 19386
- Thank you received: 6490
Am throwing this in just in case:
- Probe function - that would be initialised whenever an M3 is issued, so user does not have to do any post processor/ gcode modifications ( it can be done, it is include in the thc_toma config)
- Ignore Z values in gcode while cutting - (also included in thc_toma config)
- Cut height - user settable value based on the THC voltage ( simple THC do that when setting the voltage on them )
- Pierce height - user settable value needed for a lot of reasons, used often
- Probe switch travel - user settable value to offset the distance the switch has to travel when probing to trip ( included in thc_toma) used once when setting up the machine.
- Pierce delay - user settable value needed for piercing thicker metal plates, used whenever cutting anything over 5 or 6mm thick (included in thc_toma)
=== optional ====
- THC speed - user settable value for how fast should the reaction should be when the voltage changes
Not sure about the last one but it is included in the thc_toma and used to prevent "bunny hopping" of the torch while cutting thinner sheets, it is very useful for stepper systems, do not know about the PID controlled system as this one has much more control over the torch and is much faster.
- Output current -- see below for explanation
As a side note:
Adding another panel with pre-sets to choose some of the often used settings for cutting based on metal thickness and adjust the settings below according to that
- Feed speed - set the cutting speed for chosen thickness
- pierce height -
- pierce delay -
- cut height -
- cutting current - if there are provisions for that ( some hypertherms do, on some it can be wired from the built in potentiometer to the electronics so it is settable from Linuxcnc, on some adding relays can change cutting current controlled from Linuxcnc etc ).
The potentiometer types can be controlled using a single PWM output from parallel port or Mesa card or many other cards and an optocoupler with some simple electronics, or from one of the servo outputs from 7i77 or spindle out on 7i76 or 7i77.
The manual switch ones can be controlled using any output and a darlington transistor wired to a big relay, one or more as needed.
Please Log in or Create an account to join the conversation.
- Grotius
- Offline
- Platinum Member
- Posts: 2232
- Thank you received: 1948
Very good !
How did you write the Toma code? Making this code is almost impossible to do without being a expert. So that's why
i have repect for you. Even proma has used your code.
This item : THC speed has to have some attention with using the external offset branche.
The external offset branche uses a ini-vel and a ini-accel parameter to control the speed of the z-axis reaction speed.
The THCUD and THCAD components are written with 2 speed parameters..
1. Thc(ud).velocity-tol
2. Thc(ud).correction-vel
So in my opinion the Thc(ud) component speed value's can better be removed in the component and only use the external offset ini-vel and ini-accel as parameter for THC. This will improve the quality of movement of the motors. At this moment there are more calculation's running around actually needed.
I like also the thc has a parameter for upper limit and lower limit. for example upper limit : 10mm, lower limit -10mm.
The probe function is indeed the easyest when using a on screen button. Then you have nothing to do with choosing a different
post processor. Is it acceptable to do the probe function with a M130 for probe on and a M131 for probe off in g-code ?
In mach i always use M300 for this. But i must test if we can use higher then M199 in linuxcnc.
In code :
M130 ( Probe function, is on or off through screen button, standard off )
M3 ( Plasma start )
Cutting current will be difficult to add in this startup process. Mostly Hypertherm uses modbuss for this.
I think in later stadium we must make a modbuss component for Hypertherm just like the vdf component.
Thermal dynamics uses 0-10Volt input on your pwm output, but pwm signal must be boosted up a little bit in amps.
@Rowd,
Nice sketch, this morning it did not load, but that is solved now i see.
There are a few things i have questions for.
The kerf krossing is only readable if you have a divided voltage input trough a mesa card,
or a modbuss i/o module? So it is possible to not use this signal without error's...
Is it handy to make a basic sketch with only the basic signals. After that make a division sketch for extra optional signals?
Just an idea..
It looks like the THC function finally gets a boost !
A tip : if you modify a component, it's handy to do the extension at .c instead of .comp
This will change your programming interface into c. It will look much easyer to understand.
When you are ready, change it back to .comp and give it a go.
Please Log in or Create an account to join the conversation.