Another plasma component...

More
28 Apr 2019 03:20 - 28 Apr 2019 03:22 #132151 by rodw
Replied by rodw on topic Another plasma component...
John, I dug a bit further and found this note about external offsets
linuxcnc.org/docs/devel/html/motion/exte...-offsets.html#_notes
"If an axis.L.eoffset-enable hal pin is reset when its offset is non-zero, the offset is maintained."

Thats what was worrying me. I thought maybe the offsets would unwind if this pin was deasserted but it does not.. This is exactly what we want.
So looking at the plasmac pins there is
pin out bit     offset_enable               "enable offsets, connect to axis.z.eoffset-enable";

So I think you could safely and2 plasmac.offset.enable and motion.digital-out-00 and connect the and2.out to axis.z.eoffset-enable
So that would let you control it from gcode. (M65 P0 would hold THC and M64 P0 would enable it). Make sure your post sends an M64 otherwise you will never have THC :)

I would recommend you create a new hal file and use unlinkp to remove this linked pin set and reestablish it. That way plasmac stays intact and make your life and Phills easier. (this unlinkp approach is how Dewey wanted people to work with his config) and it really is a good idea for future maintenance.

Have you tried auto volts? I can't see any reason why you should not use it (other than archaic habits developed in your Mach3 days)
Last edit: 28 Apr 2019 03:22 by rodw.

Please Log in or Create an account to join the conversation.

More
28 Apr 2019 03:29 - 28 Apr 2019 03:34 #132152 by islander261
Rod
I presently have a working external THC enable from Gcode working just fine. It works no fail, I don't change in the middle of a cut. I am sure that Phill will get around to including it in Plasmac as it was there before. I actually use an OR2 component and and don't select the THC enable from the GUI.

Actually I am not ready to try the auto volts yet. The ohmic probing has about .010" error when physically measured on my system right now. The good news is the error is on the plus side so I am not burning up consumables. For people cutting thicker material (< 6mm) and using a well calibrated float switch I say try it. Right now I get over 3,000 pierces out of a Copper Plus electrode so the whole compensate for electrode wear thing is in the noise for me.

John
Last edit: 28 Apr 2019 03:34 by islander261.

Please Log in or Create an account to join the conversation.

More
28 Apr 2019 03:45 #132153 by rodw
Replied by rodw on topic Another plasma component...
John, thanks for clarifying.

Phill, I think plasmac needs an two input pins for external-thc-hold-a and external-thc-hold-b.
And these together in the component and if output true, hold the THC. Permanently connect hold-a in your config to motion.digital-00 so there is a mechanism to enable/disable the THC from gcode.
That would leave hold-b for user defined requirements.

I might then be able to experiment with my external kerf crossing module and once its confirmed as working, the core code could be fed back into plasmac. I severed some sheets yesterday and I did see a bit of a dive at the end of the cut with the current algorithm.

Please Log in or Create an account to join the conversation.

More
28 Apr 2019 03:58 #132155 by rodw
Replied by rodw on topic Another plasma component...

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


Sorry I glossed over the bit about the loudmouth. The penny just dropped. :lol: :lol: :lol:

I'd like to think this will find its way into Master branch shortly. The only change to the core code is the reverse run and there should be enough test data to confirm that works from this group alone to satisfy the most demanding skeptic!

Please Log in or Create an account to join the conversation.

More
28 Apr 2019 15:19 - 28 Apr 2019 15:23 #132180 by JTknives

Last I checked the plasmac branch uses both EO (now incorporated in the master) and reverse run.

Without working .hal and .ini files we can only get to all of the copying that will be needed to start building a working configuration. To start with make a new directory, say myplasmac or what ever you want, under ~/plasmac/configs/ using either a terminal or your distros file manager program. So by my example you will need a directory ~/plasmac/configs/myplasmac. Then copy all files and subdirectories from ~/plasmac/configs/sim/gmoccapy/plasmac/ to the directory you just created. Now you can cut the work in 1/2 if you are only going to use imperial or metric measures and not both. Delete all the imperial... or metric... files and links from your new directory and leave the system you want to use or leave both. The next part is a little tricky. Many of what you thought are files that you copied are actually just links to the real file and they are broken. I find it is easier to use your distros file manager program to make new links and replace the broken ones( they will usually have some sort of broken symbol if you use the icon view). Most of the files you will need to link to will be in the ~/plasmac/configs/sim/axis/plasmac/native/ folder. Once you have all the files copied and the broken links fixed we will be ready to make your working configuration.

My crystal ball is a little foggy lately so I really need you to post working examples of your .hal that has everything for your machine motion and physical I/O in it and the .ini file that calls it. I can post mine if you want to work it all out yourself but it is very confusing because of my pendant, gantry mechanics and hacks to allow limited control from Gcode.

John


Ok, I started to fallow your instructions and got the new folder created and the files copied over from the sim area. But i don't see any broken links. I tried opening each "file" and thy seamed to open fine by just double clicking on them. Am I missing something? Here is a shot of the new folder with the copied files. Also i do have working .hal and .ini file that moves my machine. I think I still need to tweak them to get proper dimensional moment, acceleration and what not.
Attachments:
Last edit: 28 Apr 2019 15:23 by JTknives.

Please Log in or Create an account to join the conversation.

More
28 Apr 2019 15:57 #132183 by islander261
Rod just started a Plasmac how to thread last week look here:

forum.linuxcnc.org/plasma-laser/36410-in...her-plasma-component

John

Please Log in or Create an account to join the conversation.

