desired velocity zero bit problem

[steveneads]

Hi

 

I have a PLC that commands jog moves and waits for them to execute before moving on. It uses the desired velocity zero bit to determine when the move has started and completed. However, with slow jog moves the code doesn't work as I expect (it's OK with faster moves) and it seems as if the desired velocity zero bit glitches at the start of the move.

 

Here's a simplified excerpt of the code:

 

;addresses used (motor 4)

brDesiredVelocityZero->X:$000230,13,1

brPosJogCommand->L:$000257

 

 

;code....

 

 

IF(brDesiredVelocityZero=1)

 

COMMAND"#4HOMEZ" ;set motor axis position to zero

 

brTimer=0 ;this is automatically decremented each servo cycle

WHILE(brTimer>-20) ;wait for 20 servo cycles for command to execute

ENDW

 

brPosJogCommand=brStroke ;set jog distance (expected time for jog about 10 seconds)

 

COMMAND"#4J=*"

 

I5211=0 ;zero timer

WHILE(brDesiredVelocityZero=1) ;hold until move begins

debug1=I5211 ;record time in loop

ENDW

 

 

brMoveDone=0

I5211=0 ;zero timer

 

WHILE(brMoveDone=0) ;wait for move to complete

 

IF(brDesiredVelocityZero=1)

brMoveDone=1

debug2=I5211 ;record time in loop

ENDIF

 

ENDW

 

ENDIF

 

The move is expected to take about 10 seconds, but the second while loop actually exits far too soon. I added debug variables in the loops to time how long they stayed there. debug1 registered 20 servo cycles - suggesting that this was the time taken for the jog command to execute and for desired velocity zero to go false. However, the second while loop also exited very quickly - after about another 20 servo cycles instead of the expected 10 seconds. If I modify the first loop to wait for 500 servo cycles instead of using desired velocity zero - the second loop exits correctly at the right time. This suggests to me a glitch of some sort in the desired velocity zero bit.

 

Have I missed something here?

[Richard Naddaf]

You need to insert a small timer delay right after issuing the Jog command. and before checking for the desired velocity zero bit. Also, you may want to make use of the in-position true bit.

 

Another thread came up recently with a similar question. It explains the use of delay timer with jog moves in a PLC.

 

http://forums.deltatau.com/showthread.php?tid=1602

[steveneads]

Hi Richard

 

I've read the other thread, but I don't think that you explain why a timer is needed! In my code I issue the jog command, wait for the desired velocity zero to go false to indicate that the move has begun, and then wait for it to go true again to determine when it's finished. As far as I can see, this logic should be robust without a timer delay if the desired velocity zero bit really works correctly.

 

If there really is a need for a timer delay, how short can it be? In my example, when I used the 500 servo-cycle delay, this was too long in some circumstances, so I really need to keep the delay to the absolute minimum necessary.

[bradp]

Problem without a timer is if the jog move is shorter than a plc scan, if you are already at the jog destination, if another condition such as a limit prevents the jog from starting. Then you are locked in a while loop that will never exit. To make the code robust you should look at the possible situations and decide if a timer or the desvelzero bit or some other information like a timeout variable would prevent such problems.

[steveneads]

I can understand why a timer is a good idea to prevent code hanging indefinitely in a WHILE loop - however, this is the opposite problem to what I believe I'm seeing. In my case the WHILE loop seems to exit too soon unless a timer is used to hold it there for a short period. This seems to be because the desired velocity bit is not behaving as I expect.

 

Maybe I'm going to have to put it down to being another of life's mysteries!

[bradp]

Why not data gather the bit? Somewhere before the jog put CMD"gat" and after the loops put the cmd"endg". Then you can see the bit with servo cycle resolution and maybe find something that helps explain it.

 

Since you are using a j= command you could also look at the motor program running bit to see if some different behavior shows.