Tool Table

Hello

I have been inspired by Phil's work and his Gmoccapy ui implementation. It is not exactly what I would have done but I am a cutter and not a coder. Now for the topic at hand. Has there been any consensus about how to handle plasma machine tool tables? I ask this because it is central to me moving ahead with a new plasma machine controller now that I think I finally understand how to make a Linuxcnc plasma controller from scratch. My present lcnc control does work well ( it leaves my old commercial controller so far behind I finally removed the last vestiges of it from my system this week) with the integrated THC but it is a real kludge because I only thought I knew where I was going when I started. Yes I know, plan the work and work the plan and at all costs avoid feature creep. This is a great way of working when you think you know where you are going.

These days when plasma cutting we generally use a CAM program with a rather complicated post processor to handle all the things we want to do for plasma cutting. My present thoughts are how do we make plasma cutting a bit more like running a mill? By this I mean tool selection in Gcode against a tool table and selecting the cutting side of the profile with G41 or G42. My milling machine is much simpler to run than my plasma cutter. I realize that the stock lcnc tool table does not have enough tool parameters for plasma cutting but I think that is an easy fix. What is harder is developing a consensuses of a tool table file structure that everyone can use. I can always fall back to using the old SC tool table file structure but this seems a bit like doing it this way because it is how we always did it instead of looking for a better way.

Now to the parts that are beyond my internet and coding knowledge. Can someone please cross post this to the Gmoccapy thread because I think Norbert may want to weigh in here (hope). Second is If I start from Phil's work with the reverse run how do I keep the rest of the master branch updates current without loosing the reverse run and other important parts of Phil's work? Sorry I know jack about using GitHub and find most user guide including Phil's quite confusing.

John

John, I doubt a consensus will emerge. The reason I say this is that the data structure is complex and not suited to a flat file/csv format. To do it properly it requires a relational database (eg SQL). Not many people understand how to design a relational database.

You need to think in terms of one-to-many and many-to-one relationships (or parent and child records). The classic example is an invoice which has a parent invoice header and many invoice line items. We can say there is a many-to one relationship between many invoice lines and one invoice header. But it goes much deeper then that becasue each invoice line item will link to product records and invoice headers will have shipping details and customer details attached to it.

So the knack in designing a database is to make a list of all of the data items you need to collect (think database fields) and then determining the data entities (think database tables) that the data items should belong to. The key here is that there should be a single point of truth in the system for each data item so there is no duplication in the data maintained (called data redundancy). So if you find you have duplicate data/data redundancy, then you have got the fundamental design wrong from the very beginning.

Good database design uses a unique (auto-incrementing) index number that is used to create the links between the various tables that is used as an index field. This makes it very quick and efficient to lookup related tables during database queries so when we send data to the user we build an appropriate view of the data for that specific use.

In SQL, there is a SELECT statement that allows you to JOIN tables together to create a virtual table with the related fields and a WHERE statement that allows you to only report on a selection of records(eg show me the cut chart WHERE the material is mild steel AND the machine is a Hypertherm 65).

Andy proposed a database structure using SQLlite for the milling machine tool table. I think this is it wiki.linuxcnc.org/cgi-bin/wiki.pl?ToolDatabase

SQLlite is supported by python so I think the way forward is to use SQL and access the database from within the GUI via python

I did some initial design work and created some initial tables and a cut chart on Phil's thread here
forum.linuxcnc.org/plasma-laser/35449-an...nent?start=10#119922
I know I have to add shielding gas as a machine option to the database. Have a look at the two python scripts and run them and see if with the background above you can understand what is going on as a first step.

So what I propose is given you are the cutter and I am the coder is that you tell me what you want, I'll design the database and the queries required which you can fold it into your GUI. If we get that far, maybe we can convince Phill to incorporate that into his GUI which might eventually find its way into the master branch.

andypugh wrote:

Years ago I made a start on defining a database structure for the LinuxCNC tool table:
wiki.linuxcnc.org/cgi-bin/wiki.pl?ToolDatabase
One advantage of a database is that users can add their own data to the table with no worries about the system not being able to read the default expected data.

That said, there are many columns in the existing tool table that could be used for other purposes. Your Plasma machine will simply ignore ABC and UVW offsets, and will also pay no attention to orientation, frontangle or backangle. Those numbers could be used to populate different settings.

Andy, thanks, I linked to your wiki page in my earlier post. I noticed that it appears incomplete as none of the examples are shown (You say at the end "Examples: 1: Simple three-tool setup" but the document ends at that point). Do you still have them? It would be good if you could add them to the wiki.

I have to say my first thought is that the data entities required to configure a plasma table are vastly different to that for a milling machine with a tool magazine. The cutting parameters are defined by the power supply driving the torch rather then what tool the operator loads into the magazine. But I have seen a plasma machine with a drilling head and tool changer mounted on the gantry. Other machines might have an engraver or a oxy torch mounted. Clearly, the multiple spindles would help define these instances. Perhaps a spindle type needs to be added and if the type = plasma then branch off and extend your proposal via different tables that extend your proposed data set.

I think one thing that needs to be preserved is the kerf width mapped to tool diameter so cutter radius compensation can be used as per the standard G41/G42 commands. I still have to get my head around them. I'm kinda hoping I will have a bit of down time in the coming months and have got LCNC running in a VirtualBox to work on some of these things. I might even try my hand at QTPyVCP and build an interface. ONe advantage of SQL is I can add new field to your structures (or join a new table with 1:1 mapping without breaking anything for the tool table... I just don't know much about the tool table...