Why does'nt it blend correctly on the first layer

[WDuley]

This is a four axis gantry palletizer. I am blending xyz axis. After picking up the boxes it goes up(z), then horiz (x,y),
then down to pos abs 298,200 counts on z, then a tuck move of 9940 counts in x, y, and z. On the first layer of the pallet, it is not waiting for z down to nearly complete before the tuck move starts. In other words the tuck move starts about 12" before it should, however it does finish the move. On the rest of the layers it works fine. The only thing different on the first layer is a larger Z pos abs move, as it repeats the pattern on the other layers with shorter Z moves.

The encoders are scaled (in cnts/inch) X= 3175, Y= -3175, Z= -4970
Could it be the unequal scaling of the axes?

I noticed that I am giving a flex_load_vs_pos before the flex_start. NI examples give the flex_start before the flex_load_vs_pos. Could this be the problem?

Or could it be the accel, decel being too high/low for this particular move?

gnRet = flex_flush_rdb(gnBrdID)
'Reset bit 15 (user status bit 3) in the Motion complete status
register which shows that the program has completed
mustOn = 0
mustOff = &H80
status = flex_set_status_momo(gnBrdID, mustOn, mustOff)

gnRet = flex_begin_store(gnBrdID, 1)
gnRet = flex_config_vect_spc(gnBrdID, &H11, 1, 2, 3)
gnRet = flex_set_op_mode(gnBrdID, &H11, 0) '0=PosAbs

gnRet = flex_load_accel(gnBrdID, &H11, 43891, &HFF
gnRet = flex_load_decel(gnBrdID, &H11, 43981, &HFF)

gnRet = flex_load_accel(gnBrdID, &H11, Acl&, &HFF)
gnRet = flex_load_decel(gnBrdID, &H11, Acl&, &HFF)

gnRet = flex_load_vel(gnBrdID, &H11, Spd&, &HFF)
gnRet = flex_load_blend_fact(gnBrdID, &H11, -1, &HFF) '-1=immediate


PlaceXYZ:
Call ZCruisePosition(Zpos&) 'get the ZPosition (varies by the layer)
Zpos& = Zpos& * glCpi&(3)
'Go up to ZCruisePosition (keep X and Y stationary, move Z)
mustOn = 2: mustOff = 0: timeout = 3000 'timeout of 30 seconds
gnRet = flex_wait_on_condition(gnBrdID, &H10, 0, 15, mustOn, mustOff, 0, timeout, 0)
gnRet = flex_load_vs_pos(gnBrdID, &H11, glEncoder&(1), glEncoder&(2), Zpos&, &HFF)
gnRet = flex_start(gnBrdID, &H11, 2) 'start VS1

'Go horiz over Place (move X and Y, keep Z stationary)
gnRet = flex_wait_on_condition(gnBrdID, &H10, 0, 15, mustOn, mustOff, 0, timeout, 0)
gnRet = flex_load_vs_pos(gnBrdID, &H11, glPlc&(1), glPlc&(2), Zpos&, &HFF)
gnRet = flex_blend(gnBrdID, &H11, 2)

'Go down to Place (keep X and Y stationary, move Z)
gnRet = flex_wait_on_condition(gnBrdID, &H10, 0, 15, mustOn, mustOff, 0, timeout, 0)
gnRet = flex_load_vs_pos(gnBrdID, &H11, glPlc&(1), glPlc&(2), glPlc&(3), &HFF)
gnRet = flex_blend(gnBrdID, &H11, 2)

'Do the 2" tuck (move X, Y and Z 2")
gnRet = flex_wait_on_condition(gnBrdID, &H10, 0, 15, mustOn, mustOff, 0, timeout, 0)
gnRet = flex_load_vs_pos(gnBrdID, &H11, glDt&(1), glDt&(2), glDt&(3), &HFF)
gnRet = flex_blend(gnBrdID, &H11, 2)

'Set bit 15 (status bit 3) in the Motion complete status register
'which shows that the program has completed
mustOn = &H80
mustOff = 0
gnRet = flex_set_status_momo(gnBrdID, mustOn, mustOff)

gnRet = flex_end_store(gnBrdID, 1)
gnRet = flex_run_prog(gnBrdID, 1)

[Dustin_W]

Your best bet will be to break that first long move into two moves, one long move, and then a shorter move. That way you limit the length that the X-Y move can blend with.

[WDuley]

Dustin,
That worked, Thanks. I've pulled my hair for two weeks trying to get it to work right. But why was it necessary to have to break it into 2 moves?

[Dustin_W]

Several things could play into it. The way blend is supposed to work is when one move begins to decelerate, the next move starts it's acceleration. My best guess is that the deceleration for the first move was happening sooner than you expected, and therefore your second move began accelerating earlier than expected as well.