ATC Project - Debug phase

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

OK, thanks for testing. It looks like I need to set up a counts-mode simulator to get to the bottom of that.

How hard is it for you to go back to I mode? I think that should be much improved now. (Though for your system C is probably the way to go, it's less likely to get "lost" (Always a risk with mode I) 
 

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.

More tweaks. And I updated the Vismach config to show tool numbers on the carousel. This was necessay to be able to test properly, and possibly took more effort than the rest of the work.
It also shows that the VMC_graycode config has something wrong with the graycode simulation, but I don't think that's a new problem.

I have pushed the changes to master. But here is the latest comp if you want to try it.
 

Testing notes for 6/27 version

COUNTS mode

• Homing works to pin sensor, no slow search
• Subsequent pocket commands move scale amount, no slow search
• No change in slow search behavior regardless of width, speed, or decel-time settings
• Jog TEST1 (fwd)
  • Requires a second enable-disable sequence to clear the state and motor-dir.
  • set jog-fwd to high
  • set enable to high < carousel moves one pocket
  • set enable to low
  • set jog-fwd to low
    • motor-dir is still 1, state is 20
  • set enable to high
    • state now 9
  • set enable to low
    • motor-dir is 0, state now 0
• Jog TEST2 (fwd, changed sequence)
  • set jog-fwd to high
  • set enable to high < carousel moves one pocket
    • motor-dir = 1, state = 20
  • set jog-fwd to low
    • carousel does slow search to previous pocket. (not to sensor, but by scale counts)
    • current-position updated to pocket-number
  • set enable to low
    • motor-dir is 0, state now 0
  • Tried playing with decel-time and width, but nothing changed the 'back up to the previous pocket' behavior.
• Jog TEST3 (reverse)
  • set jog-rev to high
    • motor-dir = -1, state = 20
  • set enable to high < carousel moves one pocket to pin sensor
    • motor-dir = -1, state = 20
  • set jog-rev to low
    • carousel does slow search to pin sensor edge
    • motor-dir = -1, state = 9
  • set enable to low
    • motor-dir is 0, state now 0

INDEX mode

• Slow search works for both homing and pocket commands
• Jogging works both directions
  • set jog-fwd to high
  • set enable to high < carousel moves to next pocket sensor
  • set jog-fwd to low < carousel does slow search to edge of pocket sensor
  • set enable to high
    • motor-dir 0, state 0

Hope that was useful
-R