M19 spindle orientation command - question on implementation

Discussion:

Michael Haberler

2011-03-17 11:38:30 UTC

spindle orientation looks useful for toolchanging and maybe other stuff, and some people even have done it with VFD's; some infrastructure already exists in NML although it isnt fully implemented.

I'm looking at adding an M19 command similar to the Fanuc spindle-orient like:

M19 [R<orientation in degrees; defaults to 0>] [L<orientation cw/ccw>]

this is how I'd do it:
- turn off the spindle
- set a HAL pin spindle-orientation line to convey the degrees value
- set a HAL pin spindle-direction line to convey the cw/ccw direction
- assert a HAL pin orient-spindle line
- wait for a spindle-oriented HAL pin line to become true

Further HAL logic would take care of actually driving the spindle motor, taking feedback from the spindle encoder into a PID loop and assert the spindle-oriented pin when done (still making sense?)

my question:

all spindle commands go through motion which is realtime; the above sequence doesnt look to me like it has strict realtime requirements so I would rather go through iocontrol-v2 to do this.

Is this sound or am I overlooking something?

-m

John Thornton

2011-03-17 12:09:52 UTC

Permalink

Hi Michael,

While it will be nice to be able to orientate the spindle for various
operations a tool changer needs be be somehow a defined set of
operations that is called by M6. On my lathe I do it via classic ladder
but there is no Z movement needed so it works fine. On my VMC the Z has
to move so it would be more difficult in ladder.

The sequence for my carousel type tool changer is:

Rapid to absolute Z pickup/drop off position
Orientate spindle
Extend tool carousel
Release pull stud clamp
Move to absolute Z clear position
Rotate carousel to next tool via shortest path
Move to absolute Z pickup/drop off position
Clamp pull stud
Retract tool carousel

If you could incorporate a tool change script that can be customized by
the integrator that would be cool and make tool changers easy to do. I
hope the M19 leads us to that point someday before my 386 dies on the
Discovery...

John Thornton

Post by Michael Haberler
spindle orientation looks useful for toolchanging and maybe other stuff, and some people even have done it with VFD's; some infrastructure already exists in NML although it isnt fully implemented.
M19 [R<orientation in degrees; defaults to 0>] [L<orientation cw/ccw>]
- turn off the spindle
- set a HAL pin spindle-orientation line to convey the degrees value
- set a HAL pin spindle-direction line to convey the cw/ccw direction
- assert a HAL pin orient-spindle line
- wait for a spindle-oriented HAL pin line to become true
Further HAL logic would take care of actually driving the spindle motor, taking feedback from the spindle encoder into a PID loop and assert the spindle-oriented pin when done (still making sense?)
all spindle commands go through motion which is realtime; the above sequence doesnt look to me like it has strict realtime requirements so I would rather go through iocontrol-v2 to do this.
Is this sound or am I overlooking something?
-m
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers

andy pugh

2011-03-17 12:23:13 UTC

Permalink

Post by John Thornton
If you could incorporate a tool change script that can be customized by
the integrator that would be cool and make tool changers easy to do.

I can't find the docs, but I think he already has.

--
atp
"Torque wrenches are for the obedience of fools and the guidance of wise men"

Michael Haberler

2011-03-17 13:49:28 UTC

Permalink

Hi John,

actually this is in place in master already. I'm currently writing the documentation for all that toolchange stuff, but the code+example works.

There is a complete example with Tx and M6 remapped to o-word subroutines, as well as o-word procedure called on abort to fixup state as needed. A gladevcp panel shows the pins and has buttons to acknowledge them - sort of manually stepping through the change process.

try emc owordm6-ui.ini in configs/sim

The nc_files/m6demo.ngc file attempts to model the existing M6-through-iocontrol as closely as possible - it should be straightforward to add your toolchanger specifics here, or in the corresponding prepare(Tx) procedure in nc_files/tdemo.ngc .

