ATC Project - Debug phase

I'll try to get something video'd tonight.  I don't have a YT account, but I might be able to persuade the spouse to let me upload something to her account.

I was just re-reading Andy's carousel.comp (the latest on github) and noticed that there are three speed setting pins
fwd-dc
rev-dc
motor-vel

I have fwd-dc = 25, rev-dc = -25, but nothing set for motor-vel.  I think I'm going to fiddle with that tonight and see if setting motor-vel to some value changes anything.  Now that I read it (again), it's a little unclear which one to use to set the speed:

fwd-dc         "Velocity or duty cycle when forwards rotation is desired"
rev-dc          " Velocity or duty cycle when reverse rotation is desired"
motor_vel    "The duty-cycle or velocity to drive a DC motor or stepgen"

Ok, so motor-vel is an output.  No low-hanging fruit there.

Noticed that carousel had 18 sense pins in halshow.  Checked the hal file and sure enough, I had

loadrt carousel ... num_sense=18

Figured it couldn't hurt to fiddle around and dropped that down to 1; I've only got 1 pocket/index pin, right?

Then I start getting this:
 

and LCNC starts locking up and getting really laggy.  Have to shut it down, can't really do anything (jogging, mode selection, MDI).

Edited hal again to num_sense=18, and the error goes away.

Tried with num-sense=0, error gone.  What the heck?

Also... narrowed the continuous rotation error down to the following speeds:

fwd-dc=28, it acts as intended (one pocket)
fwd-dc=29, it rotates at least one extra turn
rev-dc=-31, ok
rev-dc=-32, extra rotations

Odd.

 

Just a stab in the dark, but maybe those are somehow/somewhere/no idea/ tied to some divisions from one pocket to another, so when the requested value can not be divided it does extra rounds till it gets to what can be divided.

tommylight wrote:

Just a stab in the dark, but maybe those are somehow/somewhere/no idea/ tied to some divisions from one pocket to another, so when the requested value can not be divided it does extra rounds till it gets to what can be divided.
 

Good idea.

I changed the stepper drive steps/rev and recalculated the carousel.0.scale... still acts the same.  I've got the drive steps/rev set so that carousel has an even number of steps per pocket.  Used to be 1000 counts per pocket, now it's 1250.  No difference.

I did notice that at the slightly higher counts/pocket setting it didn't act up every time when the speed was set to 35.  Once I set it to 50, it failed reliably.

Made a horrible little video demonstrating the issue.

Horrible video - carousel.comp "counts" error

Maybe that can shed some light on what's going on.

num_sense should be 2 for this changer, you have two sensors...

It is possible that the round pins going past the sensors give quite a short pulse.

I see that the index-enable is continuously true. But looking at the code this isn't the problem if you are using stepper counts.

What is the "width" set to? That is the number of counts either side of the centre of a pocket that still counts as a pocket. If it is too small the carousel will never be detected as being in a pocket, because the counts is only checked every 1mS.

I have forgotten why we are using counts rather than the sense pins that you have. I added the counts mode for changers that didn't have direct feedback.

Now that I have seen the machine I think that the idea I proposed before of adding a slower latch move might work best.

I have two sensors installed, but the pocket sensor is not connected in hal any more - only the index.

If you recall, the reason I/we stopped using the pocket sensors is that the actual stopping point is dependent on the motor speed & decel; there's no mechanical device to align a pocket with the spindle and any speed/decel variation (tool weight, inertia) can result in misalignment.

I can install different flags - sheet metal would give a more repeatable (or defined) edge and a longer pulse width.  But even at higher speeds I've  never seen it miss a trigger with the existing pins; they're very close to the proxys.

'Width' is set to 0 - this sounds like it may be the problem.  Here's the comp file description (which you wrote, of course):

pin in signed width = 0 "How far each side of the exact scale to signal a new pocket";

So I left it at the default.

Should the width value be in stepper pulses?  Is this a tolerance setting, so that if I set:

scale = 1250
width = 10

that would be the same as next pocket = 1250 +/- 10 pulses?  Is this going to develop a cumulative error over multiple pockets?

Regarding the slower latch move, I think a homing search with slow back-off (a-la axis homing) would be very useful - the homing sequence is currently dependent on motor speed and decel value much like the issue with using pocket sensors and no mechanical alignment device (Geneva, ratchet).

Assuming the user settles on a final speed, the current scheme still makes the initial setup & pocket alignment tricky while developing a safe (but not agonizingly slow) rotational speed.