keybinding question

You probably want to make a generic jog function.
send if AXIS, DIRECTION, STATE

in english programing description something like this:

def do_jog(self, axis, direction, state):
if state = true the jog the axis in direction times rate
if not state stop axis jogging

Nerd wrote:

@Chris,
One of my dream's is to make a material library in the program for cutting steel and inox and alu.
The purpose is to select a material and thickness.
The rest of the parameters are automaticly transferred to the plasma inverter with motbus in the cutting program.
Also the thc value's is then read in from the modbuss.
A lot of customer's want this build in function in the software. It make's life easer for them.

Its great to see this all come together for you Nerd.

The simplest way to manage your material library would be to include a copy of Sheetcam with your products. I think you could even convince Les Newell the author to build a post processor for you that works for your machines and provide your customers with basic nesting capabilities. I had a similar idea to your dream and thought that I'd look for a python database library that I could use. There are several of them and I'd look for a fully self contained library rather than something that interfaces with a SQL server.

I think SQL has been used for tool changers and there is some code around but I have not looked at what it does or how to use it. I suspect Andy will know a lot more. wiki.linuxcnc.org/cgi-bin/wiki.pl?ToolDatabase

Andy had some great code going there on that project.
Unfortunately I think he got discouraged from an apparent lack of interest from other developers.
The tool table does leave something to be desired.

Chris M

@Chris,

The integrated tooltable in Linux can be great for plasma machines.

For example :
This software Italian made and has also a integrated tool table.
Swiftcut has it on all their machines.
Swiftcut is a Englisch company and produces at the moment max. 300 gantry machines every year. It's my biggest concurrent at the moment. They spent lot's of money on advertising Google. Swiftcut has a big investor behind the company. That's the only
reason that they are so big at the moment.

But. Linux is more and more powerfull then the Libellula software. If you don't know how to do. You buy Libellula and your machine will work.

It is maybe a good stratagy to build the tooltable extend's in the software. And also other functions. (negative adaptive speed etc.)
As you say Chris, a lack of interest has also i think to do with financial question's. If there is a budget to write software then the lack of interest can be converted to a great product in relative short time. I am willing to make a financial support to the linux community or the software developers who made this possible.

I would have thought Swiftcut sold more gantries than that when you look at their Australian distributor's lineup of 21 models.
www.machineryhouse.com.au/CNC-Plasma

I think that you need to be careful in determining what your total user requirements are and which ones of those are in scope of Linuxcnc. Off the top of my head, I think LinuxCNC's scope covers off on your negative adaptive feed, torch height control (THC) and the features required to support THC. In short, its scope is defined to managing the cutting process after a nest has been processed by a post processor and the Gcode for that nest has been generated. Its been said that plasma is an orphan CNC process because it is so different to other machines such as lathes and Mills).

I think the biggest advance that LinuxCNC could make is to build robust PID based THC components that the trajectory planner controls without this nonsense of external THC's (eg Proma, CandCNC Neuron etc). Thats how Hypertherm and the big boys do it and when Linuxcnc cracks that nut, it will be disruptive technology as it will potentially put many THC companies out of business (but it needs to be driven by a plasma manufacturer not a hobbiest). Dewey Garrett one of the core development team members has made the first steps with the external offsets branch. To my knowledge, only two of us have played with this with plasma machines and neither of us yet has a result yet but neither of us has had the time or resources to try very hard. You need Dewey on your development team.

I've written a couple of components that support the software THC model (eg corner lock, torch voltage sampling) but have yet to build a working kerf crossing (void crossing) component that works.

