carousel - persisting the last state & homing - what is best practice?

Start
Prev
1
Next
End

dirkx
Offline
New Member

18 Oct 2026 12:13 - 18 Oct 2026 12:15 #350322 by dirkx

carousel - persisting the last state & homing - what is best practice? was created by dirkx

I've got a Deckel/Maho DMC70V here with a 30 slot carousel for its tools; its Dialog112/MELDAS600 brain has been replaced by Ethercat & LinuxCNC.

I've automated part of this with the carousel(9) real time component; and this works well overall & is quite reliable Actual config at the end of the message. Now I am struggling with two things:

How does one trigger this cleanly when normal homing completes (the spindle needs to be in the home position for the carousel/arm to safely home) -- and then ideally so that if the carousel homing does not come complete/come-on - the machine is not declared fully homed; just like it would for an axis ?

On startup - if the tool changer is in a low slot - it will insist on doing a full rotation with increasing numbers; thus making a full circle; even though it could just go back one. What is the right way to persist the last position on closing linuxcnc(1) ? So that it can use this to home a lot more efficiently ?

Thanks !

Dw.

# Deckel-Maho DMC70V toolchanger carousel, 30 slots, can be rotated in both
# directions; with a brake sensor on the motor that controls the wheel and
# a pocket sensor that confirms it stopped at the right spot. General control
# is to power on the motor in either direction until you see the brake sensor
# coming up; then stop the motor and check that the pocket sensor confirms
# a stop in the right place. If not -that is usually caused by a tool or arm
# with something still in it & needs manual intervention.
#
# S202 is the slot signal & S201 is the brake now; stop motor power on rise and
# then wait for S201 to go high.
#
net carousel-index-sensor S200-input => carousel.0.sense-0 atc.led-carousel-index
net carousel-pocket-sensor S201-input => carousel.0.sense-1 atc.led-carousel-brake

net carousel-enable atc.button-carousel => carousel.0.enable <=> Magazine-output
net carousel-active atc.led-carousel <= carousel.0.active

# S202 will rise a bit later - to confirm correct position
# and needs to be combined with the counter ready
#
net confirm-tool-in-pos S202-input => iocontrol.0.tool-changed atc.led-carousel-pocket
net carousel-pocket-num iocontrol.0.tool-prep-number => carousel.0.pocket-number

# Link motor direction outputs to your stepgen or VFD/relay drives
net carousel-motor-fwd carousel.0.motor-fwd => Forward-output
net carousel-motor-rev carousel.0.motor-rev => Backwards-output
net carousel-current-pos carousel.0.current-position

# Allow the jog buttons to work; propably need to be
# tied to the interlock of MCall that then lights up
# the light output
#
net carousel-motor-jog-fwd S274-input => carousel.0.jog-fwd
net carousel-motor-jog-rev S216-input => carousel.0.jog-rev

net carousel-homed carousel.0.homed => atc.led-carousel-homed
net carousel-current-pos => atc.number-position

Last edit: 18 Oct 2026 12:15 by dirkx.

Please Log in or Create an account to join the conversation.

andypugh
Offline
Moderator

13 Nov 2026 15:38 #350683 by andypugh

Replied by andypugh on topic carousel - persisting the last state & homing - what is best practice?

If the carousel really _has_ to home then it can't know which way it needs to turn. But I am surprised that a Deckel/Maho carousel doesn't have some sort of absolute position encoding?

To delay the carosel homing until after the other axes have homed, you could interlock in HAL with the homed states of the other axes.
Or, maybe just defer homing until the first programmed toolchange, which ought to be in a safe toolchange position?

Please Log in or Create an account to join the conversation.

Start
Prev
1
Next
End

Time to create page: 0.388 seconds