Useful Plasma Thread

well, look at that! I did code this.
The maths is not complex
Comp is attached. I think we just need to decide what signal is used to mark the location and how to query it.
It will need testing as I can't remember if I got that far. I think I did. It can be done in a sim.

You don't really need to worry about distributing .so files. If you put custom components in the correct source folder with all of the other standard comps, they will get compiled and installed by the make process. But if you do a git get, any custom code will be deleted. If these components are going to become part of LinuxCNC we will need to get them into a git repository that is kept current with master. I might start doing that soon as I get a few cleaned up as your reversing code will be hard to keep current with master.

I'm not sure about the autostart function, on my plasma machine, it continues to attempt to restart while m3 is enabled.

I might send you an email via the forum. Keep an eye out for it.

Hi Rodw,

That is a very, very nice code to use !! I am on holiday this week, so i am writing on a tablet and can not test applications at this moment.

I think the M66 has one disqussion point. After the waiting periode, machine will continue without plasma arc. Okey now we have adapted the arc-lost signal, so after the M66, the machine will not move anyway, so problably that is solved.

For the auto restart function, it will be places like this :
1. M3, then wait for arc-on M66, if arc present it will do his job, if no arc, machine will not move because of arc-lost signal.
( arc lost signal in my current case integrated and tested in THCud.comp file. )
2. After arc lost signal, begin restart procedure, it will do item 1 again.

I am asking myself, is it a problem to use the same signal names over different component files?
If we can use the same signal names over and over again in different component files, it will be better for develloping building blocks.
You have to connect less signal's at the custom.hal file between the different building blocks.

Sorry double post

Thanks

Currently I have borrowed the eoffset_pid touch off code that looks something like this,I added a bit so it raises torch 50mm to change consumables, but you could loop a couple of times first. I'm not on my LInuxCNC machine but the code may not be perfect
If we are clever, we should be able to define a [PLASMA] or a [THC] section in the ini file and a standard LIB hal file that makes all of the connections in one file that the user should never need to touch.

Enjoy your holiday! I did send an email. Wait until you get home is fine.

Hi Rodw,

Your above code can be seen as user defined macro code.

When we make a plasma config distribution for the external offset branche, we can do the pre configuration in hal and ini.

It can be adaptet to multiple screen interfaces like gmocappy, gscreen, or other custom screen design's. (Blender style)
Then the plasma section will be a glade add on panel. Just like your Gmocappy interface plasma add on at this moment.
In my custom Grotius screen design it is part of a multitab panel. So in Gmocappy multitab is also a option. Why?

In the future we add a plasma tool library with all cutting parameters. In multitab it is also easy to refererr to certain webpages like M-code list's or g'code lists or certain cutting charts.

I have no mail recieved, but sent you a gmail. Maybe you can repond to my mail adres.

Related to modbuss, it is the uniform tool to set the power of the plasma inverter. It is not real time, but it sends data before the M3.
So it is a good tool to use in the future. At this time there is no modbuss_plasma.comp available, but that will change soon. At this
Moment the user interface is fast enough to do this job in python code. I tested this for a good time with 2 seperate Modbuss i/o devices.

I might start doing that soon as I get a few cleaned up as your reversing code will be hard to keep current with master.

Rod, if you have a reverse motion path. It has the power of Fanuc, Kuka or all the other big motion manufactures.
So i don't know why the master is not repsonding to my version. Maybe there are reasons, but i don't know them yet.
My git version is up to date to master, the russian guy can adapt it if he want's to.

I think Machinekit is also born out of an development issue. So why not start the Plasma-laser-kit?

Thanks !

Hi,

Maybe we must work on a plasma uniform signal list where all users are satisfied about. So when working together on a project, we can use a uniform signal name. Here a example :


Plasma signal names :

Thc_enable
Thc_min
Thc_max
Thc_speed
Thc_delay_arc_ok
THC_current_height
Thc_kerf_crossing_enable
Thc-kerf_crossing_value

Torch_up
Torch_down
Torch_at_requested_speed
Torch_touch_off_all
Torch_touch_off_section
Torch_section_distance_x
Torch_section_distance_y
Torch_section_distance_xy
Torch_pierce_height
Torch_pierce_delay
Torch_auto_restart_enable
Torch_ignition_time_out
Torch_ignition_attemps

Arc_ok
Arc_lost
Arc_voltage_in_mesa
Arc_voltage_in_modbuss

Inverter_modbuss_enable
Inverter_modbuss_connection
Inverter_modbuss_set_voltage
Inverter_modbuss_set_air_pressure
Inverter_modbuss_error

It will we great if the signal name is clear without reading the doc's first. We can expand the list to all the plasma signal names and then apply them as standard to use in all plasma related code's. If i am wrong about some signal names, please correct them. We can use a shared google docs document if that is handy.

I like the idea. I was also thinking that the plasma components also needed a consistent naming policy. eg maybe a corner lock component should be called pla-velocityhold.comp.
This would make them all group together in the documents and also make the code self documenting.

The eoffset_pid.comp is very consistent in its signal naming with every signal commencing with E: (eg E:command) so if it becomes the THC, relevant signals should follow its naming convention.
Some of your signals don't make sense to me yet but they will become apparent as I work through the code. Sorry I got busy in my business since the weekend so have not had a lot of time the last couple of days.

Hi,

I have tested 2 components with same signal names, for building component in blocks. Result is perfect !

component 1 : thcud.comp =>compiled to thcud.so
component 2 : arc_ok.comp = compiled to arc_ok.so

in hal coupling the names :
net T:thc-enable thcud.enable arc-ok.enable

For readers : arc_ok in c code, is arc-ok in hal section. The _ becomes - (you have to know that once)

Tested result :

I think i have a new function created, wich can be implemented as a interupt function for all linuxcnc users.

Its quite simple and it works realy real time :

This is one part of a building chain / block. This alsmost looks like a bitcoin put option real time handler.... This is better then building a mining rack !!!

Project update :

Today i did some work on the Grotius plasma screen.
I have added a cool emergency stop button. This was not very difficult to do.