More
29 Apr 2019 05:03 - 30 Apr 2019 06:43 #132239 by phillc54
This development phase is very time consuming so I need to reduce the burden by cutting back on sim configs.
My preference would be to revert to one GUI for the time being and revisit others if needed when when the component development is more complete.
It seems like most users run Gmoccappy, would that be correct?.
Is any one using Axis, if no one is that would be great, I could remove both...
If you use Axis, which one do you use, Native or GladeVCP.
I don't believe any one is using QtVCP as that is one I did for myself using Chris M's development work so I will remove it and get back to that later.

The order of work will be:
Complete the statistics tab, this is half done so I don't want to start something else until it is complete.
Provide some different IHS Skip types of which one will be set in the ini file.
Get the Cut Parameters to load from a gcode tool change.

Current IHS Skip was supposed to follow HT ArcGlide operation:
Skip IHS: This parameter optimizes production by reducing the time between cuts. If the next starting point is within this distance of the end of the previous cut, the THC skips the IHS. When this happens, the torch goes directly to the Pierce Height and skips contact with the workpiece. This setting can improve the overall machine production rate. Set this parameter to disabled to disable this feature. Skip IHS will be ignored if:
- Sample Voltage mode is active and an IHS is needed for arc voltage sampling (six arc voltage samples are required before IHS can be skipped)
- The THC is not in Automatic mode

I read this wrong and made it be in THC enable AND Auto Volts mode, I will fix that...

Plasmac uses three arc samples, would six be better?

I was thinking of four types: I am doing two types:
1. within distance of end of last cut AND THC enabled
2. within distance of end of last cut AND THC disabled
3. within distance of start of last cut AND THC enabled
4. within distance of start of last cut AND THC disabled or enabled

Regarding gcode tool change:
We will need to integrate with the existing tool table to allow for G41 & G42 for the kerf widths.
We will also need a tool number as a setting for each material.
I have a couple of ideas in mind but will know more after a bit of experimenting, also I won't be able to do anything that ties it to any particular software.

John,
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?

Whatever I have forgotten will follow...:unsure:

Cheers, Phill.
Last edit: 30 Apr 2019 06:43 by phillc54.
The following user(s) said Thank You: rodw

Please Log in or Create an account to join the conversation.

More
29 Apr 2019 07:30 #132249 by Dee436
Replied by Dee436 on topic Another plasma component...
I have struggled to get any time out of work to try Plasmac, I managed to get a couple of hours over the weekend and did a fresh clone, but although the sims work fine, when trying to use it as a live solution I got a screen dump and locked pc.

I have booked 2 days off work next week to dedicate to getting this up and running,

I will be using Gmoccappy
The following user(s) said Thank You: phillc54, rodw

Please Log in or Create an account to join the conversation.

More
29 Apr 2019 07:58 #132250 by rodw
Replied by rodw on topic Another plasma component...
Gmocappy alone is good with me and it aligns with the instructions I've written.

I think 3 arc samples is fine. I've found if it does not work the first go, It won't on subsequent goes without some user intervention. eg. Put the earth clamp back on, lower pierce height are a couple I've had today.

I was thinking of four types:
1. within distance of end of last cut AND THC enabled
2. within distance of end of last cut AND THC disabled
3. within distance of start of last cut AND THC enabled
4. within distance of start of last cut AND THC disabled



Option 2 can't exist, you can't base the skip from the end of a cut if THC is disabled can you?
Does THC need to be tied into this?
Can't it be:
1. within distance of end of last cut (THC enabled is implied, so if not enabled, ignore and probe anyway)
2. within distance of start of last cut (implies it does not matter if THC is disabled or enabled)

Regarding gcode tool change:
We will need to integrate with the existing tool table to allow for G41 & G42 for the kerf widths.
We will also need a tool number as a setting for each material.
I have a couple of ideas in mind but will know more after a bit of experimenting, also I won't be able to do anything that ties it to any particular software.

John,
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?
Cheers, Phill.


Sounds like a good start re the tool changer. Sorry about coming up with the idea. It will be very powerful. Sounds like it needs to be done within a separate tool changer module. Perhaps the GUI can update the displayed material based on a change of the tool number it receives from the tool changer.

John,
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?
Cheers, Phill.


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)

Personally, THC will always be enabled at my end after plasmac walk up a badly warped bit of aluminium today. By the time I was ready to take a photo, the heat had gone and the warp subsided a lot.

I have to say I read your Hypertherm reference document today, I had not seen it before. Hats off to you for the research. Once I got my head around it it makes sense. if the THC is accurate, there is nothing wrong with the end of cut. Thinking about it, it could be inclusive:

eg
If (this_start_of_cut_pos < skip_distance from end_of_last_cut AND THC_enabled AND end_sensing_enabled
or if this_start_of_cut_pos < skip_distance from last_probe_pos) 
    skip probing.

This kinda gives you the best of both worlds. Assuming an accurate THC, there are 2 positions we know to be true. The last probe position and the end of the last cut (actually where THC is disabled). If you don't want to skip, then the user set the skip distance 0.1

Sorry about thinking out aloud...
The following user(s) said Thank You: phillc54

Please Log in or Create an account to join the conversation.

More
29 Apr 2019 08:09 #132251 by phillc54
I have just pushed an update for the completed stats tab in Gmoccapy. It may need some refinement but I think it is close...

rodw wrote:
Option 2 can't exist, you can't base the skip from the end of a cut if THC is disabled can you?
Does THC need to be tied into this?
Can't it be:
1. within distance of end of last cut (THC enabled is implied, so if not enabled, ignore and probe anyway)
2. within distance of start of last cut (implies it does not matter if THC is disabled or enabled)

At the moment it is your #1 (when I fix my error) and John would like your #2, I just added the other two to fill in the blanks but I would be happy with just the two you suggest.

Cheers, Phill

Please Log in or Create an account to join the conversation.

Moderators: snowgoer540
Time to create page: 0.214 seconds
Powered by Kunena Forum