ATC Project - Debug phase

Thanks Andy, excited to try it.  I'll give it a test tonight and report back.

Does this do the slow search just for the initial indexing, or for all pockets?

If its just for the initial index/home move, then search direction shouldn't matter for later bidirectional moves in 'counts' mode since the first enable (homing) always moves CW; after that carousel isn't using any sensors.

But I agree that if used in other modes the slow search direction should be the same and not symmetrical.

Quick question - if I need to change back and forth between the two .comp files, I should rename the undesired one carouselcomp01.bak and then simple recompile again?  Just checking because I've successfully compiled the last one, but I haven't 'gone back' to an earlier version yet.

 

Got it compiled and installed and had a go at it.

align-dc was easy, but figuring out decel-time took quite a bit of fiddling.  Too high or too low and it went one (or two) pockets too far.

Obervations:
I/we were correct - on a bidirectional 'counts' carousel where the sense pins have any width, the symmetrical slow search results in misalignment when approaching from the direction opposite the initial homing direction.

It also appears to be ignoring - or at least overriding - the counts to the next pocket.

Pocket 1 counts = 21472 (after homing)
Pocket 2 counts = 22474
Pocket-to-pocket move = ~1000 counts
scale = 1250
width = 5

It was ~250 counts off because it went past the sensor and backed up - which was the opposite direction of initial homing.  And ~250 counts appears to be about the window of the pocket pin sensor.

I think for counts mode, the slow search is great for the initial homing, but after that there shouldn't be any movement or searching based on pocket sensors unless it's a unidirectional carousel.

As you indicated earlier, using the pocket sensors as a sanity-check strobe would be a good safety feature, but it's interfering with the counts function as-is.

Counts mode is working great without the pocket search.  I set up a pointer on pocket 1 and stationary reference mark and did about 30 pocket changes, in both directions.  Every time it went back to pocket 1 it was dead-nuts on.

andypugh wrote:

You did an interesting experiment, but possibly not the one I intended.


 

Yes, that sums me up nicely.


Had another go with the new version.

HOMING  (appears to work properly)
Rotated CW to index pin
Rotated CCW slowly until sensor went low
Rotated CW slowly until sensor went high and stopped.

CW MOVES (does not appear to work properly)
Set pocket to #2, enabled carousel (from home pocket)
Carousel moved CW to pocket #2, continued past the sensor and stopped
Moved CCW (reversed) past #2 to pocket #1 at slow speed.
Stopped at pocket #1

Disabled then re-enabled carousel and it repeated the go past and back-up to the previous pocket.
Did the same thing from pocket #1 to pocket #3 (any CW moves).  Move to pocket, then back up an extra pocket and stop.
It did not lose track of position - i.e. when sitting at pocket #1 current-position = 1, but pocket-number = 2.
I adjusted decel-time from 0.01 to 1.5, no effect on CW behavior noted.

CCW MOVES  (appears to work properly)
Set pocket, enable carousel
Moves to CCW pocket-number
backs off the sensor CW
approaches the sensor CCW until it just triggers then stops.

Forgot to report on jogging

jog-fwd: moves correct direction
jog-rev: does not move at all, even when I force current-position = pocket-number

Not hard at all to switch back - I'll try it right now.

EDIT  test results for INDEX:

Homing - works fine

As before, CCW works fine (#1 to #18)

CW is working now.  At first it did the same thing as before except it lost track of position
Pocket 1 to pocket 3
Moves CW past sensor 3, reverses back to pocket 2 and stops... only this time current-position reported 3 as if it had hit the target.

If you recall, last time carousel 'knew' it had gone too far the wrong direction.

Changed decel-time from 0.5 to 0.1 and it started acting as desired.  I raised the speed from 50 to 100 and it still worked nicely.

Definately need a caution in the component man file to prove out decel-time, and maybe a hint for starting values.

I think it's a big win for anyone running open-loop steppers.  The slow latch means the pockets won't get out of alignment even if a few steps are lost over the course of a long program.

As you mentioned, for closed loop steppers or servos, the extra search/latch time is unnecessary and 'counts' mode would be preferred (assuming the homing/index latch remained)

PS... it just occurred to me that with the working bidirectional latch, in 'index' mode you could have a carousel with uneven pocket spacing and it'd still work.  As long as the pocket sensor pins lined up with the pockets, carousel would have no problem if the spacing between pockets were not precise.

Use case #1 would be to build a carousel with one or two extra-wide pocket positions for large diameter tools (saw, facemill).  Rather than having to empty the pockets before and after the big-tool pocket for clearance, you could just manufacture the carousel with two pockets that take up the same arc length as 3 pockets - bit of extra clearance.  Index mode with latch would handle this no problem.

Use case #2 would be for someone building a carousel without the help of a indexing head/table or a large mill.  As long as you got the radial distance from the carousel axis close, you could eyeball the pocket locations and still be in business.  Lay it out by hand and poke some holes for forks - bamma-jamma.  Just make sure the sensor flags all had the same relationship to the forks.

Nice job, thank for working on this.