Plasmac Component Refactoring

Hello Everybody,

I am building a machine that uses an interchangeable module system to either support oxy-fuel or plasma cutting. I started out using the plasmac component, but had a really hard time configuring it to work for me, tracing the flow of the switch-case statements was very difficult. 

I ended up starting from scratch, and using a lookup table to determine what to do. This lookup table is imported from a CSV file, so I can make the table in a readable way, then export.  I've made an "abstract class" with methods that each module needs to have. When the lookup table determines which action needs to be taken given the machine state, the function associated with the current module will be called. The functions themselves can return a call to another function, so when the lookup table spits out "PAUSED" as the method, the PAUSED function can return the correct cut recovery process, or the BEGIN_PROCESS can call the IMPLEMENT_ON function . There is also an option to force a function call from the GUI, so the user can probe at any time from the GUI or turn on/off the torch. 

I also rewrote the offset_move function to make it more intuitive (at least for me). An example call for height control would be offset_move(FROM_DATUM, MM, 'z', (velocity), target). Now I don't have to do calculations for the velocity in my function logic and it is all handled in the offset_move function. 

For probing, I wanted to support contour mapping, because there is not a great way to do THC on a oxy-fuel machine. This component allows you to probe an arbitrary number of points before the program starts, and then uses these points to calculate the "datum" from which the z height is set. You can also choose to probe only on the first pierce, or at each pierce like Plasmac is now. 

This currently will not work with the Plasmac GUI or really any machine besides mine, but if there is interest I can try and make it compatible. I think this method will be more readable and expandable. I am also curious to hear feedback on the concept, maybe there is something I am missing. I am pretty new at C, this is my first big project, so I am sure there are plenty of mistakes. 

I have attached the code I have right now, as well as the lookup table that my program reads. 

do you have the csv file to attach?

As a code base I rather like it. I have spent a vaste amount of time mapping out the call flows in the plasmac component and just from a readability angle this code is much easier on my eyes.

But I understand that plasmac has probably had an organic growth overtime as it was massaged and polsihed it to deal with ideas, quirks and bugs.

Cheers - J.

I've attached the raw CSV, the python script I use to process it, and then the file that the C program reads. The raw file is more easily readable but I decided I'd rather do most of the parsing in python than C, so there is that one intermediate step.And yes the plasmac code is very reliable, and definitely has fewer bugs than my code, hopefully as I work on it more they get smoothed out. 

The CSV files are txt files because the forum will not let me attach the CSVs, but you should be able to rename them and open them in a CSV editor
 

Thanks. Do you have this hosted on something like guthub? Just asking as from an ability to post bugs, proposed pull requests etc that will make it easier to utilise, maintain and potentially grow.

Assuming that is of interest.

I will post the code on GitHub this weekend, I have it the git repo with the rest of my project but I'll make a separate one with just this code. Glad to hear you are interested in the project.

I ike the code base, clean and readable. When you get it on git please post the repo link here.

I'm interested in the idea of being able to make it a seamless switch-out for plasmac. So a need for pin name/purpose alignment but then also a clear set that are unique to functions within this component.

Choice is good.

Cheers - J.