Another plasma component...

islander261 wrote:

I hope others may weigh in on this so we can see if some sort of consensus can be found . As you know I feel strongly about having a torch enable button and indicator on the GUI. The torch enable signal is ANDed with any torch on signal coming from the controller just prior to connecting to the output pin. On my system a dry run is done any time you run a Gcode program and the torch is disabled. I find that once you get your PP sorted out there isn't much use for a dry run ( I only ever cut full sheets).

So I'm going to weigh in on this because the dry run feature was one of the most attractive features of this component for me. The plasma I am working on is used by inexperienced undergraduate students in a university machine shop so having the dry run is essential when the number of parts cut is normally small and the people operating the machine often make basic setup mistakes.

In my opinion it makes more sense to have a button to enable/disable the torch and a dry run just be the case where the gcode is run with the torch disabled (as suggested by John). I think that this approach may be more versatile and may have added safety benefits. The current behavior of the dry run button seems to be an additional way to cause gcode to execute while disabling torch and arc-ok checks. This is slightly confusing as now an operator has two buttons they can click to run a program and it is easy to make a mistake and click the run program button when you wanted to do a dry run (I've made this mistake a few times myself).

I'm interested in what everyone else thinks about this because the current implementation does work decently at the moment , excepting a few bugs which mean you have to restart linuxcnc (I will report when I can repeatably cause the bug).

Glenn

Lets just say I don't have dry run on my current experimental config and I really miss not having a torch disable button!.

Sometimes squeezing a part onto a small offcut its nice to check it stays on the sheet.

Phill

Sorry, this is going to be long and rambling.

I will first describe what I do on the Gmoccapy UI that I made for my table. This configuration does everything from either values (controls) in the Gcode or values (controls) from the GUI. There is a check box on the setup tab to select whether values come from the GUI or from the program. The THC enable is always controlled from the program if it is there. One unforeseen result of this is it requires a rather complex PP which produces complex Gcode that has some rather tricky conditional code for changing cutting parameters when tools (materials) are changed. The changes in values (controls) are sent over as an analog output (M67, M68) as originally adopted by CandCNC for use as an S block with Mach3. On my system I decode the value using both a custom .hal component (real time stuff) and the GUI Python handler for the setup tab. The whole system is rather cumbersome and produces complexity at all levels, ok for me but I would hate to have to teach a newbie to use it via forum posts.

I am now getting my head around some of the workings of the plasmac component and I think it will make the problem much simpler. I also now realize that it is possible to have a rather large number of motion digital and analog outputs if you need them so why limit yourself to the Mach3 legacy single variable. I think that any value or control passed from the Gcode file should update the value or control on the GUI and override the current value. This will allow a default safe configuration that is updated with each tool change. For those that don't use that complexity you still have your materials file and can use a simpler PP and Gcode files. The next step in complexity which is of no use to me at this time is being able to send over plasma power supply operational parameters that are forwarded by RS-485 (present) or Ethernet (future) to the machine. The interface to all this is pretty simple given the plasmac operation. This is pretty easy for a PP and can even be done using Gcodetools. All commands and values are sent over in one of two places. The first place is between the last movement block and the M3 S100 block for things that need to happen before a cut and second place is after the M5 before any movement blocks. I think most of this can be done using the GUI Python handlers because of where the variables will be passed. A short (.1 or .2s delay) G4 should allow the GUI handler plenty of time to work because the machine is not moving when the variable is sent (M3 and M5) are que breakers anyway I think.

When I hacked in Gcode control of THC-enable using the thc-enable-ext pin a number of releases back I just used a motion digital pin (01 I think). I placed a synchronized output M62 P01 command just after the M3 S100 block but before any motion block to enable the THC and placed an immediate output M65 P01 command to disable the THC just after the M5 block before any motion block (if needed). It appeared to work ok. On hind sight I now realize that I could have done it as described above and not worried about any synchronized outputs. This is easy to do either in a SheetCam PP or in Gcodetools.

I hope this helps and also hope others will chime in on whether they think any of this is needed and implementation methods, there is always a better way.

John

I would also like to have a torch disable function to fit parts onto already cut sheets.

On a side note I think everything worked and I can now load plasmac sim. when I do I get this and I cant close that top test window. I don't know if thats a feature of the sim but I can move it around. Now how do I move forward from here and go from using a sim to an actual controller?

And I figured out how to do screen shots lol

Do you have working .ini and .hal files that move your mechanics correctly? If so post them.

I will give complete instructions later when I am finished with the days work.

John

The dry run is very important to have. @Zultan..Glenn..

I solved this by the following, important for phil who is currently writing a new plasma component :

In my component i made a arc-ok fake button.
So the dry run is simply running when the arc-oke fake button is on.

( the plasma component is alway's looking for the arc-oke signal when active. ( programmer's logic )
When the arc-oke is incoming, the machine is allowed to move. (smart connected halui.pause connection).
When you want to dry run and have no arc okey signal, the component will say, we will not move !!!!

So the student can not dry run, what is a shame for us. But it will be solved soon. In the previous provided ethercat component, it's available as a fake button. That you cannot see because the gui interface is not provided. Only the connections are provided.

I remember posting my experience with linuxplasma so far in post at this post :
: forum.linuxcnc.org/plasma-laser/35449-an...ent?start=230#130217

Keep in mind. This is the most powerfull linux plasma application currenty in use.

In the next post Phill will have a look at my files.

But i know it's hard to follow. C code can be very confusing, and i mentioned that my component names (logical names)had to be more specialised trough the testing periode.

In the attachment of the above post, look at the signal pin in bit arc_ok_togglebutton "";

If the arc_ok togglebutton is active, in c code it goes to a separate code section called "case togglebutton" or when not active it's case is "case no_togglebutton". But in plasma world. It's very difficult to write a good component. Testing of component's are in my case alway's done on real machine's and the time it takes include testing is sometimes 2 day's or more when i start from scratch.

(remember i have a different linuxcnc distribution. My component works on a exernal offset branche cruisifide with a reverse run branche).
I can see my current offset in Z dro. I can see my actual tool path (how the thc is responding path) etc. It is still the mach3 killer in all way's. But you have to know how to install it.

Last I checked the plasmac branch uses both EO (now incorporated in the master) and reverse run.

Without working .hal and .ini files we can only get to all of the copying that will be needed to start building a working configuration. To start with make a new directory, say myplasmac or what ever you want, under ~/plasmac/configs/ using either a terminal or your distros file manager program. So by my example you will need a directory ~/plasmac/configs/myplasmac. Then copy all files and subdirectories from ~/plasmac/configs/sim/gmoccapy/plasmac/ to the directory you just created. Now you can cut the work in 1/2 if you are only going to use imperial or metric measures and not both. Delete all the imperial... or metric... files and links from your new directory and leave the system you want to use or leave both. The next part is a little tricky. Many of what you thought are files that you copied are actually just links to the real file and they are broken. I find it is easier to use your distros file manager program to make new links and replace the broken ones( they will usually have some sort of broken symbol if you use the icon view). Most of the files you will need to link to will be in the ~/plasmac/configs/sim/axis/plasmac/native/ folder. Once you have all the files copied and the broken links fixed we will be ready to make your working configuration.

My crystal ball is a little foggy lately so I really need you to post working examples of your .hal that has everything for your machine motion and physical I/O in it and the .ini file that calls it. I can post mine if you want to work it all out yourself but it is very confusing because of my pendant, gantry mechanics and hacks to allow limited control from Gcode.

John

Phill

Please let me know if any of my rambling comments need clarification. As I have said before there is always a better way waiting to be discovered. I know Rod has put some of this in place and Pedro has as well, I hope we can hear from them. I can post some examples of my Gcode files and the SheetCam PP if you want but I think that it is not the way to go, why perpetuate a Mach3 legacy approach. Did I say I am a poor coder?

John

islander261 wrote:

Phill

I know Rod has put some of this in place and Pedro has as well, I hope we can hear from them?

John

With my original gcode probing routine, there was no error checking so I could disable the torch on the console and the probe would time out and go on its merry way. Now I have some error checking this won't work.

This is not quite the same but here is an idea that might be able to be adapted.
More recently, I was getting spurious probe touch offs while cutting so in the gcode touchoff , I set a motion digital output at the beginning of the touchoff routine and anded that with the probe pin. Then I turned it off when exiting the routine.That way, the probe was only ever enabled when I was actually probing! I did then think I could extend this for height error checking....

So back to Plasmac.

Perhaps you could set a pin from the GUI to disable the torch. You could AND that with the motion M3 pin to trigger the torch on relay. That part is easy! But as you are doing this all in one component, you could just add an if statement so that if the torch is disabled, the wait for probe signal code is skipped and you just move to cut height. I think that would be pretty simple to code Phill.

For the record, I spent the morning working on my plasma machine so I can get a Ohmic sense wire up onto the torch. I really have to catch up with you guys. Then a supplier stuff up cost me the rest of my plasma building time. Hopefully over Easter I might get some time.