Re: Kohzu motors poll rate issue??

[Alireza Panna <apanna1236@gmail.com>]

Hi Mark, Ron

Ok so it seems to be the controller that cannot do 60Hz updates. Thanks for your help.

Why do you need high status update rates?

To keep more accurate track of the readout of the motor positions during fly scans. We are trying to avoid using pulse outputs from the controllers as well as trying to avoid using encoders.

If status updates are only used for user feedback displays, then 5 Hz is more than adequate.

You are right 5Hz is more than adequate for client display screens, I believe caqtdm (which we use here) updates at 5Hz when the Update Type is set to timed (They also have a direct setting where the channel defines the update rate). 

Best,

Ali

--

Alireza Panna

University of Maryland, College Park

On Wed, Mar 9, 2016 at 12:53 PM, Ron Sluiter <sluiter@aps.anl.gov> wrote:

Hello Ali,

I am not surprised at the inability of the Khozu SC motor controller to do status updates greater than 22 Hz. Even with VMEbus based motor controllers that have communication via DPRAM (e.g. OMS MAXv) I have had to make some changes (i.e., up the OS's clock rate) to achieve 60 Hz status updates. The priority of a motor controller is to, of course, controller the motor. From the motor controller's view, host communication is either a low priority task or a background function.  Which begs the question...

Why do you need high status update rates?

If status updates are only used for user feedback displays, then 5 Hz is more than adequate.

Ron

On 3/9/2016 11:03 AM, Mark Rivers wrote:

Hi Ali,

 

I can see the problem.  Each poll consists of 3 write/read operations.

 

It writes the following 3 commands and reads the response to each.

\002RSY1/21

\002STR1/1

\002RDP1/0

 

The time between each write and the subsequent response is 12 ms, 17 ms, and 13 ms for the 3 commands.  These times are reproducible for the 2 poll cycles you showed.

 

Once a response is received the time to send the next poll command is always only 1 ms. 

 

So the total poll time is 12+17+13+1+1+1 = 45 ms.  That means the poll frequency will be 1/.045 = 22 Hz, which is exactly what you see.

 

So the problem is not in the motor driver, the problem is your device.  It takes 12-17 ms to reply to each poll command.

 

Mark

 

 

 

From: Alireza Panna [mailto:apanna1236@gmail.com]
Sent: Wednesday, March 09, 2016 10:47 AM
To: Mark Rivers
Cc: tech-talk@aps.anl.gov
Subject: Re: Kohzu motors poll rate issue??

 

Hi Mark,

So i turned the asyn trace masks on:

 

#For debugging purposes

asynSetTraceMask("kohzu",-1,0x9) 

asynSetTraceIOMask("kohzu",-1,0x2)

 

Here's the output that I see when I move the motor:

2016/03/09 11:25:15.013 kohzu addr 4 gpibPortRead

C\tRDP1\t-5428\r\n

2016/03/09 11:25:15.014 kohzu addr 4 gpibPortWrite

\002RSY1/21\r\n

2016/03/09 11:25:15.026 kohzu addr 4 gpibPortRead

C\tRSY1\t21\t0\r\n

2016/03/09 11:25:15.027 kohzu addr 4 gpibPortWrite

\002STR1/1\r\n

2016/03/09 11:25:15.044 kohzu addr 4 gpibPortRead

C\tSTR1\t1\t1\t0\t0\t0\t0\t0\t0\r\n

2016/03/09 11:25:15.045 kohzu addr 4 gpibPortWrite

\002RDP1/0\r\n

2016/03/09 11:25:15.058 kohzu addr 4 gpibPortRead

C\tRDP1\t-5384\r\n

2016/03/09 11:25:15.059 kohzu addr 4 gpibPortWrite

\002RSY1/21\r\n

2016/03/09 11:25:15.071 kohzu addr 4 gpibPortRead

C\tRSY1\t21\t0\r\n

2016/03/09 11:25:15.072 kohzu addr 4 gpibPortWrite

\002STR1/1\r\n

2016/03/09 11:25:15.089 kohzu addr 4 gpibPortRead

C\tSTR1\t1\t1\t0\t0\t0\t0\t0\t0\r\n

2016/03/09 11:25:15.090 kohzu addr 4 gpibPortWrite

\002RDP1/0\r\n

2016/03/09 11:25:15.103 kohzu addr 4 gpibPortRead

C\tRDP1\t-5338\r\n

 

The bold lines are when it is reading the co-ordinate value. You can see from here that the interval for subsequent reads is around 0.045s (~22Hz)

 

Best,

Ali

 

 

--

Alireza Panna

University of Maryland, College Park

 

On Tue, Mar 8, 2016 at 7:46 PM, Mark Rivers <rivers@cars.uchicago.edu> wrote:

Hi Ali,

 

To help figure this out you can do:

 

asynSetTraceIOMask portName -1 2

asynSetTraceMask portName -1 9

 

portName is the asyn port name of the GPIB port.  -1 means all addresses.  2 means ASYN_TRACEIO_ESCAPE and 9 means ASYN_TRACE_ERROR | ASYN_TRACEIO_DRIVER.

 

You will then see all of the communication from the IOC to the controllers, with time-stamps.  So you can see if the problem is communications delays or something else.   

 

You may want to send the asynTrace output to a file

 

asynSetTraceFile portName -1 “myTraceFile.txt”

 

Mark

 

 

From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Alireza Panna
Sent: Tuesday, March 08, 2016 5:25 PM
To: tech-talk@aps.anl.gov
Subject: Kohzu motors poll rate issue??

 

Hello tech-talkers,

 

I have 5 SC-410 motor controllers daisy chained to a NI PCIe GPIB controller. The motor controllers are used to control a total of 18 kohzu positioning stages. In the start-up file, I set up the kohzu controllers to poll at 60Hz

# Kohzu SC-800 motor controller setup parameters:

#     (1) maximum number of controllers in system

#     (2) motor task polling rate (min=1Hz,max=60Hz)

SC800Setup(5, 60)

 

However the max polling rate I see is ~ 22Hz. I am not sure why the motors are not being polled at 60Hz.

camonitor -tIs VPFI:KOHZU:m1.RBV

VPFI:KOHZU:m1.RBV              2016-03-08 17:54:02.824819 -1.5  

VPFI:KOHZU:m1.RBV                              +57.093353 -1.48  

VPFI:KOHZU:m1.RBV                               +0.043757 -1.46825  

VPFI:KOHZU:m1.RBV                               +0.045044 -1.457  

VPFI:KOHZU:m1.RBV                               +0.046047 -1.4455  

VPFI:KOHZU:m1.RBV                               +0.044958 -1.43425  

VPFI:KOHZU:m1.RBV                               +0.045999 -1.42275  

VPFI:KOHZU:m1.RBV                               +0.045986 -1.41125  

VPFI:KOHZU:m1.RBV                               +0.045030 -1.4025  

VPFI:KOHZU:m1.RBV                               +0.045986 -1.4  

 

I have tried removing all but one SC-410 controller, to see if it is because of the GPIB cable. I have also tried just having one SC-410 controller with one axis connected (each controller can supports a max of 4 axes), but I don’t see a change in the polling rate. I also don’t think it is the GPIB controller card, since I have tested two cards (Agilent 82350b and NI PCI-e GPIB) now, and in both cases the max polling rate is see is 20Hz. Also I don’t really see a big difference in the polling rate when the cpu is under high load vs. low load. I am not sure if it is the controller limit at this point (I could not find any documentation regarding how fast the controllers can poll, maybe I need to look harder)  I am using linux-gpib-4.0.2, asyn-4-26, motor-6-9, base-3.14.12.5.

Any help is appreciated on this.

 

Also some of the stages, we have do not have an origin sensor on the motor shaft, so the origin return sequence 3 for homing the stages no longer works. I temporarily changed it to look for the NORG (origin proximity sensor)

case HOME_FOR:

case HOME_REV:

           rtnval = write_parms(pbuff, signal, cntrl, motor_call, command, mr);

           sprintf(buff, "ORG%d/2/0/0/4/1", axis);

           break;

but then I need to change it back for the one’s that do have an origin sensor. Is there a better way to do this. Maybe have a record for home search?  For the time being i just use HOME_FOR to use method 4 (look for NORG) and then HOM_REV stays as is.

 

Best,

Ali