Useful Plasma Thread

Sweet, any way to easily implement this yet?

Hi,

Sweet, any way to easily implement this yet?
how to install

In the readme file i added 2 comment's on the end of readme file. One for turning on adaptive feed and one for fixing rounded
corners. In the next update this is implemented in the source code.

Today i have started with python code for saving the plasma screen parameters to files that can be saved and load in the program.
It works !

A sample to write a text file in simple way :w+ means write, a+ means append / or adding lines, but w+ is good, we write everything at once. We don't want to be too
late for starbuc's coffee.
The first line it writes the text : Travelheight.
The second line it writes the text : value, this is the actual screen value of Travelheight.

So the text file, where the plasma tool is defined, in this example 45amp_4mm_inox.txt looks like this :
A sample of reading the value's back by selecting a file name, typed in a text entry box :
Now this reading and writing is working i will make the python code complete for all the parameters used for the component driven plasma program. The advantage is, that we now can make tool lists for different plasma machines, load them, save then and share them etc.
I will make standart tool list's, just like the Trump laser company is providing them.

After this is done, i will do the keyboard buttons to move the machine with keyboard. This example is giving a time ago by
Mr Morley, thanks to this example.

I have added a machine on button with 3 colors next to the emergency brake. Then it is better to see in what senario the machine is.
I have used it, and when it's orange i know it's only the internal emergency stop. So this is nice.

Color external emergency brake : red
Color internal emergency brake : orange
Color machine on : green

Maybe i add a blue color too, incicator for running program in auto mode.

I will work to simplyfy the plasma screen again. Now almost every plasma parameter is implemented in the component.
Using tool list's, it will not longer be a must too see every parameter on the main screen.
So the screen will be simplyfied. This is the current layout.


@Perry,

Thank you for your post.
and will be a testimony to LinuxCNC and your work.
That would be nice !
BTW mine will be on Mesa.
If you have your machine working with a standard and clean config, we can modify the hal and ini section.
But maybe we have already a mesa config for you at that time from someone else.
If you want to try the grotius config, still in development, you can install it. Rodw can do it for you with teamviewer.
Maybe Rodw can sent pre installed static (new type) hard drives around the world. That would be nice.

Hi,

I asked Rod for advise earler today about saving the plasma tools and parameters in textfile or in excel file.
We do it in Excel for now. I just made a working code thanks to a online example in just 2 minutes.

The python code behind the glade screen :


The output file after clicking a screen button :


So we now can make beautiful torch and cutting chart's data files, load them into the program, save them and share them.

xlsxwriter.readthedocs.io/example_demo.html#ex-demo

For new forum readers who are thinking what is happening here and how ?

Linuxcnc

1. a file, C coded, compiled and real time component for torch height movement is loaded in linuxcnc. This file has many i / o.
2. a python coded linuxcnc user interface screen.
3. a excel sheet to store and load data.

The excel data is readed and writed by the python file (linuxcnc screen code) and passed to the real time component.

A short example of the c code :

Hi,

Today i worked at the automatic screen resolution. I had to replace the whole screen layout in Glade. It's done now and it works
on small and big monitors. The window is auto resizing according to my wishes.

Small monitor :

Big monitor 1920x1200:

Looks great Grotius. That is a weakness in Gmcappy I think. Whilst it resizes between 4:3 and 16:9 screens, the 16:9 version I think is far to spread out and is not intuitive to use. Yours looks better as the buttons are kept together.

Hi Rod,

Thanks,

It's hard to make a screen that is clean and simple. I think the screen is a little bit to difficult to use at this moment.
But all parameters are used and important.

Now i am finished making a python tool list code in excel for writing data.
See, it works !



Tommorow i will expand the c code first with a few tiny things. Must add pierceheight_speed and probe_speed.
And a few more tiny things. Not very hard to do.

Last Saturday cutted several hours with this configuration. I was impressed.
One time the machine was probing where no material was. But it stopped probing at probe limit -10mm.
So i was happy. The travelheight is also the maximum value the thc can go up during cutting.

Grotius:

Does any of this code work with torch width offsets? In other words you pass a code like D01 that get referenced in your table to what the offset around the part should be. Operator can adjust this. Or does everything have to be programmed with hard coded dimensions.... IE is a 4 inch square part given dimensions of 4 " and the controller handles the actual outside tool path or is it have to be done on the programming software and send 4.06" dimensions?

@Perry,

At this moment only the torch cutting data can be saved and loaded, so kerf width (plasma kerf) i will adapt in the saving file,
good mentioned. Better adapt now for later on. I will also adapt the kerf widht, cuttings speed etc to the screen.
Cutting speed i must test first with the variable g-code output later on this week. I want to see when the variable g-code
is loaded, and reloading.. After seeing that i can write the c code easely.

But i need to do some homework to also implement this kerf width. Later on i will study the inkscape python code.
In linux my previous tests with tool offset's where not so good. Maybe you know the trick? Program's like dxf2gcode i have
already studied and used, but are not good enough to use. Reason, if you have a dxf dwawing 2000x1000mm full of figures,
dxf2gcode can't handle it.

If you look at me. I am 2 years now studying linuxcnc, i can not make a whole cad cam package for linuxcnc in a few month's or
can we? We do the cam nesting in inkscape?

Maybe Rod can make a cam nesting module for Inkscape?

This masterpiece of open source inkscape python code will do the trick later on. We will startup inkscape without you will see it.
It will use the code to do load a dxf right into the Gremlin screen, and it will make a cutting path with tool kerf offset's in the future. I have said this a few weeks ago, we must make contact with the russian guy, who has made the g-code tools for inscape.

This is the Russian guy, his name is Nick :


And Nick will do the trick. He is also interested in linuxcnc.

I vote for the russian guy to do the coding

But as far as kerf allowance goes I believe it simple as LinuxCNC supports a tool offset in Gcode doesn't it?

Rod

I have not tried to to use cutter compensation to allow for kerf width. Based on my experience using it with milling machines I think that for most engineering work that use mostly rectilinear shapes it will be worth while to try. I am not sure when trying to use it for cutting artwork with compound arcs and many arc to arc and arc to linear transitions that there may be some problems.

I have several reasons for this, and please remember that all of this is from my prospective of cutting parts (artwork) with lots of compound curves, guys doing mostly engineering work will not have these problems often. First I use a popular low cost CAM program to produce all my cutting code. It has a lot of trouble producing good code when outside kerf compensation (outside offset) is turned on. This is combined with the current trajectory planner arc transition error really makes a mess of things with the feedrate going to zero at unplanned places. Now my current work around is to make all my art work with the defined path being kerf compensated in Inkscape. I actually draw with lines that are the kerf width wide so I know what the actual cutting result will be.

I have used Gcodetools in Inkscape in the past. It actually works quite well and generated good code most of the time. The reason I don't use Inkscape for my final CAM any more is it doesn't have built in nesting capability (yes, I hand nested completed code as subroutines for multiple part files but it is still a PITA), you have to redefine the cuts for each instance of a part which is a PITA for me. Again this is my work flow for cutting full sheets only. I used Inkscape and Gcodetools when I first started and cut out one piece at a time. I bet Nick can produce a nice solution if he wants to.

I will fix a couple of simple files and try to use cutter compensation later this week and see if it makes the TP puke at arc transitions.

John