Carousel Toolchanger
- tommylight
- Away
- Moderator
Less
More
- Posts: 19188
- Thank you received: 6430
25 Jul 2024 16:48 #306026
by tommylight
Replied by tommylight on topic Carousel Toolchanger
This one ?.. there's an excellent vid on YT from Erik Salo (sp?) about configuring a tool changer. His explanation and demonstration of the digital in/out hal pins is excellent.
The following user(s) said Thank You: spumco
Please Log in or Create an account to join the conversation.
25 Jul 2024 22:32 #306037
by spumco
Replied by spumco on topic Carousel Toolchanger
Thanks Tommy. That was the one I watched about 3 times before the motion.digital-in stuff started sinking in.
Please Log in or Create an account to join the conversation.
25 Jul 2024 22:45 #306038
by Hawk83
Replied by Hawk83 on topic Carousel Toolchanger
Believe me… I have read through countless hal-, ini- and remap-configurations, but since LinuxCNC is a relatively complicated piece of software, it’s hard to find all the needed information and sometimes I almost don’t even know what to look for.
I have watched Erik Salos’ video several times, and it is by far one of the best sources I have found on this topic. And even though he is using the carousel.comp (which I also would have used if my tool-carousel wasn’t controlled by a +-10V signal) I have gathered a lot of useful info from that video.
But back to the topic…
I have the M6 and Tx remap working to the point that when I run an M6 Tx command from MDI, LinuxCNC executes the necessary prolog and epilog functions and executes the change.ngc file.
I have put some print-commands in the change.ngc file to verify that it is beeing called and executed and I have also successfully returned different parameters to verify that everything is working as intended.
But I can’t get it to execute G-codes from within the change.ngc-file. I have tried running G0-commands (e.g. G0 C180 and G53 G0 C180) but it’s just skipping the lines containing the G-code and the axis doesn’t move. When I run the axes in MDI they work just fine.
Any tips regarding this?
I have watched Erik Salos’ video several times, and it is by far one of the best sources I have found on this topic. And even though he is using the carousel.comp (which I also would have used if my tool-carousel wasn’t controlled by a +-10V signal) I have gathered a lot of useful info from that video.
But back to the topic…
I have the M6 and Tx remap working to the point that when I run an M6 Tx command from MDI, LinuxCNC executes the necessary prolog and epilog functions and executes the change.ngc file.
I have put some print-commands in the change.ngc file to verify that it is beeing called and executed and I have also successfully returned different parameters to verify that everything is working as intended.
But I can’t get it to execute G-codes from within the change.ngc-file. I have tried running G0-commands (e.g. G0 C180 and G53 G0 C180) but it’s just skipping the lines containing the G-code and the axis doesn’t move. When I run the axes in MDI they work just fine.
Any tips regarding this?
Please Log in or Create an account to join the conversation.
25 Jul 2024 23:02 #306040
by spumco
Replied by spumco on topic Carousel Toolchanger
I'm using a stepper in position command for my ATC, where carousel.countes-target drives the stepgen.nn.position-command. That's the basic connection between carousel and a position-mode motor.
Unfortunately, I'm not expert in LCNC enough to know if there's a similar way to connect carousel.comp to an analog torque or velocity-mode servo. I can see why you're inclined to stick with the ATC-axis scheme.
Can you post your config files, including the toolchange ngc files?
Also - what servo motor and drive is being used? Just asking, as maybe there's an alternative command signal available that doesn't require a massive wiring change.
Unfortunately, I'm not expert in LCNC enough to know if there's a similar way to connect carousel.comp to an analog torque or velocity-mode servo. I can see why you're inclined to stick with the ATC-axis scheme.
Can you post your config files, including the toolchange ngc files?
Also - what servo motor and drive is being used? Just asking, as maybe there's an alternative command signal available that doesn't require a massive wiring change.
Please Log in or Create an account to join the conversation.
02 Oct 2024 03:28 - 02 Oct 2024 03:30 #311142
by Becksvill
Replied by Becksvill on topic Carousel Toolchanger
hey spumco
could you share your cofig maybe?
i have a carousel setup with a step dir servo motor.
do you just have the one sensor for index or home and then or did you have to add other sensors also?
i think i have a setup just like your one buy my one is not working
i keep getting this error "the toolchanger has failed the final alignment check"
and then it tries again
etc
i emailed andy in the email list also but any help appreciated
cheers
Andrew
could you share your cofig maybe?
i have a carousel setup with a step dir servo motor.
do you just have the one sensor for index or home and then or did you have to add other sensors also?
i think i have a setup just like your one buy my one is not working
i keep getting this error "the toolchanger has failed the final alignment check"
and then it tries again
etc
i emailed andy in the email list also but any help appreciated
cheers
Andrew
Last edit: 02 Oct 2024 03:30 by Becksvill.
Please Log in or Create an account to join the conversation.
02 Oct 2024 05:05 #311151
by spumco
Replied by spumco on topic Carousel Toolchanger
Config attached - be warned, it's pretty complicated. Feel free to ask if anything isn't clear.
There are a couple things still in there that aren't done (GUI related), but the tool changer is done and tested.
ATC hardware:
Best thing I did was use halshow for testing. I put all the appropriate pins in one watchlist and then disconnected carousel.n.enable and n.pocket-number from the 'real' connections, and did all testing by enabling/disabling in the halshow window. Same-same for carousel homing/unhoming, as well as adjusting the speed & accel (including final align-dc).
In addition, I modified the PB subroutines to add a number of manual ATC function overrides for testing/troubleshooting. Trying to remember which motion.something.digital-out-??? to trigger via MDI M64 P? or M65 P? is horrible when you have about 20 things all competing for brain-bandwidth.
When you look at the subroutines you'll ask yourself "why did he make a separate Mcode just to retract the ATC, or just to activate the drawbar?" The reason is that it's easier to test - and recover from a problem - using GUI (or physical) buttons than it is to type in MDI stuff.
Note that some of the subroutines are not used; those are the 'OEM' files from the Probe Basic installation. Others are used, but have been modified based on my particular config. The primary files are 'toolchange.ngc' and all the Mxx.ngc files. Mnn.ngc file numbering is mostly legacy stuff from the PB installation.
Still to do is a laser sensor to check that the tool is seated properly in the spindle taper. User GuiHue has a very nice config and hardware setup that uses a laser sensor to check the top of the drawbar, and he inspired me to buy a sensor a while ago.
Depending on the spindle & pull-stud length, BT30 tool holders can be mis-grabbed by the drawbar claw (with the drive dogs not seated) and the tool will not be seated in the taper. This is dangerous, obviously, but I currently don't have a way to check for this - I'm just checking that the PDB cylinder is fully retracted. My tool forks have metal anti-rotation tabs that engage in the toolholder notches... but I'd still feel better knowing the tool is properly seated.
Now that the ATC appears to be working reliably, I'll be installing the laser sensor soon to see if the drawbar top is at the correct elevation for a seated toolholder - and alarm out if it isnt.
PS - once it's working well in testing, load the whole carousel up with heavy tools and do some more testing. I had to reduce my speed & accel/decel a fair amount due to inertia - tripped the stepper a couple times as I had carousel moving too aggressive.
There are a couple things still in there that aren't done (GUI related), but the tool changer is done and tested.
ATC hardware:
- Closed-loop stepper driving platter through a 5:1 reducer
- 18 pockets
- Sensors
- Carousel
- Once-per-pocket
- Once-per-rotation (home)
- Flags are 3D printed and attached to the forks (one fork is a 'double' that triggers the home sensor
- Sensors are optical slot-type
- Previous version had round stainless pins sweeping past inductive proxy's - that didn't work so well as a slight change in radial distance to the pin resulted in significant difference in rotational alignment
- Slide
- One proxy carriage FWD, one for retract
- One for a pneumatic cover door
- Carousel
- carousel.comp (make sure you get the latest version, there were a few edits recently)
- INDEX mode
- Toolchange sequence handled via remap and heavily modified Probe Basic subroutines
- using carousel.n.align-dc - if this is set to something other than zero, carousel will do a fine alignment dance after the pocket sensor is triggered. Andy did a nice job with this as carousel will approach the sensor trigger edge from the same direction regardless of the initial movement direction.
- CW to sensor -> decel/stop slightly past -> back up CCW past trigger point -> move CW slow to trigger leading edge
- CCW to sensor -> decel/stop slightly past -> move CW slow to trigger trailing edge (same edge as with CW move)
- carousel.n.debounce made a huge difference in reliability - this was a recent addition to the comp
Best thing I did was use halshow for testing. I put all the appropriate pins in one watchlist and then disconnected carousel.n.enable and n.pocket-number from the 'real' connections, and did all testing by enabling/disabling in the halshow window. Same-same for carousel homing/unhoming, as well as adjusting the speed & accel (including final align-dc).
In addition, I modified the PB subroutines to add a number of manual ATC function overrides for testing/troubleshooting. Trying to remember which motion.something.digital-out-??? to trigger via MDI M64 P? or M65 P? is horrible when you have about 20 things all competing for brain-bandwidth.
When you look at the subroutines you'll ask yourself "why did he make a separate Mcode just to retract the ATC, or just to activate the drawbar?" The reason is that it's easier to test - and recover from a problem - using GUI (or physical) buttons than it is to type in MDI stuff.
Note that some of the subroutines are not used; those are the 'OEM' files from the Probe Basic installation. Others are used, but have been modified based on my particular config. The primary files are 'toolchange.ngc' and all the Mxx.ngc files. Mnn.ngc file numbering is mostly legacy stuff from the PB installation.
Still to do is a laser sensor to check that the tool is seated properly in the spindle taper. User GuiHue has a very nice config and hardware setup that uses a laser sensor to check the top of the drawbar, and he inspired me to buy a sensor a while ago.
Depending on the spindle & pull-stud length, BT30 tool holders can be mis-grabbed by the drawbar claw (with the drive dogs not seated) and the tool will not be seated in the taper. This is dangerous, obviously, but I currently don't have a way to check for this - I'm just checking that the PDB cylinder is fully retracted. My tool forks have metal anti-rotation tabs that engage in the toolholder notches... but I'd still feel better knowing the tool is properly seated.
Now that the ATC appears to be working reliably, I'll be installing the laser sensor soon to see if the drawbar top is at the correct elevation for a seated toolholder - and alarm out if it isnt.
PS - once it's working well in testing, load the whole carousel up with heavy tools and do some more testing. I had to reduce my speed & accel/decel a fair amount due to inertia - tripped the stepper a couple times as I had carousel moving too aggressive.
The following user(s) said Thank You: Mr. Mass
Please Log in or Create an account to join the conversation.
Time to create page: 0.091 seconds