Useful Plasma Thread

I was thinking about the structure.



If you have a component written. It has the in and output signals we need.
It can interact directly with M codes, user interfaces, etc real time.
So better is to work around the to make M code list, this list is a user friendly list and also reduces the comp file code, a Macro does not have to be compiled, and simplyfies the structure in drastic way. Also users can make a quick modification to a existing Macro and don't have to worry about learning the whole process how to be a top c programmer.

This is how you can do a Macro :

It first looks if the THC is enabled.
It triggers if the arc okey signal is not lost during the cutting process. This real time interrupt model is only done by the component.
So the component handles only the real time interrupts. Logic parts can be programmed in the Macro's themself.

Thanks guys. the sketch is far from complete. and has a few more annotations on it now! I just wanted to focus on the core components that compartmentalise each THC function so it does not include pierce delay etc at this stage.

I am very comfortable programming in C and have had previously written Interrupt Service Routines (which is what the servo thread really is). By breaking it up into components, it should be more robust and easier to read as each components source should mostly fit in < 100 lines of code.

Some comments.
1. This will be designed so all torch height control is done internally within Linuxcnc and will not accommodate an external THC such as Proma ot the current THCUD/THC components. LinuxCNC is better than that!
2. It will require a method to read torch voltage (eg. Mesa THCAD at $69 becomes a very cheap THC).
3. Using internal code and PID based control should eliminate the need for a THC response speed setting.
4. Islander261 and I have experimented with using a standard M67/M68 command to allow multiple GUI settings to be set from within Gcode using just one analog pin (with an appropriate python screen handler) so you can change settings on screen and within Gcode. So I don't want to be too prescriptive about what Gcode does what, Just that every required Gcode function is supported.
5. Grivalajp has already shared some python code that uses modbus to talk to the Hypertherm RS485 port. Eventually, I would like to replace this with a hardware module so that there is no need to have a USB connection back to the PC. It would be much nicer if there was only on ethernet connection to the control box. This should be able to be supported using the smart serial port on a Mesa card and the right firmware (available for the 7i76e).
6. I have often wondered about writing a seperate touch off component that enables motion.spindle-at-speed when Arc is on, back at cut height after pierce delay so that there is no Gcode pierce routine required.. I've added it to the list.

Thanks for all the feedback. As I said most of this has been written so if I can stay motivated, it might not take long.

Hi,

Yesterday i had an issue about the limited M code list. We can go up to M999. We just have to change some things.

These codes are currently undefined in the current implementation of LinuxCNC
and may be used to define new M-codes:

M10
M11 M12 M13 M14 M15 M16 M17 M18 M19 M20
M21 M22 M23 M24 M25 M26 M27 M28 M29 M31 M32 M33 M34 M35 M36 M37 M38 M39 M40
M41 M42 M43 M44 M45 M46 M47 M54 M55 M56 M57 M58 M59 M74 M75 M76 M77 M78 M79 M80
M81 M82 M83 M84 M85 M86 M87 M88 M89 M90
M91 M92 M93 M94 M95 M96 M97 M98 M99

All codes between `M199` and `M999`.

So we can go up to M999. That is nice !! But i think we can go up to M10000 if we want, lets try it.
It is easer to understand M3 is related to M300 and so on.

For today my investegation ended here at line 148 : github.com/LinuxCNC/linuxcnc/blob/master...4ngc/interp_array.cc
At this moment i want a good time with my wife.

For tommorrow i have a new github linuxcnc version to try the exended Macro M999 and also try M10000.
You can see if it is working if it has a star.
github.com/michelwijnja/External_offsets...tive_feed_macro_plus

Update :

Expanding the M codes was succesfull in one file after compiling. I expanded the M-code array.
But it still is complaning after compiling and testing in terminal about : Uber 200 is not allowed.
So there is another file that is related to this maximum number.
github file
But now i have to find the other related files. The terminal give's to less information to solve this quickly. Is there a log file
that can trigger every single program step?
So i must look file by file tomorrow.

Rather than trying to use M300, why not pick a range say M300-M399?

Then you could use M303 to pair with M3 in a logical manner. I don't think its a good idea to hack into the Linuxcnc core model.

I've added one more box to my diagram "touchoff exclusion". Say you don't want to touchoff until you are > 50mm form the last one, this will set a pin to be true if a touchoff is required (eg >50mm from last touchoff).

Hi Rodw,

A Touchoff on/off button is very nice. I assume this will be added as Macro in g-code wich triggers the hal pin ?

I am curious how you program the 50mm variable distance in linuxcnc. I know sheetcam has a postprocessor who does this.
If you can do this in linuxcnc, this would be great !!

Problem with user defined macro's is the low range at this moment. It has enough macro's, but i like them to use in logic way that you can see that some macro's are related to each other. But i can better not waste precious time for this little thing.

Mesa THCAD at $69 becomes a very cheap THC).

Yes, it's very cheap for the product.

Its pretty easy, if the ArcOK changes state and it turned on, save the x and y coordinates (eg axis.x.pos-cmd and axis.y.pos-cmd). Then do some maths to calculate the distance from there to the the current coordinates and turn on a pin if its > say 50mm. It might be better to link the input to the probe signal rather than ArcOK but it would be the same method.

You could attach this signal to a motion.digital-in-nn pin where you could retrieve the state in gcode with a M66 if touching off in gcode. The maths is based on Pythagoras theorem. You should not need to do anything in gcode to tell it when you are touching off as the system already knows.

I've also written a simpler version that tracks the y position and enables a pin when it is greater than a set distance (half the table length). Why? well the pin can trigger an air ram to open a shutter to zone the table. This need to be fleshed out to a multizone system, but 2 zones is already supported.



Added this to the list

Hi,

I was thinking about the probe function wich you can set over xy distance.

The pythagoras formula is one option, like Rod has written.
Here i have a signal sample how you can trigger very simple over x and y distance.
The result will be no circular distance calculation but a rectangular distance calculation. In this way it is also possible to only measure at y axis or only at x axis distances. Most of time inox plates are bended over the short side.

Anonther function is the auto restart function. To make and adapt this function would be also great !!

If you look at the plasma start procedure :

1. Probe on or off.
2. M3 and wait for arc-on signal to move, if time out trigger auto restart component.
3. If arc-on, then do your thing.

So now it looks like we are building the THC features in building blocks, user's can add building blocks to their needs.
It would also be easyer for others to upload new features to this forum, that features can be loaded and tested in minutes.

I have tested that problably a component.so file is enough to load directly without first the need to compiling the component.comp file.
But i think i have to test this over different disto's.