gmoccapy plasma struggle bus

Hello

I am using Gmoccapy for plasma. There is no automated way to generate your configuration, you must do it your self for everything beyond simple motion. I modified the GUI to suit my work flow with custom tabs. I knew nothing about doing this when I started and it took a rather long time with some really messy code to get it all working. I will post my configuration later today when I am at the shop.

John

tommylight wrote:

Rodw is using it, and maybe Icelander.
I use Axis strictly.......for now.

We (islander261 and I) found nothing was actually connected in the Gmoccappy plasma screen. We both extensively modified the screen set and its python handler (plasma.py).

The problem is there are many ways to do plasma there has not been a standard config for it. The new component by PhilC is the one that may well become the standard.

But always, just get a working machine (XYZ axes) with stepconf and then start modifying from there by hand editing your files.

Tommy ight can guide you with a working Proma config he uses that is published on the forum.

I have a working machine xyz, plasma. I'm cutting with axis. I want to use gmoccapy though.

We used a arduino in the plasma machine and did our voltage devider and have everything workling up to the thc. Havent had much time for that but will get it going.

I am cutting pieces but we see/want some of the features of gmoccapy plasma.

We are getting counting on the 7i76 encoder and the voltages show great with the pyvcp panel JT did.

We saw the gmoccappy plasma screen and thought we would like to use it. But if nothing is connected then I guess we either attempt to reinvent the wheel again and start coding or use axis.

Thanks, sorry for the rant.

I do not know much about plasma cutter, but if you have your machine working with axis, it should only be a minor work to change over to gmoccapy.

I coded the gmoccapy plasma gui just with information from the forum and the wishes i received. As i do not have a plasma table, i just made a sim config. The connections are there, but the hal part must be made. If I do understand well your post, you have the hal part working, and that must not be touched. The only part to modify would be changing the pyVCP panel to a glade panel.

I am pretty sure, that there will be a lot people to help, after you post your config folder.

Norbert

Ok, it really isn't that hard to splice any of the THC components into the plasma example of Gmoccapy. I probably would have done this if I had known about the working examples using Axis. You will want to build a tab using Glade for the UI and a Python handler for the actions if you need more than just HAL connections.

The hardest part will be getting the Glade Editor setup to run correctly and use all the HAL specific widgets. Some how by dumb luck I managed to get it working on my computer by following various directions I found here. Sorry I don't remember what actually worked or how to do it. I am not a programmer so it can be done by a layman. The Gmoccapy plasma example served me as a template for all the modifications I made, yes it was a bit frustrating at first.

I find the Gmoccapy plasma work flow suites me just fine, it is very milling machine, router like. I have combined limit/homing switches used to set machine coordinates and then use G54 offsets to set work piece location. The only thing I don't like is that I have never figured out how to backup if the torch misfires. I just edit my Gcode file and start over if I need to. I never have gotten the stock run from here to work ( most likely user error). There is an open source modified gcodeview program that if incorporated into Gmoccapy would allow backwards scrolling to a new starting point in the code. Sorry I don't know enough about programming to add it in. It is used with a Gscreen plasma UI so I think it will work.

I have attached a zipped file of my present working configuration. This uses a 7I76E and THCad cards from Mesa as the hardware running on an old Dell Optiflex 745. Sorry there is no simulation version so you are on your own to look at the working screens with out using Glade. This is hopelessly over complicated meandering code (did I mention I am not a programmer) but does work well enough for me to do production cutting several days a week.

John

Maybe I can help with some of the confusion about the plasma screen. There are many options on the plasma screen but not all are used or necessary. Some are for advanced use with your own custom hardware and HAL component. For instance, if your Z axis and THC functions are driven by a stand alone motor on the Z axis that is not controlled by LCNC but by the THC system.

I explained all the functions of the buttons and signals but maybe did not specify the separate uses.

I suggest that prospective plasma users read this first. It is a very comprehensive explanation of the plasma process and the meaning and use of all the functions, signals and features.

Gmoccpy Plasma Wiki

None of the plasma functions are internal to Gmoccapy or LinuxCnc. Everything is done outside in HAL or in a component and or hardware. So no signals will be connected unless they are connected to your own component or the THCUD component. The intention was not for the plasma screen to do any functional work but only provide the HMI interface. Some has opted to modify the plasma.py to accommodate their own requirements and as this is not wrong to do it does mean that future updates will destroy the work done. The idea was that unless the THCUD component works for you, each user would code his own component to manage the other complex functions.

THCUD does lack the finer controls such as corner locking. This can however still be done with another component and in conjunction with THCUD.

Please read the wiki and then feel free to ask before you get stuck in. It is not as difficult once you understand the finer nuances of plasma.

Marius, as the author of the Gmoccappy Plasma screen its a shame you did not weigh in when Islander261 (John) and myself were trying to put it together 18 months or so ago. We found there was no precedents to follow at that time. Many of us using LinuxCNC have moved past using external THC's and want to use the Mesa THCAD boards and manage the THC internally.

Neither of us knew anything about LinuxCNC. We were new recruits. There were bugs in the pin names which Norbert fixed on my report.

There was no explanation of how you might use the cut height and G0 rapid height settings. There are Gcode routines that bore no relationship with the GUI settings. Today, we can use External offsets but its only become part of master branch in the last month. We chose to use Sheetcam to get these values into gcode.

John worked out how to change plasma.py to allow GUI settings to also be controlled by Gcode which was a great step forward as we could use the GUI or Sheetcam to set up cut parameters.

Cornerlock was a pretty simple component to write. and it was my first foray into halcompile.
Master branch removed some pins so even the Z up and Z down LED indicators could not be extracted from HAL without writing a component (in the absence of a THCUD).