(unfortunately I forgot to add the gladevcp UI file - you need to pull it from here until it's merged:
http://git.mah.priv.at/gitweb/emc2-dev.git/commit/4a67f60b742a17a69aa4d49868a5e3585047bb08 )

I'd be happy to help and am very curious to see some use!

-Michael

Post by John Thornton
Hi Michael,
While it will be nice to be able to orientate the spindle for various
operations a tool changer needs be be somehow a defined set of
operations that is called by M6. On my lathe I do it via classic ladder
but there is no Z movement needed so it works fine. On my VMC the Z has
to move so it would be more difficult in ladder.
Rapid to absolute Z pickup/drop off position
Orientate spindle
Extend tool carousel
Release pull stud clamp
Move to absolute Z clear position
Rotate carousel to next tool via shortest path
Move to absolute Z pickup/drop off position
Clamp pull stud
Retract tool carousel
If you could incorporate a tool change script that can be customized by
the integrator that would be cool and make tool changers easy to do. I
hope the M19 leads us to that point someday before my 386 dies on the
Discovery...
John Thornton

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers

John Thornton

2011-03-18 12:07:10 UTC

Permalink

Hi Michael,

I tried to get the patch but ran into problems so I'll wait for you to
commit the gladevcp ui file. I look forward to seeing that work.

Thanks
John

Post by Michael Haberler
Hi John,
actually this is in place in master already. I'm currently writing the documentation for all that toolchange stuff, but the code+example works.
There is a complete example with Tx and M6 remapped to o-word subroutines, as well as o-word procedure called on abort to fixup state as needed. A gladevcp panel shows the pins and has buttons to acknowledge them - sort of manually stepping through the change process.
try emc owordm6-ui.ini in configs/sim
The nc_files/m6demo.ngc file attempts to model the existing M6-through-iocontrol as closely as possible - it should be straightforward to add your toolchanger specifics here, or in the corresponding prepare(Tx) procedure in nc_files/tdemo.ngc .
http://git.mah.priv.at/gitweb/emc2-dev.git/commit/4a67f60b742a17a69aa4d49868a5e3585047bb08 )
I'd be happy to help and am very curious to see some use!
-Michael

Michael Haberler

2011-03-19 02:51:22 UTC

Permalink

Hi John,

I've reworked this branch to make it a single commit and it is rebased on master now.

so either picking http://git.mah.priv.at/gitweb/emc2-dev.git/commit/4e6577497aee1a5f9ec5db8504fe4dd9b52ec1ab or merging http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/add-missing-osubdemo-ui-file-fixed should work

sorry for this

-m

Post by John Thornton
Hi Michael,
I tried to get the patch but ran into problems so I'll wait for you to
commit the gladevcp ui file. I look forward to seeing that work.
Thanks
John

Michael Haberler

2011-03-19 12:23:49 UTC

Permalink

somewhat blushed I admit I had messed up my repo's history.

I do believe merging http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/add-missing-ui-file into master works to fix this, finally. Ahem.

-m

Post by Michael Haberler
Hi John,
I've reworked this branch to make it a single commit and it is rebased on master now.
so either picking http://git.mah.priv.at/gitweb/emc2-dev.git/commit/4e6577497aee1a5f9ec5db8504fe4dd9b52ec1ab or merging http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/add-missing-osubdemo-ui-file-fixed should work
sorry for this
-m

Post by John Thornton
Hi Michael,
I tried to get the patch but ran into problems so I'll wait for you to
commit the gladevcp ui file. I look forward to seeing that work.
Thanks
John

Chris Radek

2011-03-17 14:01:33 UTC

Permalink

How does it do unorient? Is that automatic at the next M3? M5?

Robert Harpham

2011-03-17 14:22:23 UTC

Permalink

Post by Chris Radek
How does it do unorient? Is that automatic at the next M3? M5?

M19 starts a Spindle Orient command,
M20 as well as M03 M04 M05 will cancel a Spindle orientation comand

Post by Chris Radek
spindle orientation looks useful for toolchanging and maybe other
stuff, and some people even have done it with VFD's; some
infrastructure already exists in NML although it isnt fully implemented.

also means Some of the boring cycles can be finished then also and
implemented. where you need to stop spindle, orient, move over and draw
out the hole..

Post by Chris Radek
I'm looking at adding an M19 command similar to the Fanuc
M19 [R<orientation in degrees; defaults to 0>] [L<orientation cw/ccw>]
- turn off the spindle
- set a HAL pin spindle-orientation line to convey the degrees value
- set a HAL pin spindle-direction line to convey the cw/ccw direction
- assert a HAL pin orient-spindle line
- wait for a spindle-oriented HAL pin line to become true

Michael Haberler

2011-03-17 21:19:13 UTC

Permalink

ok, so that means its a first-class spindle-state 'locked' in it's own, with operations to unlock it - thanks, I wasnt aware of that

it seems some machines have a lock pin which disables spindle movement when inserted and needs to be explictely removed; others might have a brake which may engage in any rotational position

so M19 would cause two different processes depending on machine:
a) essentially 'probe' the lock-engaged pin by slowly rotating the spindle, stopping when lock-pin switch opens
b) take orientation and direction from M19, hand over to PID controller until angular postion == orientation, engage brake, release PID control

M20 would in scenario
a) activate unlock mechanism (magnet, whatever) and make sure lock-pin switch is closed
b) release brake

outline:

