Spindle direction signal when stopped

Just about completed a hardware project that gives PathPilot (V1) control of spindle RPM and direction of a SiegSX3 mill.

A limitation of the mill internal software is that the spindle direction can only be changed when the spindle is rotating. What this means is that when the spindle starts it always runs in the direction it was previously then changes direction if required. Not much of a limitation in practice as I can't remember ever running the spindle in reverse.

Not much of a limitation apart from one thing...

Under PathPilot control when the spindle is running forward and is then stopped, the direction line, a gpio out of a 5i25 card, goes from high to low which is a change from forward to reverse, Next press of the PathPilot FWD button sets the line high, forward again.

My hardware faithfully follows the direction line, the spindle starts forward, switches to reverse for a few rotations then back to forward and runs up to speed. I can probably fix my software to eliminate this with a few lines of C but setting direction line to reverse when stopped seems a bit odd.

I can't see where this is happening in PathPilot (I may have missed it) so is it happening LinuxCNC and if it is is it by design?

Is there anyone with a more knowledge of PathPilot and LinuxCNC than I have (which is not much) shed any light on the direction line behaviour?

Ken.

I can test that for you if you can tell me what you want to know. I am still in test mode with PP. I can run Halmeter while running PP.

( TP

andypugh wrote:

I would generally anticipate DIR = 1 to be reverse. I suspect that this might be an assumption somewhere in the code. ie spindle-on S=0 has dir = 0.

I understand that as a logical assumption.

One thing has just occurred to me, my assumption that the inactive state of motion.spindle-forward implies reverse is wrong. It means spindle is not running forward, motion.spindle-reverse being active is spindle reverse. Either can be active or both can be inactive.

Can you attach the HAL?

The HAL I use is standard PathPilot V1.9.3 unchanged, I won't attach it all given I think I now understand whats going on. The only relevant part is two lines:
I'll have a poke around and look at both motion.spindle-forward and reverse and if I find the above to true it's a easy HAL fix.

Thanks, Ken.

Vmax549 wrote:

I can test that for you if you can tell me what you want to know. I am still in test mode with PP. I can run Halmeter while running PP.
( TP

That's very kind of you.

If you can look at the states of motion.spindle-forward and motion.spindle-reverse in the three spindle states, stopped, running forward and running reverse it may confirm the way it works..

I can run the hal monitoring tools myself but by the time I rediscover how to use them again you will most likely have it done.

Thanks for the offer of assistance,

Ken.

stop - For = false Rev = false
forward - For = true Rev = false
reverse - For = false Rev = true

Direction pin

stop = false
forward = true
reverse = false

Transition from forward to stop changes Dirpin = false
Transition from Reverse to stop changes Dirpin = false

Hope that helps, ( TP

Thanks for that TP.

Early this morning (its not 9AM yet) I fired up halshow in a terminal with PP running on another screen and got the same results. I was expecting some 'opposition' from the hal tools but I must have setup this install already.

My plan is to use a set/reset flipflop to latch the motion.spindle-forward and reverse signals and use the f/f output to drive the direction line, that way the direction out will only change when a different motion.spindle signal comes active to what was last active.

Of course PP1 doesn't have the flipflop component so thats next.

Thanks all, Ken.

Completed my spindle mod and fixed the problem.


I had to reverse the forward and reverse signals setting and resetting the flipflop, as the f/f comes up reset it would have defaulted to reverse. This needs an inversion to get the direction correct, be nice if the ff had an inverted out.

I notice the flipflop output is an 'io' pin not an 'out', does this mean I could preset the output with something likeand go back to plan A without the inversion? Or does this permanently set the ff out to 1, never to change again?

Ken

andypugh wrote:

Note that flipflop does now have an inverted output pin.

Good, I was going to start a campaign.

It will hold the setp value until the first clock pulse.

Looks like the inverted out will also respect the set/reset ins if not clocked.

The new inverted pin is also 'io'. Does this mean the outputs can be set to an illegal state which will persist until there is clock or set/reset activity?

Ken