Another plasma component...

I use to use solidworks with esprit for all my milling. Started out hand coding using autocad 98 and the list function to get my xyz. I then moved to BobCAD r19 I think it was. And then onto solidworks and esprit. After that I moved onto a few other cam packages but solidworks and good ol autocad is my workhorse. I do still have a seat for BobCAD 19 back when a seat was an actual usb dongle. I had thought about digging it out to see if I could get that to work with plasma. Guess anything is possible with a bunch of modifications to the post. That’s what started the conversation with them. Sheet cam does look nice and I did download it and played with it a bit.

Ok, if I was running a job shop and paying for a bigger than 4' X 8' table with a hidef plasma I would defiantly be looking at using ProNest or something similar. Small table, air plasma go for SheetCam. Like I said before I paid for my license the first week I had it, just profit for the last three years. Your Acad or .dfx out from Solidworks will work fine. If your margins can't support SC then you are in the wrong business.

I'm not sure that I will say that SC is nice, especially the Linux version. But I have made plenty of profit with it and the cost of entry is ridiculously low. Using .dxf files for import bypasses its biggest weakness at the expense really nice Gcode. If you are cutting .25" or thicker you will never notice the difference.

Actually your knife blanks maybe simple (at least the ones I've had people ask me to cut) enough you can just use the free trial.

John

I got a quote a couple of years back for the Hypertherm Pronest software and the basic package cost upwards of $10,000 AUD and the flagship version was going to cost 30,000 AUD.

For what you can do value wise with Sheetcam there is nothing that comes close for the money.

PLASMAC Tn M6 toolchanger:
I've not tried this but it should work. The plasmac materials file needs three extra entries in it:
ToolID = Unique numeric number representing LinuxCNC's Tool Table Tool Number
KerfWidth = the width of the kerf (Tool Table tool diameter)
Thickness = the material thickness (in device units)

So when the machine is homed (eg when joint.X.homed, joint.Y.homed and joint.Z.homed have all transitioned to a true state),
Plasmac should loop through the Materials table and issue afor each material.

This will write out a tool table to the Plasmac settings
See: linuxcnc.org/docs/devel/html/gcode/g-code.html#gcode:g10-l10

So a Post processor (like sheetcam) just needs to know the ToolId for each material in the plasmac .mat file and issue an appropriate
and subsequently issue the appropriate G41/G42 command for inside and outside cuts before each M3 (And a G40 when done)

Adding the Z offset should compensate for material thickness so the probe height will always the same height above the material when changing from say 16mm to 1.6mm material.

If this can be done it would be waaay cool and as close as you can get to not having data redundancy (eg duplicate settings) other than in the post processor.

Finally plasmac could generate a sheetcam tool table which the user could import into sheetcam. This would truly make plasmac the single point of truth for all settings. Nobody has been able to achieve that with entry level plasma THC systems......

Rod

You are correct that this is testing that needs to be done. Plasmac is really close to being a little giant killer right now. Adding the tool management will push all other applications less than the HT integrated systems to the Mach ancient history heap.

I am sure that Phill has the skills to pull this off given what he has produced so far. We need to cheer him on to get his system running to move this beyond theory for him.

I have hacked in external control of the THC enable from Gcode which I hope makes it back into the main Plasmac fold soon. I unfortunately also need IHS skipping that is not dependent on the last cut being under THC using the Auto Volts to set the cut point.

John

islander261 wrote:

Rod
I have hacked in external control of the THC enable from Gcode which I hope makes it back into the main Plasmac fold soon. I unfortunately also need IHS skipping that is not dependent on the last cut being under THC using the Auto Volts to set the cut point.
John

John, Seeing, Phill's away, the boys can play!

Try the attached component. there is a new pin called
Setp it to a value of 1 and if you are really lucky, it should calculate the skip from the start position. Search for my initials "RJW" for the changes made. This is untested and I have not compiled it (written in notepad++ on Windows.) from the current GIT file.

I was a bit unsure exactly how to do it but I think plasmac needs an external_hold THC pin. THis could be permanently configured in Phills HAL stuff to always recognise M64/M65 via a digital output pin. This would let sheetcam to control it.

Rod

Thanks for the solution. You have seen my PP so you know it can use both the synchronous digital outs (turn on) and static digital outs (turn off). The latest version of my PP puts both conditions where the static switch should have no effect on program speed.

I have thought about rolling my own IHS skip that doesn't require active THC and Auto Volts but don't want to go there just yet. I am really trying to stick with the commonly supported branch for the time being. I have my own fully custom adaption of Gmoccapy if I want to get back to the fix it with every update routine AGAIN. Phill is such a much better coder than I am for the present time I will wait for him to tell me to get lost before hacking his code.

The Plasmac branch is really so good now that I don't want to go polluting it with my hacking. This has the potential to kill a Texas loud mouth as soon as someone releases a pre built ISO with a schematic/wiring directions to use the Mesa hardware.

John