Re: Kohzu motors poll rate issue??

[Alireza Panna <apanna1236@gmail.com>]

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