ATC Project - Debug phase

I think I'm getting close.

The new carousel.comp (2022-03-16) has the new pins and seems like I've got the steps, counts & width set close enough for testing.  Speeding up and down makes no change to the stopping point - WOO!  Position control is working.

Downside... it's back to continuous rotation.

Keeps rotating after the first enable (homed goes high). Doesn't stop unless I disable the stepgen or carousel.0.enable.
Keeps rotating while I watch carousel.0.current-position count up and down and doesn't stop when it gets to the correct carousel.0.pocket-number.

jog fwd & jog rev work fine (like before) - moves one pocket per enable.

Andy - is there any way you could check and see if the continuous rotation fix you made on May 17th

forum.linuxcnc.org/38-general-linuxcnc-q...iv-a-new-hope#243170

could be merged with the "counts" version of carousel?  Or if you think it wouldn't make a difference have you got another idea?

So close...

I am a bit confused. The linked version of carousel.comp in your latest post (the one above) doesn't provide any extra pins as far as I can see.
Adding a latching velocity and mode shouldn't be difficult and has made it to my to do list. However, I need to prepare the right hardware beforehand.

Doing everything in PT with an axis doesn't seem to be so bad. Set up an axis of your choice (W comes to mind). Add that axis to initial homing, use home_offset to get to the desired zero position. This allows you to know the initial pocket.
You can access the current_pocket and selected_pocket information in macros: see linuxcnc.org/docs/html/gcode/overview.ht...ub:system-parameters

Determine all the pocket positions (in degree) once, store them in the macros and then it is just a matter of sending the axis to the right absolute position using G1 A <value>. Note that this will likely move the axis back and forth to stay within 360° and not take the shortest way.
If that is desired, you would need to move in relative coordinates and determine the angle and direction of movement. Using some simple conditions in code within the macro, this isn't too difficult.
That is the main building block for working out the m6 macro with positional control, No need for additional trajectory planning. However, it does not use any indexing whatsoever besides initial homing.

The remaining bits aren't too difficult. You'll have to do those by yourself.

Furthermore, I would image that the homing routines effectively operate on velocity as well. Provided the speed is not crazy, the motor is tuned properly and the step timings are not stupid high, hitting an index marker should be too difficult - even without mechanical locking in place.

GuiHue wrote:

I am a bit confused. The linked version of carousel.comp in your latest post (the one above) doesn't provide any extra pins as far as I can see.

 

Andy has posted two new versions of carousel.comp lately.

First one was posted in another thread (carousel.comp_2022-03-16) and contains additional pins which connect the stepgen counts output to a new carousel.N.count input.  Step scaling is handled with a couple other new pins, and the whole scheme works as a positioning-mode system instead of a velocity-mode system (which relies on mechanics to index perfectly).  The only sensor required is an index pin - pocket pins/flags are not needed.

The second one he posted (in this thread) corrected a bug found when carousel.comp was set to index mode.  This bug caused the carousel to rotate continuously under certain circumstances even if it was reporting the correct pocket had been reached.

The 2022-03-16 variation still has the continuous-rotation bug.

What I was asking in my last post was to see if Andy could merge the two and post a bug-free version with the new 'counts' feature.

The benefit to using a position-mode carousel.comp instance is that you don't have to do the math in an .ngc file.  All rotation is handed off to carousel.comp, making a remapped M6 file simpler.

Further, manual control of the carousel is also easier - there's no need for a separate remapped M-code to jog the carousel, nor is there a need for a separate homing M-code (or axis homing) or 'is-homed' safety check.  Carousel homes on the first enable automatically - whether that's at the first tool change, machine start-up, or first manual jog.

We still have to do the tool-to-pocket logic and carousel/arm movements, but this unloads quite a lot of activity in to the background.

ITS ALIVE! (ish)

I got impatient and had a go at merging Andy's two updated carousel.comp files: the bug-free one (no counts feature) and the buggy one (with counts feature). 

