Another plasma component...
Please Log in or Create an account to join the conversation.
is page 1 always updated with the newest version of the component
Yes, thats what git does. When Phill says he's pushed an update, you just need to go to your src directory (~/plasmac/src if you followed my instructions), pull it and recompile with these commands:
git pull
make
sudo make setuid
If there is only one change, then only that file will get compiled so it will only take a few seconds.
Please Log in or Create an account to join the conversation.
I didn't explain this very well, I meant as an override, so if you didn't specify it in your material then it would do what the GUI widget showed but if you specified it in your material then that would override the widget.rodw wrote:
phillc54 wrote:
Would it be practical to add THC Enable as a setting for each material then do everything from a tool change rather than a digital pin?
I don't think so. You might wish to rerun a part for testing with THC disabled or something. Keep the material selection strictly as a container for required cut settings (THC has no part in that)
I am trying ti find an easy (for me) way to do what John would like.
The git branch is but the notes only are when I remember or when someone reminds me...pl7192 wrote:
is page 1 always updated with the newest version of the component
Cheers, Phill.
Please Log in or Create an account to join the conversation.
Initially, I sided with John on this point but now I can see the case for the Phill method if you can trust the height control algorithm. I think now I have that trust. Running with the Mesa THCAD also adds trust. Its exceedingly accurate, manages noise well and is highly responsive to change in voltage. I suspect that is half the battle with THC's
Sometimes challenging the status quo is not a bad thing. It might not be a big a deal as John thinks it is. I'm warming to it.
Remind me to do some plots of plasmac cuts with halscope.
Please Log in or Create an account to join the conversation.
- islander261
- Offline
- Platinum Member
- Posts: 757
- Thank you received: 216
Thanks for all of the hard work.
The HT Arc Glide document is mostly the gold standard on THC documentation outside of their development labs.
I think that the IHS skip if enabled should work like your #1 and #4 examples. I make a lot of short, just pierce to .5" long cuts with no THC enabled when cutting open lines (I want a fat kerf so it doesn't fill with powder coating). Having IHS disable or a working IHS skip when cutting open lines function will be nice so the torch isn't trying to probe the slag pile from the last pierce.
I have used the reverse run in both directions to fix torch break away stops from tip ups and so far it is working fine, saved a number of pieces so far! The jury is still out on the Gmoccapy Run from Line (skip ahead) function, it has worked but not without some modal problems later. I think I have a Gcode fix for getting the correct modal state on starting but the remaining state is a Gmoccapy problem from my testing.
The statistics tab will be nice but certainly not at the expense of fine tuning the operation of Plasmac.
I will leave it up to the data handling experts to work out how to set cutting parameters from Gcode. Almost any method will be ok with me once it is defined so I can build a PP around it. I suggested using a tool table because that is what most PP have and LinuxCNC has a rudimentary built in one. The SheetCam one is fully extendable by way of the PP. One word of caution is that new users may have a hard time getting the kerf width (tool diameter) offsets working correctly, this is usually one of the trouble spots for new machine users and I expect no difference from new plasma cutters. Also SheetCam does not handle tool diameter offsets the same way as most machine tools, it actually changes the tool path in the Gcode instead of specifying the actual part size and passing the correct offset side required to get it.
I will checkout the statistics tab when I go out to the shop shortly.
John
Please Log in or Create an account to join the conversation.
The component is modified so you will need to run make.
The config files affected for each config are:
ini file
plasmac.hal
The ini file has the following added:
# sets the type of IHS skip, if not specified the default is 0
# 0 = if start of cut within skip-ihs-distance of end of last cut and THC is enabled
# 1 = if start of cut within skip-ihs-distance of start of last cut
SKIP_IHS_TYPE = 0
plasmac.hal has the following added:
# settings
setp plasmac.skip-ihs-type [PLASMAC]SKIP_IHS_TYPE
IHS skipping is also valid with the torch disabled so you can check with a dry run.
There are also a couple of sample files in the nc_files/plasmac directory.
It is possible to change the type between cuts if you are so inclined, I don't intend to add that to any of the sim configs.
Cheers, Phill.
Please Log in or Create an account to join the conversation.
- islander261
- Offline
- Platinum Member
- Posts: 757
- Thank you received: 216
I have had a look through the new IHS skip code. There is a very real possibility that I am not understanding the code correctly. From what I see when the plasmac.skip-ihs-type == 1 the skip distance is calculated from the start of the last cut. This way the origin for distance follows with each cut instead of being fixed at the last successful probe (the last place we know where the material surface is). Once you start this it is very possible to chain many small cuts for a long distance before probing again. It is very likely that you can be several cuts removed from the last probing location and still be within the IHS skip distance.
I will install latest and may get to testing today.
Sorry if I wasn't clear about what is needed here. If the logic is inverted then THC-enable and IHS skip type == 1 can mean work with THC (from end of cut) and == 0 no THC, work from last probe. If the logic is inverted then I don't need two signals from Gcode to control it only the THC-enable from Gcode.
John
Please Log in or Create an account to join the conversation.
That got me past the screen dump and locked up pc. After numerous changes to ini and hal files I managed to get linuxcnc to start. I also had to comment out the IHS skip line as I was getting an error along the lines it wasn’t in the array.
After I got plasmac started I noticed I had a strange issue where although I have a metric setup, it often starts in imperial and the jog speed displays in inch rather than mm, then other times it starts correctly in metric
My main issue at the moment is that I am getting joint following errors on all axis even though my Ferror and min ferror are the same as my working config, I am fairly sure it is to do with the real-time environment. I am going to get an hour before work in the morning to try another clone and configure but with a usr/real-time version switch to see if that makes any difference
How is everyone managing their ini file? if for instance changes are made to the sim ini file, are you all just manually copying those updates to your own .ini or is there a simpler way?
Please Log in or Create an account to join the conversation.
- islander261
- Offline
- Platinum Member
- Posts: 757
- Thank you received: 216
I keep my working configuration completely separate from the sims. That way the sims are automatically kept in synch with the latest release and are an unmolested reference point if I run into a problem. Yes, I do things the hard way, lots of manual copying.
John
Please Log in or Create an account to join the conversation.
I'm certainly not an expert here, but Rod has created an excellent thread about using plasmac that should help answer your questions.
Configuring Plasmac
Please Log in or Create an account to join the conversation.