Another plasma component...

phillc54 wrote: Rod,
I will see what I can come up with.
That's the problem with progress, one step forward and one in some other direction...

It may well be that I need to go back to a Combobox for the name and keep the name as the header and tool number as a setting although I am not sure how that will play out with tool selection...

Cheers, Phill.

I had a quick look at plasma_run.py and am scratching my head about alternate data structures. I don't do enough in python.

I keep coming back to SQLlite and this page has some guidance on how to load an SQL query into a combobox
python-forum.io/Thread-Need-help-adding-...to-a-combo-box-PyQt5

I think I might try and write a CSV file containing plasmac tool table entries and import it into a SQL lite database. This would get rid of the need to use an indexed array containing the tool table entries. With a bit of luck I could give Phill a select statement to use to load a combobox as per the link. Does not look to be too hard

I'd propose that the returned entries would be a single concatenated string that contains the toolD as well as the name. If we got that far, it should not be hard to add another drop down (probably hard coded to shorten the returned list (eg. select only the entries for Aluminium for example.)

Are you up to a challenge Phill?

In PyQT they have methods to handle data from a database.

TBH I am more interested in getting the functionality of tool handling working and the whole config working before doing a major change like moving to a database.
I don't have any experience with databases so it would be a slow process.
I also really like the flat text file system in that anyone with a text editor can easily change or add tools or at a quick glance can see what is in the file.
Also I am not really sure what the advantages of moving to a database would be having not used them before.
Is SQLite in the existing LinucCNC ISO's.
This doesn't mean that I am against the database idea, just that I wouldn't be comfortable doing it at this stage.
Having said that I am not averse to incorporating someone elses code into the config.

Cheers, Phill.

Phill, YEs, its time some of us help you with the code. I think the guts of plasmac is pretty well sorted now. if we get the SQL backbone sorted, you would not really need to do anything other than incorporate a combobox dropdown and the code to load it. The other small fragment would be selecting the toolID on a Tnn M6. I just don't know enough about the GUI side of things. We'd keep it to a flat file database rather than the complex relationships I proposed earlier.

Thinking through this a bit more, if we added columns for machine make (eg Hypertherm, Thermal Dynamics, Esab) and Model (eg. A120, 45XP etc), the database could be deployed with plasmac and variables for make and model could be set in the .ini file.

I loaded a fair bit of Hypertherm data (45XP and some PM65 from memory) previously so if I captured that and Stefan provided a CSV files for his machines once I have a template, we would have a fairly good starter dataset a user could select from just by modifying his ini file to select his make and model.

I'd propose the database is maintained by CSV file imports by an external python program so plasmac does not have the need to build a whole new GUI update form. Perhaps there is also an external script that creates a sheetam tool table from the DB. (Unless BigJohn writes a GUI for it).

I think the advantage of the database is mainly that it gets away from an indexed array by toolID and provides the ability to sort on name or any other criteria, plus the ability to drill down by make, model, material to save scrolling through a list of hundreds. Drilling down on material would require one more combobox but it could be populated from the one flat table as JohnT has done (with SELECT DISTINCT).

I'll make a start on this tomorrow night and see where it takes us. If the other guys come on board with data, we would not annoy you until we have something ready to incorporate. Hopefully BigJohn can help on the DB stakes if I get stuck. You just need to make sure you can populate the cut chart settings from a toolID (Tnn M6) for now.

phillc54 wrote:

Also hopefully, the pace of change will slow once Phill gets his tool handling in place. We must be getting to the end of it.

I am so looking forward to that.

I have been skipping this thread, as I don't have a Plasma, so don't think I have much to add.
But this talk of a HAL component having its own tool table causes me some disquiet.
I am wondering if this "component" has grown into something that should be something else?
(Possibly an alternative "Task" to the default "Milltask")

What was the problem with using the normal tool table?

There is a long-term idea to replace the current tool table with a database, and that would make adding extra data fields easy. I accept that you might not want to wait for that to happen.

Andy, This is much more than a component now, Its a complete environment with simulated GUI's that have been designed to be very easy to transfer to a real machine.

The problem with plasma is summed up by maruis in the wiki

Plasma operations on CNC machines is a bit of an orphan process.

The data we need has nothing to do with a tool but all about a material and its thickness. The only setting in the tool table that is of any use for plasma is the tool diameter (kerf width) so we can use a tool offset.

When you purchase a plasma cutter from a reputable manufacturer, it comes with a manual which can include 50-100 pages of cut charts. This is normally categorised by material type (Mild Steel, Aluminium, Stainless Steel) and a consumable set (electrode, tip, nozzle shield to use etc). The page will the list all of the cut settings for each thickness of the material (1mm, 2mm, 3mm.... 20mm.... 32mm).
Those settings include cut speed, pierce height, cut height, shielding gases, gas pressures, arc voltage and so on. That is the data plasma needs.

As you say this is not a milling machine, its a plasma machine. I revisited your SQL wiki page recently to see if it could be incorporated into a plasma model and there was not one relevant data entity for plasma.
There is no spindle, no magazines, no pockets, no geometry. I could not even see a setting for tool diameter in the wiki. Clearly, this orphan process is a totally different world to lathes and milling machines.

Phill started with a drop down list of cut charts, I observed it was missing the kerf width and it would be good if we could select a cut chart using the tool number to set the cutting offset for a given machine and its growing from there. But the cut chart is built into a GUI, not a component.

This is one of the most significant advancements of LinuxCNC for a very long time. It opens up a whole new class of machine that is being used more and more in industry. This config deals with plasma cutting at a very high level and there is a lot of experienced others guiding Phill.

There are few (if any) commercial plasma systems that can hold a candle to Linuxcnc running this config. I just hope that is recognised from the development team when the time comes to incorporate it into the development branch. The only change to the core code has been the incorporation of the reverse run branch and there are now enough testers to be confident that it is stable and working. Other than that it is just one new component and a couple of simulations.