Re : serial read statement delay

[hasqual]

I am using a program that interfaces with a motion controller.  Initially, I used large time delays to ensure that the device was in the proper location before moving on, but then I tried to get more elegent and query the position in a whlie loop, and exit the loop when the returned position is no longer changing (meaning a move is complete).  This works for the most part, but with some delays that I am unable to explain (but imagine one of the seasoned vets could tell me in an instant).  I introduce a 0.1 second delay in the while loop to make sure the calls don't occur so fast that no position change has occurred in successive calls, unless the device has truly stopped.  The problem I am getting is a large lag time from when the device stops moving, to when the corresponding position indicator says it has stopped moving. 

For instance, I tell the device to move 100,000 "steps".  Watching the position indicator go from 0 --> 100,000 is instructive, as the indicator says the motor is still at position ~60,000 when it actually stops moving, whereupon the indicator still ticks up to 100,000, but ~5 seconds behind reality.  Why would there be such a lag time in signal delivery, especially when there is a time delay instituted in the loop?  No matter what I changed the time delay to be (higher or lower) the same lag occurs.  At what step in the communication process is the bottleneck of information taking place ... and why? 

Just for kicks, I tried adding a "flush buffer" statement at the end of the while loop, in case the buffer was somehow getting backed up, but then the program really crapped out.  I don't understand why this would have such a lag though.  If a move takes even 100 seconds, with a 0.1 second delay that should only be 1000 write/read statements correct?  Most moves take on the order of 5 seconds though, which is 50 write/read statements.  Any thoughts? 

My program is attached, but not able to be run since it references the motion controllers.  Thanks!

[JB]

Please try slightly modified version of your VI and let us know what happens !

[hasqual]

Sorry, basic posting practice that I missed ... I am running Labview 7.0, thus I couldn't open the attachment.  If you can either post in 7.0 or earlier, or a picture that I can replicate that would be great!  Thanks for the help.

[JB]

Here is it ! I'm a impatient to know if it works...

[hasqual]

After the new sub-vi, it has the same sort of a problem.  I put in a move that takes ~7 seconds (100,000 steps), and watching "number" on the "position_vi_2", it lags about 7 seconds behind, such that 7 seconds after the move stops "number" shows 100,000. 

Sidenote, the reason this problem is important is that most moves take less than 5 seconds, thus there isn't a big deal, but there are occasional moves that can take upwards of 1-2 minutes, which this then multiplies to take quite a bit longer. 

To me it seems like the crux of the issue is that there is a bottleneck taking place in the information transfer, and I can't believe it's because I'm sending too much info, since in these short, 7 second runs it seems to be a small amount of data (8 bytes/transmission * 1 transmissions/ 0.1 seconds right?).  This would mean something on the order of 80 bytes/second, which isn't close to the baud rate right?  (I'm no electrical engineer and could be missing something here).  I just don't understand how the computation can get so far behind reality, as no movement change even shows up on the number until ~2-3 seconds after initial motor movement, and falls behind even further by the time the move is complete, which is why longer moves prove even worse.  Why can't it report the position, relatively closely to instantaneous position, on the fly? 

[JB]

(8 bytes/transmission * 1 transmissions/ 0.1 seconds right?)

Your description of the behaviour of the new version is not correct.

Write command --> Wait answer (max delay = timeout set by VISA Configure Serial Port) --> Read answer --> Wait 0.1s --> Write command...

So the overall transmission rate is now set by the time the controller needs to answer and may therefore be variable. Only the delay between a read and the next write is set by the software to 0.1s.

In your original VI a new command is sent to the controller without waiting for the answer to the previous command. With short delays, the controller will not have the time to finish the processing of a command before a new one ! I don't know how the controller manages too high rates but this could explain the delays (commands put in a buffer and processed one after the other). Therefore I expected the new version to solve this problem.

Here is what I would do to from this point :

1. Try to find some information about a possible minimal delay between 2 transmissions in the user manual of the controller.
2. Set a longer wait (eg 2s instead of 0.1s) before writing a new command.
3. Check the delay for the answers and if there are timeouts (return count < 2). By the way, what is the expected answer from the controller to the pos command ? (nb of bytes...)
4. Check if the behaviour is the same when there is no move. The controller may be busy during a move and only react with a low priority to the pos command.
   

Attached version should help you to do the mentionned investigations.

[Henrik_Volkers]

I don't know your positioning system, but maybe that system already have a move/command finished register /query command?

As JB mentioned, when the controller is busy the answers seems to be delayed. 

If you know the parameters of speedup/down ramp and velocity you can make a good guess about the time it will need and reduce the polling.

[JB]

---

Henrik Volkers a écrit:

I don't know your positioning system, but maybe that system already have a move/command finished register /query command?

As JB mentioned, when the controller is busy the answers seems to be delayed. 

If you know the parameters of speedup/down ramp and velocity you can make a good guess about the time it will need and reduce the polling.

---

Very good points Henrik! I can only agree. The tests will show if our assumptions are correct...

[hasqual]

(1)Try to find some information about a possible minimal delay between 2 transmissions in the user manual of the controller.
(2)Set a longer wait (eg 2s instead of 0.1s) before writing a new command.
(3)Check the delay for the answers and if there are timeouts (return count < 2). By the way, what is the expected answer from the controller to the pos command ? (nb of bytes...)
(4)Check if the behaviour is the same when there is no move. The controller may be busy during a move and only react with a low priority to the pos command.

Regarding (1), I checked through the manual and didn't find any information pertaining at all ... I may call and see what they think of some of these problems though.

I tried (2) in the new program, and it returned different results numerically, but just as long of a delay.

Regarding (3), no timeouts appear.  The expected answer is alternating between 2 or 15 bytes, in the order (2,15,2,15,2,15 etc...) as long as the command takes place, which is why I only get results on half of the answers, the 15 byte answer contain the information I need.  The information then is offset by 6 bytes from the beginning and 8 of them are taken to obtain the numerical position.

Regarding (4), the question I have here is regarding the fact that the system doesn't speed up once the move is complete.  If it was that resources were diverted to moving the motor, wouldn't the whole system speed up again once the move was technically complete?  Even if there was a backlog of information I would have expected it to arrive faster once the move was complete, yet it steadily reports the information at the same rate regardless of the motor moving or not.  Is this accurate to assume?

The results from the new program:

When running with a time delay of 0.1 seconds, the number of iterations varies between 100-115 iterations.  The "Answer delays" is almost always 14, very occasionally 13.  The "Answer delay" indicator (if I am watching closely enough) is 14 at the beginning, and 0 for the rest of the time.  The "Answer" button blinks consistent with the 0.1 second time delay and the "Answers" button never blinks. 

For a run using a 2 second delay, instead of 0.1 seconds, the answers are scaled down to 10-11 iterations, and the type of delay for "Answer delay" and "Answers delay" (14 almost all the time for Answers delay, and Answer delay 14 out the shoot, then zero after the fact).  In all cases "number" does end at the expected and correct value. 

Any thoughts?  Thanks again for all your guys' input and help.