1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 <2016> 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 <2016> 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: Kohzu motors poll rate issue?? |
From: | Mark Rivers <[email protected]> |
To: | "'Alireza Panna'" <[email protected]> |
Cc: | "[email protected]" <[email protected]> |
Date: | Wed, 9 Mar 2016 17:03:21 +0000 |
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:[email protected]]
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 <[email protected]> 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:
[email protected] [mailto:[email protected]]
On Behalf Of Alireza Panna 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 |