carousel.comp - jog-FWD still an issue

Thanks.  I'll do some proper diagnostics when I get home this evening.

log the pocket number in the carousel component, I'd be willing to bet that you have some kind of error with position encoding happening.

if not a issue with decoding, the statements here might be conflicting in nature at line 294, not sure why you'd subtract the jog rev from the jog fwd.

switch (state){
case 0: // waiting at start
motor_dir = 0;
if (jog_fwd || (jog_rev && inst_dir == 2)) {
if ((inst_code == 'I' || inst_code == 'E' || inst_code == 'C') && ! homed){
state = 10;
break;
}
target = current_position + jog_fwd - jog_rev;
if (target > inst_pockets ) target = 1;
if (target < 1) target = inst_pockets;
if (jog_fwd){
motor_fwd = 1;
motor_rev = 0;
motor_vel = fwd_dc;
motor_dir = 1;
}
if (jog_rev){
motor_fwd = 0;
motor_rev = 1;
motor_vel = rev_dc;
motor_dir = -1;
}
active = 1;
state = 20;
break;
}
motor_vel = hold_dc;
if (! enable) return ;
active = 1;
if ((inst_code == 'I' || inst_code == 'E' || inst_code == 'C') && ! homed){
state = 10;
break;
}
state = 1;
ready = 0;


here is how I have it written in my Hal toolchanger component project. and I have not fully tested this snippet of code yet.

if (increment_button) { // input from hal to increment pocekt
pocket_request += 1;
}
if (decrement_button) { // input from hal to decerment pocket
pocket_request -= 1;
}


if ((pocket > pocket_request) && (caoursel_down == true) && (carousel_out == true)) {
// Move tool changer backwards
motor_fwd = false;
motor_rev = true;
} else if ((pocket < pocket_request) && (caoursel_down == true) && (carousel_out == true)) {
// Move tool changer forwards
motor_fwd = true;
motor_rev = false;
} else
if (pocket == pocket_request){ // Tool changer is already at the correct pocket
motor_fwd = false;
motor_rev = false;
}

Holy brainfarts...it was a loose pin.

The pluggable terminals on the drive are the screw type, and if you don't open them up far enough before inserting the conductor you can tighten them and get a 'false' clamp.

After making sure the drive wasn't toast (via RS232 commands), I switched to a different stepgen on the 7i76e and it was doing the same thing.  Checked the board end terminals... then pulled the terminal block out of the drive and one of the DIR differential pair was a little wiggly... false clamp.

It's likely been that way for months and was casuing intermittent issues this whole time.

After setting align_dc and decel_time to 0 (no pocket pins to search for), it's responding to jogs and pocket destination commands.

I feel rather foolish, but at least I can get on with testing the ATC now.

Thanks Andy, and sorry for bugging you before doing remedial troubleshooting.

Andy,

Current status is the same as from the last github post:

• Normal pocket commands work fine.
• Increasing the accel and velocity result in misalignment
  • Not lost steps in motor/drive (I'm using closed-loop stepper with tight following error settings)
  • Not related to steplen or stepspace
  • 'feels' like a velocity-mode stepgen commanded by a coarse-resolution timer, but I'm inexpert and not able to precisely define the issue.
• Homing works
• Home offset isn't fool-proof
  • If home offset is >0, homing malfunctions if the carousel is already at pocket #1
  • In this case, carousel will just move the offset amount and doesn't take the decel time in to account
  • I think homing sequence should ignore the home pocket sensor if already triggered and start rotating until the sensor triggers again, then apply the offset
• Unhome doesn't work, no change from github description
• jog-fwd/rev don't do anything except get stuck at state=20

Carousel is working for me now, at the speed/accel settings which don't result in misalignment.  I have physically moved my home/pocket sensors to get alignment sorted out, but that may not be possible for everyone else using carousel.

Would be nice to have jog working.

Thanks for the updates Andy.

I'll get the latest comp and start playing with it this evening.  Might take me a day or two to get back with results, but I'll get right on it.

-R

I've loaded the latest comp and am fiddling with it now.  Preliminary report:

• Homing/unhoming
  • Works perfectly, even if it starts at pocket #1.  Nice.
• Home offset
  • Works perfectly!  Very satisfying to use LCNC to adjust the alignment instead of nudging sensors or flags.
  • Can start homing from any position - even in-between pockets - and the offset works well in both directions.
  • Note that I haven't changed my rotational speed or accel during the above testing.  I'll try 'stress-testing' soon.
• Jogging - still no joy
  • #1 Starting from a homed carousel, with enable/jog pins unlinked from other hal connections
    • align-dc = 0
    • current-position = 1
    • pocket-number = 1
    • counts = counts-target
    • Set enable low (state = 0)
    • Set either jog-fwd/rev high through halshow (state 0 > 20)
      • current-position = 1
      • pocket-number = 1
      • counts = counts-target
      • Carousel does not move, and no way to get out of state = 20...must restart LCNC
  • #2 Starting as above
    • Set enable high (state 0 > 9)
    • Set jog-fwd high (state = 9, no movement or response)
    • Set jog-fwd low (state = 9)
    • Set enable low (state 9 > 0)
  • #3 Starting from #2
    • Set enable high (state 0 > 9)
    • Set jog-fwd high (state = 9)
    • Set enable low (state 9 > 20)
    • Now stuck at 20.

Once it's stuck, there's no combination or sequence of inputs/commands I can think of can get it out of 20.

UPDATE

I've just had an ATC crash with the counts mode config.  Crash was due to the pocket not being aligned with the tool holder before the head came down on the misaligned tool.  Thankfully I have plastic tool forks and a (intentionally) fairly flexible platter.

No major damage I can see, but I still need to check everything closely.  No alarms or error messages until the crash happened.

No changes to my config or sequencing macros since the last program I ran.  The head should not have come down until carousel reported being in position via carousel.0.ready pin going high.

Assuming carousel reported being in position, this means the counts were off from intended.

Once I've determined there is no serious damage I'm going to try switching to carousel's index mode and start testing again.

EDIT
Just discovered that I've failed to connect my ATC stepper drive alarm to some LCNC estop or other alarm signal in HAL.  So it's plausible that the stepper drive faulted, failed to rotate per command, and wound up misaligned once carousel.0.ready went high.  I don't know if this is the case as there won't be any records or data trail in LCNC for me to investigate the crash.

So despite preaching the value & reliability of a closed-loop stepper for ATC use, I've managed to shoot myself in the foot again.  I may still switch to carousel-index mode, but I think I'll do some testing while still in counts mode once I've hooked up the alarm signal.