- M19 will convey orientation and direction to motion.
- motion will get a spindle-orientation and spindle-direction pin fed with these two parameters.
- motion gets a disable-spindle-movement input which blocks M3/M4; this pin is positive-edge triggered
in case a) this would be fed the lock-engaged switch
in case b) this could be the brake-engaged switch; external HAL components could handle orientation/direction/PID loop and eventually set disable-spindle-movement
- spindle-state 'locked' is true iff disable-spindle-movement is true
- M19 will wait until disable-spindle-movement is true
- motion gets an release-spindle-lock pin (positive-edge triggered) which would, in M20 M3,M4,M5
- activate the unlock mechanism in scenario a),
- release the brake in scenario b)
- M20,M3,M4,M5 would wait for disable-spindle-movement to become false.

unclear to me: what's the difference between an M20 and an M5? both leave the spindle unlocked and stopped. Do we need an M20 at all?

I would have liked to make M19/M20 remapped tp oword procedures as well but due to the spindle state interaction I dont see any other route than new NML messages + extending motion

-mah

Post by Robert Harpham

Post by Chris Radek
How does it do unorient? Is that automatic at the next M3? M5?

M19 starts a Spindle Orient command,
M20 as well as M03 M04 M05 will cancel a Spindle orientation comand

Post by Chris Radek
spindle orientation looks useful for toolchanging and maybe other stuff, and some people even have done it with VFD's; some infrastructure already exists in NML although it isnt fully implemented.

also means Some of the boring cycles can be finished then also and implemented. where you need to stop spindle, orient, move over and draw out the hole..

Post by Chris Radek
M19 [R<orientation in degrees; defaults to 0>] [L<orientation cw/ccw>]
- turn off the spindle
- set a HAL pin spindle-orientation line to convey the degrees value
- set a HAL pin spindle-direction line to convey the cw/ccw direction
- assert a HAL pin orient-spindle line
- wait for a spindle-oriented HAL pin line to become true

that is how my ladder and hal is set out right now for doing my spindle for the changer but with a fixed postion hard coded right now..
will you give a ini file value for default oriention position? so if no R value is given at a M19 the value for default in the ini file is used (if no value is found 0 is used) as my encoder postion is 21degrees from 0 to postion my spindle for change postion.
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers

Robert Harpham

2011-03-17 22:52:22 UTC

Permalink

Post by Michael Haberler
- M19 will convey orientation and direction to motion.
- motion will get a spindle-orientation and spindle-direction pin fed
with these two parameters.
- motion gets a disable-spindle-movement input which blocks M3/M4;
this pin is positive-edge triggered
in case a) this would be fed the lock-engaged switch
in case b) this could be the brake-engaged switch; external HAL
components could handle orientation/direction/PID loop and eventually
set disable-spindle-movement
- spindle-state 'locked' is true iff disable-spindle-movement is true
- M19 will wait until disable-spindle-movement is true
- motion gets an release-spindle-lock pin (positive-edge triggered)
which would, in M20 M3,M4,M5
- activate the unlock mechanism in scenario a),
- release the brake in scenario b)
- M20,M3,M4,M5 would wait for disable-spindle-movement to become false.
unclear to me: what's the difference between an M20 and an M5? both
leave the spindle unlocked and stopped. Do we need an M20 at all?
I would have liked to make M19/M20 remapped tp oword procedures as
well but due to the spindle state interaction I dont see any other
route than new NML messages + extending motion
-mah

you are quite right M20 is abit of a odd unused code, as M03 M04 M05 all
do it also.

should end of program cancel an M19 also? ie M30 etc so the spindle is
not sat for ever in servo mode if done electronicly if u program an M19
and never reuse the spindle untill a program rerun? as damage may happen
to motor or drive Mill or Lathe

also one question, will you make motion or IO control do a M19 true when
it enters into tool change request = true? and M19 false at the end of
tool changed=true ? as i if you have the following program

exsample
G91 G29 Z0 M19 < Orient spindle while moving Z to change potion
T01 M06 < change the tool
M30 < end program
there is no request for a cancel on orient = true

which would also cancel a oriention early in
G91 G29 Z0 M19 < Orient spindle while moving Z to change potion
T01 M06 < change the tool
S6000 M03 < start the spindle

Only issue i would see, above works for a Mill with or with out a changer
but a lathe is something else as you dont realy want to start postion
the spindle some where on a tool change.. unless you have a very fancy
multi axes lathe..
maybe check ini file for
TOOL_CHANGE_WITH_SPINDLE_ON = 1
if 1, dont request spindle oritent for a tool change request.

Chris Radek

2011-03-18 02:35:34 UTC

Permalink

Post by Michael Haberler
it seems some machines have a lock pin which disables spindle movement when inserted and needs to be explictely removed; others might have a brake which may engage in any rotational position
a) essentially 'probe' the lock-engaged pin by slowly rotating the spindle, stopping when lock-pin switch opens
b) take orientation and direction from M19, hand over to PID controller until angular postion == orientation, engage brake, release PID control
M20 would in scenario
a) activate unlock mechanism (magnet, whatever) and make sure lock-pin switch is closed
b) release brake