The other key component that needs to be added (and I see this as being part of the LinuxCNC GUI interface (be it Gmocappy, Axis or Grotius's own). In my view, this is not a tool table but a materials table that knows this material and this thickness requires these settings. If I was writing that, it would have a number of database tables (eg material, thickness, plasma machine make and model, book cutting speeds. Lets call it a database for now. So this database needs to expose itself to the world via a web based API or shared database structure so a nesting program can access the data. In today's world, I think this is probably a web based server that accepts and returns XML or JSON data structures. Such a web based system is probably 10 lines of python code (ok, maybe 100). I have a background in the printing industry and in that industry there is a communication standard called JDF (Job Definition Format) that allows a connected workflow control itself and be coordinated by a MIS system. I don't know if there is an equivalent industry standard for CNC machines, but this would be where a plasma manufacturer could build competitive advantage. Build an open source interface to the machine and let companies like Libellula to talk to it.

I had a look at the Libullela video. In my view this component of a plant control system is clearly out of scope of LinuxCNC and the accompanying GUI module that manages the materials database except that it needs to be able to access the materials database and send a nest to the CNC system via a defined interface. This software makes intensive use of maths (for nesting), graphics (for displaying the nest) and databases (for customers, materials, scrap material, quotes, invoices and so on). All of these systems needs to be analysed and distilled into data entities and the required fields, then the relationships that connect these separate data entities documented. From there the database structures can be defined.

I know I've rambled on a bit here but whilst I am just a hobbyist on this forum, I've purchased a lot of profile cut parts and some of those parts are cut on tables that are 90 metres long. Whilst it might be ambitious, I think Grotius or any other aspiring plamsa manufacturer needs to develop a functional block diagram of a production facility software model and then decide how much of the action it wants to take on.

The key today is software interoperability so determine your niche, select the building blocks you want to build and ensure you expose your system via robust API's so others can partner with you to provide the pieces you can't or don't want to build.

@Rodw,

Thanks for sharing idea's.
I say life is short. In the time we have, we must be satisfied of our work here on planet earth.

I am not as Trump, but i know Linuxcnc rules within a short time. Look ad android samsung phone's en television's.
Apple is also a sort of Linux source. Fanuc has been a leader for several years, but the fact's are changing.

The basic source code of Linuxcnc can not be written by one person. That is almost impossible. ( I have seen the source code earlyer today during 16 hours of non stop merging and compile and testing the output. )

I sometimes think it has been a artificial human that was so clever to write this. Just like the pyramid's in Egypt, they are at mm secure build in relation to the golden circle.

Linuxcnc is at this moment for my company the best choice to invest time in. I think my invest in time will help me the coming
10 years to be ahead off every plasma manufacturer in the world, including swiftcut.

So if we have a solid basis, the extend's of the software are simple and they are available. Must only be integreted by Norbert.
That's why i go to him in Germany. I hope he will be able to help.

We write a material table, we do a auto dxf to gcode imput. We do what we want. Because we have unlimited possibilities.

I have a little idea running in my head.



If you add a hash comparisement to Linuxcnc. You can add a material table in relation to the best output.
It can compare clients best tool jobs. Or get a second find on git or google when there is no data. Al these relation's are the beginning of artificial intelligence. Linuxcnc is thinking for you. Hashing can be dangerous. When you have a good pc and mind, you can solve any code with a trick.

I don't think hashing is the right approach. Its a low level technique and the world is beyond that today. I see a plasma CNC database as being a relational database so entity relationship diagrams (ERD) are more appropriate.See www.lucidchart.com/pages/er-diagrams

The key with a relational database is to make sure that a piece of data is only stored once to eliminate data redundancy. Sometimes they call this the single point of truth. To do this, you need to identify the entities the data fields belong to. These entities become the database tables and the fields therein. An ERD then graphically defines the relationships between the entities. and they will either be 1:many (father:child) or one to many (child:father). The lines representing these relationships define the database keys. The database development environment I've used allowed the data entry requirements to be specified for each field. Once the entity relationship was completed, you pressed a button and the system would generate a few million lines of code which was automatically compiled into a working program. Each procedure had 5000 or so embed points so you could insert lines of custom code in various places to customise the procedure. The application I built in this way had a central database server and satellite production centres in a 100 km radius. The system handled 150,000 production jobs with 98.6% ontime delivery before it was retired.

I think the data entities for a production Plasma system would be something like material, thickness, sheet size, plasma machine, operation, machine book speeds. The operation would tie it all together, something like, Hypertherm 45xp, mild steel, 2400 x 1200, 8mm thick linked to parent tables and its own fields like cut speed, pierce height, pierce delay etc. The GUI could allow drop downs to select the material and the workflow could set the environment up for a simple walk up job. Also the nesting program could access the same database and ensure when the nest was cut up the environment was configured automatically.The key to this is system interoperability so database app would expose an api to the GUI and the nesting program and any other third party system.

Anyway, we are well of topic. You have my email address if you want to explore this further.