Another plasma component...
06 May 2019 07:33 #132928
by rodw
Replied by rodw on topic Another plasma component...
Forgot to mention for the benefit of others, when you return your ini file to the new plasmac folder, you need to add this into it
# sets the type of IHS skip, if not specified the default is 0
# 0 = if start of cut within skip-ihs-distance of last successful probe
# 1 = if start of cut within skip-ihs-distance of end of last cut and THC is enabled
SKIP_IHS_TYPE = 0Please Log in or Create an account to join the conversation.
06 May 2019 07:34 #132929
by JTknives
Replied by JTknives on topic Another plasma component...
Ok I should be up and running and my voltage seams right as well.
The following user(s) said Thank You: rodw
Please Log in or Create an account to join the conversation.
06 May 2019 08:34 - 06 May 2019 08:39 #132933
by phillc54
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.
Replied by phillc54 on topic Another plasma component...
Rod,Does glade allow you to display 2 fields in a dropdown eg. Tool number and name?
We seem to have given up a lot of usability when implementing the tool table. I know most languages I've used allow this. eg. revert to a drop down with tool number and name on the one line
So if you have 200 or so tools in the table, this will become fairly unwieldy as you'd need an index card beside you to choose the tool you want.
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.
Last edit: 06 May 2019 08:39 by phillc54.
Please Log in or Create an account to join the conversation.
06 May 2019 08:36 #132934
by phillc54
Cheers, Phill.
Replied by phillc54 on topic Another plasma component...
Yes, if I list the ini file as changed with any update then you will need to check the new one to see if there are any alterations.Forgot to mention for the benefit of others, when you return your ini file to the new plasmac folder, you need to add this into it
Cheers, Phill.
The following user(s) said Thank You: rodw
Please Log in or Create an account to join the conversation.
06 May 2019 11:55 #132951
by rodw
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?
Replied by rodw on topic Another plasma component...
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
self.comboBox_3.addItems(self.pm_Combo)
def pm_Combo(self):
conn = sqlite3.connect('testdb.db')
c = conn.cursor()
c.execute("SELECT DISTINCT projectmanager FROM testtable2")
pmList = c.fetchall()
conn.commit()
conn.close()
return pmListI'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?
Please Log in or Create an account to join the conversation.
06 May 2019 12:07 #132952
by BigJohnT
Replied by BigJohnT on topic Another plasma component...
In PyQT they have methods to handle data from a database.
#load the database
db = QSqlDatabase.addDatabase('QSQLITE')
db.setDatabaseName(current_path + 'plasma.db')
#bind a query to a label
def materialInit(parent):
parent.materialMapper = QDataWidgetMapper(parent)
parent.materialModel = QSqlQueryModel(parent)
parent.materialModel.setQuery('SELECT DISTINCT material FROM cut_chart')
parent.materialMapper.setModel(parent.materialModel)
parent.materialMapper.addMapping(parent.materialLbl, 0, b'text')
parent.materialMapper.toLast()
parent.materialLast = parent.materialMapper.currentIndex()
parent.materialMapper.toFirst()
#connect the navigation buttons
def materialFwd(parent):
if parent.materialMapper.currentIndex() != parent.materialLast:
parent.materialMapper.toNext()
else:
parent.materialMapper.toFirst()
def materialBack(parent):
if parent.materialMapper.currentIndex() != 0:
parent.materialMapper.toPrevious()
else:
parent.materialMapper.toLast()
Please Log in or Create an account to join the conversation.
06 May 2019 12:20 - 06 May 2019 12:24 #132953
by phillc54
Replied by phillc54 on topic Another plasma component...
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.
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.
Last edit: 06 May 2019 12:24 by phillc54.
Please Log in or Create an account to join the conversation.
06 May 2019 13:06 #132955
by rodw
Replied by rodw on topic Another plasma component...
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.
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.
Please Log in or Create an account to join the conversation.
06 May 2019 17:42 #132978
by andypugh
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.
Replied by andypugh on topic Another plasma component...
I am so looking forward to that.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 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.
Please Log in or Create an account to join the conversation.
06 May 2019 20:59 - 06 May 2019 21:00 #132998
by rodw
Replied by rodw on topic Another plasma component...
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
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.
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.
Last edit: 06 May 2019 21:00 by rodw.
The following user(s) said Thank You: thefabricator03
Please Log in or Create an account to join the conversation.
Moderators: snowgoer540
Time to create page: 0.320 seconds