As we moved down the path of writing components, we wanted to extend the system and add auto volt sampling (another fairly simple component) and kerf crossing. These features are not in the GUI.

So in summary, Gmoccapy plasma seduces the user into thinking plasma is easy until you start joining the dots in HAL. It has promise but its far from complete.

I think in the future a new Gmocappy screen needs to be developed which is compatible with the work PhilC is doing becasue the guts of it could be prewired and support THCUD and Mesa THCAD type configs.

Marius, as the author of the Gmoccappy Plasma screen its a shame you did not weigh in when Islander261 (John) and myself were trying to put it together 18 months or so ago. We found there was no precedents to follow at that time. Many of us using LinuxCNC have moved past using external THC's and want to use the Mesa THCAD boards and manage the THC internally.

I am sorry that you had to suffer. Dont we all at some time. I was not available to assist but the documentation explains a lot in detail.
And a lot of us still uses our own external THC and not the Mesa stuff and therefore has to manage the THC externally.

There was no explanation of how you might use the cut height and G0 rapid height settings. There are Gcode routines that bore no relationship with the GUI settings. Today, we can use External offsets but its only become part of master branch in the last month. We chose to use Sheetcam to get these values into gcode.

I am sure that the document explains the purpose but you need to know how plasma works in order to understand the features. That the document cannot teach you.
Sheetcam is a good choice, I only use and supply that to my customers.

John worked out how to change plasma.py to allow GUI settings to also be controlled by Gcode which was a great step forward as we could use the GUI or Sheetcam to set up cut parameters.

This I have a huge problem with if the intention is to merge it to the live system. The GUI settings are not to be controlled but are to provide data to an external component that must do the controlling. It is not a step forward. Changing the GUI is not the way to go. You lock other users out.

Master branch removed some pins so even the Z up and Z down LED indicators could not be extracted from HAL without writing a component (in the absence of a THCUD).

That was the idea. You control everything from HAL

As we moved down the path of writing components, we wanted to extend the system and add auto volt sampling (another fairly simple component) and kerf crossing. These features are not in the GUI.

Again. They must be done in a component. Others might not want to use that.
All of the features and functions of THC and Plasma must be done outside of the GUI.

So in summary, Gmoccapy plasma seduces the user into thinking plasma is easy until you start joining the dots in HAL. It has promise but its far from complete.

You clearly did not read the document. I stated that it was not easy and I explained many of the problems. I also did my best to explain how THC and plasma works. The GUI was never intended to control the THC or any plasma functionality. It is purely meant to give the user all the possible input and output interface in order for them to create their own system.
Remember that there are ,many ways to do THC. Not just the Mesa way.

I think in the future a new Gmocappy screen needs to be developed which is compatible with the work PhilC is doing becasue the guts of it could be prewired and support THCUD and Mesa THCAD type configs.

Unless a new screen is written that explicitly services the Mesa product and it is named so, and the original is still available, it will definitely break other systems. I fully agree with variety but exclusivity or favoring one product is not playing the game.

I am glad that you got your system working in the end but I am a bit shocked at the attitude of wanting to change things when it is not understood. Also at the fact that it can be allowed to favor a specific product in doing so. I trust that the changes has not reach the master branch yet as I would object if it is done at the cost of the current working system.
I do support the idea of separate development for specific hardware but I do not support the idea that any one becomes the mainstream system. The original screen was written to enable any user to put their system to work on the LinuxCnc platform.

I think if I were to start again, I would understand how to use your screen better but it still has gaps. But that is an enigma in itself as there are many paradigms that can be adopted in the plasma world. Its not as clear cut as other CNC environments.

So while your screen may be a good fit for your paradigm, it may not be a good fit for mine or John's as there is no right or wrong way. We made the commitment to Gmoccappy, but the screens provided did not suit our paradigm so like many others we changed it. I know I tried to change as little as possible.

Don't get me wrong, the document was very valuable to a newcomer when I started.

Understood that Hal controls how it all hooks together. Thats why I wrote and shared so many "helper" components which came about as I enabled different parts of your interface.

I think you should take a closer look at PhilC's config as it is very generic and supports both Mesa style configs and THCUD/PROMA style configs. Its not going to lock anything in or out if it were adopted into master. It would be nice if it had a touch screen alternative.

If nothing else, I think combined efforts of many people over the last couple of years (you included) have advanced the plasma capabilities of LinuxCNC significantly. Furthermore, I think it has been proven that there is no need to use an external THC and by doing it in software has been producing superior results. But the Mesa THCAD is not the be all and end all of torch voltage measurement. There are many ways that arc voltage can be introduced into LinuxCNC but the THCAD board is a cheap and robust solution.

In my view, LinuxCNC has lacked maturity in plasma and we collectively have found a number of issues that was a problem for plasma, bugs have been fixed or work arounds have been devised as a result of our collective enquiring minds. LinuxCNC's was streets behind other systems with plasma control but I am excited to see that is changing.

Dewey Garrett put an enormous effort in writing a THC component using external offsets and I spent many many hours trying to get it going without a result. Sadly, it has not made it to master branch with the rest of the external offset code. Dewey showed how to build library hal files that connected all of the hard stuff centrally so the user never had to worry about it. Thats the piece gmoccappy plasma is missing. I wrote a torch sampling module so I knew I was starting on the voltage set point, not some guess of it from a cut chart when working with his PID based THC module.

LinuxCNC's capabilities are wasted on external THC's, it can do so much more once it has total control of torch voltage in the trajectory planner and HAL. I think it is important for a complete plasma config to find its way into LinuxCNC master branch but it should not be based on an external THC which by definition are quite crude devices. We can do much better! I look forward to seeing a mature plasma system evolve where the user just has to set a few INI file variables once he has a working stepconf or pncconf config. Until we think of that as the end goal, users will continue to walk around in circles.