Some thoughts and some findings using PlasmaC

tommylight wrote:

snowgoer540 wrote:

tommylight wrote:

snowgoer540 wrote:

Manually, I can jog (rapid) the torch until I'm blue in the face and I never get an error,........

Haha, what's that mean? Or are you just happy at the though of my torch jogging

Nah, i just imagined you blue in the face !

And that made you happy?! Am I going to have to start looking over my shoulder???

snowgoer540 wrote:

tommylight wrote:

snowgoer540 wrote:

tommylight wrote:

snowgoer540 wrote:

Manually, I can jog (rapid) the torch until I'm blue in the face and I never get an error,........

Haha, what's that mean? Or are you just happy at the though of my torch jogging

Nah, i just imagined you blue in the face !

And that made you happy?! Am I going to have to start looking over my shoulder???

Of course, i still remember the original Smurfs !
"I hate machines" .....

Franklin wrote:

I solved it by adding another dbounce for the float-switch. And when the Probing, signal comes through dbounce with a value of 5, and when the torch is on, the signal comes through a dbounce with a value of 500.

Could you elaborate on that, as that might be all that is required and since it is not always needed it would be best to keep it "as needed".

tommylight wrote:

snowgoer540 wrote:

tommylight wrote:

snowgoer540 wrote:

tommylight wrote:

snowgoer540 wrote:

Manually, I can jog (rapid) the torch until I'm blue in the face and I never get an error,........

Haha, what's that mean? Or are you just happy at the though of my torch jogging

Nah, i just imagined you blue in the face !

And that made you happy?! Am I going to have to start looking over my shoulder???

Of course, i still remember the original Smurfs !
"I hate machines" .....

Oh, the Smurfs! Ha, we're all a bunch of plasma Smurfs. Forgot about the Smurfs.

tommylight wrote:

That being said, most of what is written bellow is my fault for building very fast machines, and that brings the first issue:
-using speeds of over 3m/m for the Z axis will very often over run the soft and/or hard limits requiring to switch to joint mode and jog the Z axis down manually, then back to world mode to continue work.

It is hard to get a handle on this. If anyone sees this issue could they please post the values of the following hal pins while in the errored state:
axis.z.eoffset
axis.z.pos-cmd
joint.n.pos-cmd
ini.n.max_limit
ini.n.home
motion.eoffset-limited
(n = the joint number associated with the Z axis)

One thing I will mention is that when using eoffsets it is recommended that the joint not approach the soft limits, so the home position of the Z axis should be below the maximum limit for Z. I would suggest around 5mm (0.2") below and all cuts should be started at this height or lower.

in portrait mode the jog speed is stuck at the highest value, in my case at 36m/m, while the jog slider is where it should be and moving the slider will set the speed correctly.

Well it was something dumb I did. I have a fix and will push it soon. There is an almost complete overhaul of the docs plus a few tidy ups so when that is finished I will push everything at once.



EDIT1:

Another feature already discused with Phill is ignoring the float switch from the moment the torch on singal is active till the arcok goes true. This is to awoid arc lost issues caused by unshielded and cheap proximity sensors as they are usually located near the torch and i did encounter that issue.

I have a fix for that as well.

EDIT2:

-probe/floating switch is active only during auto mode, so bumping the torch into something while jogging will not stop the machine. It would be safer to have it active all the time.

My thought on this was to create a hal pin to do this and leave it up to the user to connect it if required. I have done some testing but there is an issue with asserting motion.feed-hold and/or motion.feed-inhibit if a jog has begun. It works correctly in teleop mode but not coordinated mode. I have submitted an issue and I guess we need to wait until something happens there. The plan was to use a 8 input or component because there are a lot of jog pins to keep track of. It did all work except for the feed-hold/inhibit bug.

On phone so short,
I have 10mm from soft limit to home, it gets over it.
Thank you.

I think i found another reason for lost arc during piercing when using plasma sources that fire instantly when they receive "torch on" signal:
It seems the torch on signal is given before the torch reaches the pierce height and stops, did it over 40 times today and as far as i can tell it is firing while moving up.
Just did some sim tests, It does trigger before reaching setpoint !

As usual latest master.

Yes, it would be possible that the last servo thread of Z motion hasn't completed when the torch is activated. A relatively easy fix if it is an issue.

EDIT: that would equate to about 0.016mm per 1000mm/min