Carousel.comp - counts mode bugs/error?

I'm back with more testing of ATC and carousel...

Had a couple successful-ish tool changes, but noticed the pockets weren't quite lining up a few times.  After investigating mechanical reasons, I think I've discovered a bug (or some setting I've got wrong) in carousel.comp - at least in counts mode.

Issue: Direction changes get more counts than desired

Settings:
Counts mode, index pin only (no pocket sensors)


What I noticed was that after homing to the index pin, carousel would move the ATC the correct number of counts until a direction change.  At each direction change it would add counts and the pockets would not line up.  This counts error is repeatable for every pocket, regardless of how many rotations or DIR changes I make.

My earlier DIR pin issue is resolved, so that isn't the issue.  All data on the chart below is taken from stepgen.N.counts so the ATC is being commanded to do this (not lost steps)

Actual counts vs pockets:
Thoughts?

-R

Hate this forum editor.

Lets try this:
 

More testing.

Reinstalled the individual pocket pins & sensor.  Uncommented align_dc and decel_time.

I can home it, see the slow-latch, and it settles at State 0 at pocket 1.

Jog one pocket (either direction), and it moves the correct counts but gets stuck at State 20.  Unresponsive after that, have to restart LCNC to initialize and continue testing.  Can't determine if the counts are correct at direction changes.

Setting align_dc to 0, leaving decel_time at 5, behavior reverted to the previously observed.  Can home, command pocket moves, and jog without locking up at State 20... but at each direction change the counts moved are too high.  Each subsequent jog after that (in the same direction) is correct, but any direction change is wrong.

Help?

Can you give us more information about your ATC system? Attach the configuration files and describe (ideally also a photo) what kind of encoder, motor, etc. you have.

Also let me know what LCNC version you are using.

Thanks for responding - Andy's commented on the github page issue I raised and has indicated he thinks it may be a code issue and not just me being silly (for once).  It works fine when commanding a move to a specific pocket, but the 'jog' function isn't working.

Running MX21, LCNC 2.10 and Probe Basic.

Regarding the ATC system... it's not 'interesting'.  Looks, more or less, like every "toolchanger for router" on Aliexpress.

Nema 34 stepper motor
5:1 planetary reducer
Carousel platter is bolted to the reducer output
Plastic pocket forks
2/ea PNP sensors (one for index, one for per-pocket)
Sensor flags at each pocket (one extra-long for index)

As far as the encoder... there is no 'encoder'.  I'm using carousel.comp set to counts mode.  carousel.0.sens-0 is connected to the index proxy, and carousel.0.sens-1 is connected to the per-pocket proxy.

I'll post up a photo or two tonight.

Tommy-

Not tried Axis, but I've pretty much deciphered the 'stock' Probe Basic toolchange choreography.  And all my testing wasn't using the PB screen buttons or even M-codes; it was all done through halshow direct to the pins.  Might as well have done halcmd in terminal as I was bypassing everything that could have buggered the testing.

PB doesn't use carousel.comp to control the ATC; it uses motion.digital-out-NN signals to, essentially, turn a motor on/off or fwd/rev.

In stock PB form, there's no per-pocket feedback from the ATC.  This is why the stock PB sequence required a geneva wheel mechanism to mechanically ensure the right pocket is lined up.  All the math to go from pocket N to pocket Z is handled by three ngc files (M-codes).  And every time the ATC moves there are additional functions in the various toolchange M-code files which update the LCNC parameter file with:

• current-pocket
• destination-pocket
• tool number X in pocket Y (for all of the pockets)
• tool number in spindle
• ATC homed or not
• other stuff

Because I'm using a stepper motor and no geneva wheel, I had two choices: treat the ATC as an axis, or use carousel.comp.  Andy talked me out of doing the ATC-as-axis plan when he added the 'counts' mode to carousel.comp.

Which means I had to disassemble all the 'stock' PB ngc files and rebuild them to let carousel.comp do all the heavy lifting when it came to moving the ATC.  So instead of motion.digital-out-XX turning a motor on/off, it now sends carousel.0.enable a 'go' signal.

I kept the parameter-writing/reading functions as that's the only way to keep track when using a tool table with more tools than pockets.

Once I got the various settings dialed in, carousel has been working pretty well.  Carousel works - basically - like a velocity-mode motor and a stopwatch.  Carousel figures out "if the motor is spinning X fast, and I need to go Y distance per pocket, and I have to go Z pockets, then I'll turn the motor on for A milliseconds."  Works like a champ, even at really, really fast rotational speeds.

The problem is that the jog function isn't doing something quite right.  Despite carousel working fine when a specific pocket is commanded, using the jog function fails when the jog direction is changed from the previous command.

Andy's looking in to it...

-R

This is the Issue:
https:/github.com/LinuxCNC/linuxcnc/issues/2300

I did not know, that Andy is helping you now. He will help you better than me.

Andy - any time to think about this?

I'm near the finish line on my rebuild and during 'live' ATC testing with tools I noticed that the carousel pockets were misaligned a bit.  The further the travel, the more it was misaligned.  My earlier testing (charts I posted) was only a few pockets fwd/rev so I guess I didn't catch an issue at max travel distance (9 pockets).

Still having issues with jogging... gets stuck at state 20.