Another plasma component...

Facepalm, thankyou

John,
I intend to have another attempt at the m-code override parameters and I am trying to get my head around how it should work so I hope you can help me out with the following:

At the moment I believe you set thc-enable and cut-height from m-code, I can understand thc-enable but wouldn't cut height be better set by the cut parameters from the material selected on the panel.
Do you use a digital out for thc-enable and an analog out for cut-height, or just use analog for both.
If during a job a spin box value is changed should this then override the last m-code or should the last m-code be the value used until a new m-code or the end of the job.
When a job is finished should the original spinbox values then be set as the values for the next job or should they stay at what was last used.

If anyone else would like to chime in you are more than welcome...

Cheers, Phill.

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