Gmoccapy G0 feed override crash

Gents,

I converted some while ago my maho MH700C into a linuxcnc machine.
I am using Gmoccapy and running the linucnc version 2.6.8 (latest at the moment).

Yesterday I used a program my 15 year old son created via inventor /hmsexpress.
It was our first time we used the cad/cam soft to create a gcode program and it used the T1 M6 code to load tool #1.
As my machine was used before with handwritten programs my toollist contains already different tools.
I manually changed the T1 M6 into T6 M6 because tool #6 has to be used.
Unfortunately I forgot to change also the G43 H1 into G43 H6 (MY STUPID FAULT !!!, not my sons' and definately not linuxcnc !!!)
However, because of the new program I used the feed override slider to bring the feed to 0 !
I used the step by step button on the screen and the program executed everytime a step till the tool was changed and the spindle came to alive.
Then the step by step button was grayed out.
I couldn't figure out why so I decided to run the program in one way with the feed to 0 to get control over the machine.
With the feed on 0 one of the first codes was a G0 to bring the tool just above the part.
The machine started , WITH THE FEED TO 0, at full speed to the part. Because my tool length was not correct (G43 H1 instead of H6) the tool crashed into the part, well melted together. Of course I was to late to push on the emergency.

So I have to report 2 issues.
- What is the reason that the Feed override doesn't have influence on the G0 code but only on a G1?
- Why is the 'step-by-step' button on the screen grayed out.

Initially I tought that it had to do with the inventor/hmsexpress created program but I used one of my old handwritten programs and the machine behaves the same.
When I use the MDI and I type p.e.:
g0 x100
The machine will go full speed to x100 with or without the feed override slider to 0.
On the other hand when using a G1 x100, I have control over the machine with the feed override slider.

I just want to say also that NO external hardware/HAL pins are connected to the sliders.

Does anyone has an answer on the 2 upper questions?


Kind regards,

Noach

somewhere around 2.6 version of linuxcnc feed override was changed to only affect feed moves.
There was facility to have a separate control for rapid override.
There was still another that controlled 'max velocity' which affects both types of moves.

It is sometimes nice to have feed moves at full speed but rapids slow (or some other combination) - this is what the change was about.

I am not sure how Gmoccapy dealt with these changes but I'm sure there is a control for rapid override somewhere.

step button grayed out sounds like a bug...


Chris M

Chris, Andy,

Thanks for the reply.
Your explaination sounds logic.
I will use next time the velocity slider instead of the feed and it is probably not a bad idea to install an encoders or potentiometer to control the velocity slider.

But can anyone else who is using gmoccapy, try the 'step-by-step' issue?

Kind regards,

Noach

Sorry for the crash.

Please use the velocity slider to control the speed of G0 moves.

I will check on the spindle stuff as soon as possible.

Quedtion, why do you use G43 H1? After a tool change a simple G43 with no H value will load the correct compensation values. So please get rid of the H stuff and avoid such crashes!

Norbert

Hi All,

The G43 H? is generated by HMSexpress (the cam software) automaticly. If they didn't do that I probably not had that crash.

Yesterday I hooked my MPG encoder, which is used for the axis, with some logic to the Feed and/or Velocity slider.
During the tests I figured out the following :

- With the feed on 0, the velocity slider went also to 0. So when applying a G0 code I had control over the machine this time (strange isn't it?). This was not the case when the crash happend. So I wonder now the fact that the feed slider affect the G0 yes or no is depending of something different????? This is also contradictory to the statements we said before as since LCNC 2.6 the strategy was changed. But anyway I agree that controlling the velocity will always be the safest way to get control over the machine at all times.

- With hooking up the MPG to the velocity slider instead of the feed slider I noticed that with 1 puls of the MPG up or down the velocity slider moved very fast. While the MPG was hooked to the feed slider it worked fine in that way that more or less 1 puls changed the slider 1% up or down. With MPG to velocity slider I only need 5 MPG steps to go from left to right and this while the number which enters gmoccapy.velocity-override.counts and gmoccapy.feed-override.counts are the same. Seems that the scaling for both sliders inside gmoccapy is different.
It is maybe not a bad idea to create a pin like 'gmoccapy.feed-override.scale' and 'gmoccapy.velocity-override.scale' to control the sensitivity of the MPG or potentiometer in relation to the sliders??
So due to this scaling error I had to go back to the feed override but I don't trust the G0 code.

I will spend some more time in the future to test every time when I startup the G0 code and the feed slider to see when or not it has influence.

@Norbert :
Do you have any idea why the 'step-by-step function' is grayed out after a few steps ? The step-bystep function is very important to set up a new program.



Kind regards,

Noach

Hi Andy,

Thanks for the tip !
I hooked up in 'my machine'.hal file now the max-velocity and the MPG via the halui parameters and programmed a fix value for the scale with setp.
It works fine and I have nice control over the machine.
I used the :
halui.max-velocity.counts
halui.max-velocity.scale
halui.max-velocity.count-enable
... in the hal file.

@Norbert :
I assume that using the halui pins will not have influence or negative results for gmoccapy? Anyway the slider moves when the MPG is controlled.

Kind regards

Noach

Gents,

To come back to my 'step-by-step' question earlier in this thread.....

This problem is solved after I upgraded to LCNC 2.7.0.
Now the step by step is working fine.

Noach