There should be HAL pins that tell HAL which mode the interpreter
requests, and a loopback saying when it's done, and that's all.
Things like lock pins, polling a pin, pid controllers, making sure a
switch is closed, waiting for the spindle to stop, etc etc are
machine-specific and very definitely taken care of by HAL setup and/or
ladder as the integrator sees fit.

In the spirit of iocontrolv2 there may also be a pin signaling an
error (failed request).

I just want to make sure I understand what you're proposing, because
pretty much none of these things you mention above are the job of the
interpreter or any code you will write to add this feature.

NGC says the NML interface should be ORIENT_SPINDLE(double degrees,
DIRECTION direction) and doesn't mention unorient. For unorient you
could make a new call or could possibly use STOP_SPINDLE_TURNING()
which reflects what someone has already pointed out: M20 and M5 seem
to do the same things.

The HAL interface should be pins showing degrees and direction (+-1
like is used elsewhere) and a loopback like the rest:
motion.spindle-orient -> motion.spindle-oriented

Kim Kirwan

2011-03-17 21:24:24 UTC

Permalink

Hi Michael,

Post by Michael Haberler
M19 [R<orientation in degrees; defaults to 0>] [L<orientation cw/ccw>]
- turn off the spindle

Here I would insert an additional step...

- wait for spindle-at-zero

...because if we change the spindle drive from spindle mode
to servo mode while the spindle is at full RPM, we're probably
going to break or burn out something.

Most good spindle drives that are suitable for orientation have
multiple sets of parameters available. Two is sort of the minimum,
many have four sets or more. This is what allows you to put a +10V
step function on a spindle drive and get a nice steady ramp up (or
down) over several seconds. But we can't run that way in servo mode,
it has to be instantaneous. Hence the need for two or more drive
parameters.

Since a spindle encoder is used for orientation, the spindle-at-zero
detector (via encoder) should be able to be fairly high quality.

Post by Michael Haberler
- set a HAL pin spindle-orientation line to convey the degrees value

I'll leave this step here even though we're early (not in servo yet).
Yes, this might be handy, even machines without a tool changer might
benefit from this for such things as oriented-boring-bar-withdrawal.
But there's a problem with bar-orientation, more on this later.

Post by Michael Haberler
- set a HAL pin spindle-direction line to convey the cw/ccw direction

Yes, this might be good, because it would make sure that in-the-hole
boring bars, etc. would always be rotated the "correct" direction
for the tooltip. But won't that play hell with with our PID servoing
action?

I'll have to leave this to others who know more about whether
EMC2/HALs PID loop can be "guided"(?) in such a way. But I have to
wonder if this isn't going to cause more bother than it's worth?

If we don't try to set the bar rotation direction, and the bar
is always withdrawn (we don't offer bar-orientation), then we can
just turn the servo on and let it "flop" to the right position.

Comments and advice on this invited.

Post by Michael Haberler
- assert a HAL pin orient-spindle line

Now we're ready to turn the spindle back on (in servo mode).

- turn spindle back on (now in servo mode)
- EMC2/HAL begins closing the PID loop on the spindle
(spindle begins servoing to oriented position)

Watch the spindle encoder, and wait for orientation.

Post by Michael Haberler
- wait for a spindle-oriented HAL pin line to become true

Now we're oriented, and we're telling a tool changer that it's
time to start the tool change, but there's a problem.

A tool changer start is an external event, and at some point,
hopefully, we'll get tool change done back as a result. So
there's an external event (long after orientation) that says
"quit M19 and continue with the next g-code step".

With boring-bar-orientation, when the spindle is oriented,
we're done, we want to exit M19 and go on with the next g-code
steps right away to remove the boring bar.

So maybe we need another M19 argument, maybe Q0 (default),
"Stay in M19 forever until some external event occurs" vs.
Q1 "When M19 fully reached, we're done, drop it and move on."

I should add by way of explanation that that M19 doesn't
have to stay on during boring bar withdrawal, since if the
spindle "relaxes" a few degrees at the end of M19, that's
usually good enough to remove a boring bar from a hole. But
M19 usually stays on during a tool change since if the spindle
would relax even a fraction of a degree, that could be enough
to foul a tool change arm.

We stay in servo mode for position holding as long as we
still need the M19 command on. When we're done with M19
(for either reason), we have some cleanup to do before we
can exit:

- turn spindle back off (still in servo mode)
- EMC2/HAL can stop closing the spindle servo loop

Cancel the spindle servo mode (drive parameters to "normal").

- clear the HAL pin orient-spindle line

Now we're out of servo mode with the spindle off.

We don't care about the spindle-oriented HAL pin line now.

I think at this point we're OK to exit the M19 cleanup,
and the M19 command, unless I've forgotten something.

Comments, suggestions and advice invited and appreciated.

Hope this helps.

Kim