Another plasma component...

islander261 wrote:

Rod

I really don't know what to say, at some point we all need to get the correct .ini values for our tables. When I got mine set correctly most everything seems to be working correctly. The G54 Z offest had no effect on getting rid of the Pogo stick on my system, only the correct MIN_LIMIT fixed it ( my Zmax is at the top of travel, if your directions are reversed then it will be opposite). I only set the G54 Z offset once and Gmoccapy seems to remember it. The G54 X & Y offsets are set to the work piece origin or zero once for each work piece. On my system the G54 X & Y offsets are always 0 at startup.
John

John thanks. pretty sure my Zmax is at the top of travel. I'm just going up to the shed now. I kinda think my zmin is too low below the cutting surface so the probe height is lower than the material surface. So the probe is triggered when plasmac is not expecting it

Just a question for how far this project is so far.

When can i download a Linuxcnc release of this plasma version?
Can i do a git clone command for this version and install it as rip-environment?

I looked back into the post's of this topic yesterday. I mentioned it has negative adaptive feed and externall offset's branche included.

Maybe i can look at it and do some dry run experiments.
Don't forget to include a seperate simulation version. Just like in Axis !

Thanks !

Phill

Thank you, I think that the IHS Skip distance should be from the last probe location. At the end of the cut you really are only assuming you are at the correct height. For me at least the IHS Skip needs to work whether the THC was active or not the last cut. This may explain part of the behavior I saw today.

John

Phill

Yes, the Plasmac THC works very well. My problem is at least 40% of the cuts I make are without THC. As luck would have it most of these cuts are really close together and I don't like probing into the last pierces slag pile. So yes a pin or a check box to select pierce or end of cut reference.

I looked at the Gmoccapy Glade file and Gmoccapy python handler and it looks like it gets the current feedrate from self.stat.feedrate which is hooked to the LinuxCNC internals some how. Part of this code is well beyond my limited Python and LinuxCNC internals knowledge. Are you sure the remap of the F blocks doesn't mess this up some how? I do know that on my system the displayed F block is always the last non zero one and usually follows the F block in Gcode closely.

John

Rod,

My slats are pretty level, say about +/- 1.5mm. So I just had my Z at machine Z 0 and took a tape measure and measured down to the top of the slats from the torch shield end. I used this measurement as my MIN_LIMIT and a little bit less for my G54 Z offset. The G54 Z offset is only so your DRO makes sense when cutting. Mine is close right now, close enough I don't need to do math in my head to tell what is happening in the cut.

John

Phill,

NS (norber sneider) is quite good in renaming.
But he is a master coder !! I am not very good in python, python is not my style.



it's from self.s.feedrate (if feedrate status exists... check by man page)
Jes, it exists : . linuxcnc.stat attributes => feedrate (returns float) - current feedrate override.
Why override? Did we ask for this? The comment is not so carefully made for "override".

source is then self status channel.

The self.status.feedrate command will work also in Gmocappy source code

Multiple (re)definition's of this can be done in the same source file i think without concequences.

s = linuxcnc.stat() # create a connection to the status channel
s.poll() # get current values

To add in the github section of the linuxcnc readme file :
Source : github.com/paulscherrerinstitute/ecmaster