NOTE - the bug was that in index (and count) mode, the initial homing sequence would set the right pocket number (#1) but just keep rotating forever.

Now that I can use halcompile like a grownup the editing and installation worked.  All I did was edit the "Case 2" section to eliminate the extra motor_rev statement.

It now works as advertised, with the very useful bonus features Andy cooked up:

1. Carousel now works in positioning mode (mode = counts).
2. Requires a single indexing pin/sensor only - no pocket pins, no encoder.
3. Is bi-directional without any g-code math.
4. Jogging fwd/rev is still available and will move one pocket (and keep track of what the actual pocket number is.
5. With a closed-loop stepper or servo carousel will always hit exactly the right pocket position or alarm out (assuming the drive's internal following error isn't really sloppy)
6. Probably doesn't need the s32comp to motion.0.analog-out-xx thing for g-code pass-through (at least during my testing), as iocontrol.0.tool-number, .tool-prep-number, and .tool-prep-pocket are all s32 outputs.  Connecting any of these to carousel.0.pocket-number means a simple Tx M6 in MDI will set the desired pocket.  YMMV.

Some notes if anyone wants to poke around with the new features:

• carousel.0.scale: wasn't too bad to figure out, and having a closed-loop stepper drive with programmable steps/rev made it graceful.  In my case:
  • 5:1 reducer
  • 18 pockets
  • NEMA 34 900 oz-in stepper (native 200/rev, 1000-line/4000-quad encoder)
  • Motor steps/rev set to 3600 in drive (18 microsteps)
  • Worked out to carousel.0.scale = 1000
• carousel.0.width: not really sure what this is for.  I left it at =12 (default in .comp), but found the position was creeping after multiple platter turns.  I set it to =0 and now it's dead-on after multiple rotations.
• My guess is that the 'scale' is intended to be the width of the actual pocket, and 'width' is the distance between the pockets.  I guess I cheated by setting 'scale' to the center-to-center distance of each pocket and simply not using the 'width' setting.
  • Maybe Andy can explain the thought behind having two scaling parameters.
• Would not recommend using an open-loop stepper, or a closed loop stepper unless the drive's internal following error alarm can be set very low.  Missed steps will cause a crash.
  • I mention this because quite a few of the el-cheapo closed-loop steppers available have factory default following error settings that are HUGE - like 1/4 motor rotation. If you can't adjust this down to a very tight number, pick a different drive because you need the drive alarm to work properly.
• Speaking of which...don't forget to connect the drive's alarm output to some sort of LCNC alarm input.  Carousel doesn't use joint/axis, so the standard joint.N.amp-fault-in pin isn't available.
  • How about a new carousel.0.amp-fault-in pin? (pretty-please!)
• I think this is a case where a stepper may be preferred over a servo.  The huge slow-speed torque of a stepper, coupled with an appropriate gear reduction, is an advantage over a (similar-sized) servo.  No servo tuning, no dithering, no PID loops, possibly cheaper. 
  • Of course, there's something to be said for having all your drives & motors be the same. Who wants an odd-ball stepper drive (plus power supply) in an all-servo machine?
• Pocket alignment might be tricky to set up.
  • The index pin needs to trigger at the right location to align pocket #1 with the spindle.
  • An adjustable sensor mount is likely required because the initial (home) location will be dependent on the motor velocity and decel.
  • Carousel doesn't home like an axis (move to trigger, back off at low speed). Fiddling with the rotational speed will result in misalignment, so settling on a rotational speed with a loaded carousel then tweaking the sensor so it nails it every time is the ticket.
  • I'm going to abandon my horizontal sensor (proxy) and vertical pin (round) arrangement, and switch to a vertical-down sensor and a horizontal (sheet-metal) flag that passes under it. The sensor mount will be adjustable sideways to permit earlier/later triggering.  Once the speed is locked down it should be pretty accurate.

Still need to get an M6 remap set up, as well as the extend/retract functions tied in.  But I think the major hurdle(s) are behind me.

Famous last words, of course.

PS - New and improved, bug-free carousel.comp attached for anyone who wants to try it out.

Carousel is working - no bug, new counts feature present.
Remap is working - no qtpyvcp notifications.py errors.
Orient is working, but I can't get it to settle in a reasonable time.  Tuning on my end, of course.
Toolchange.ngc is suitable modified for testing (no carousel in/out movement).

Once I get the sequence down, it'll be time to try to integrate it with Probe Basic gui buttons.

"ATC Fiasco, Parts 1 - 15, Volume 2, 3rd Edition, revised."
or
"Dear ATC Diary, I hate Linux, but I love LinuxCNC."

Ever time I clear a hurdle, or hit a wall... my obnoxious inner child can't help writing something snarky in the title.

It's so long now that changing it to [Solved] when or if it's ever sorted out means someone would have to wade through all the whining I've done over the past months.  I'm hoping to start a new thread in HAL or somewhere with a working config & explanation - I'll link this thread to it when it's done.

I'll stop fiddling if you want, but the title mischief is what keeps me from throwing in the towel on LCNC

Current update is working on the spindle orient.  It's just not reliable enough for me to continue integrating the ATC sequence yet.