EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  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  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: PMAC IP and motor records
From: Krzysztof Lazarski <[email protected]>
To: "Rees, NP (Nick)" <[email protected]>, Dirk Zimoch <[email protected]>
Cc: tech-talk <[email protected]>
Date: Tue, 13 Jan 2009 15:52:11 -0600
Dirk,
If you are interested, I can send you the source code of the simple SNL
application, which is using Delta Tau Windows driver (PCOMM32 or PCOMM32 PRO
2), which should work with your firmware version and with any kind of
connection (network, USB, serial, PCI, ISA) to the PMAC (through
SelectDevice() the PMAC selection window).
It includes InPosition, actual positions monitoring and triggering jog
movements for 32 motors. I can add for you, the monitoring of the analog
inputs (with my setup).
This solution is based on Delta Tau's API calls and is using the same
programmatic techniques as in the PMAC Executive Suite (Delta Tau product).
Probably, you can run this sequencer together with your original Windows
application, in this way adding you own functionality.

We are using PMACs since 1996, here at Structural Biology Center at APS
sector 19. When we were deciding about our upgrade path, there were no EPICS
device drivers available, except our one - VME based (written by Tom
Coleman). Our upgrade approach was to write modular SNL application,
flexible enough to be extended with an additional PMAC functionality, which
we would like to add (or remove), easily, any time. Similar to what our
SBCserver offers. SBCserver is the interface between our beamlines, EPICS
and user GUIs, and other socket clients.

Because of rules of the tech-talk, if you are interested, please send me
direct email request, and I will send you the tar.gz file of a test
application (you should have at least DOT NET 2002 with "make" from Cygwin
(or MinGW), on your Windows computer).

Best regards,
Krzysztof.

-- 
+-------------------------------------------------+
Dr. Krzysztof Lazarski
Structural Biology Center, Beamline Software Development Coordinator
Argonne National Laboratory
9700 South Cass Avenue, Building 435 D002
Argonne, IL 60439-4830
ph: 630-252-3855, fax: 630-252-0564
[email protected]
www.sbc.anl.gov
 +-------------------------------------------------+
-- 


On 1/13/09 11:38 AM, "Rees, NP (Nick)" <[email protected]> wrote:

> Dirk,
> 
> First, I would suggest upgrading from 1.938, or better still, buying a
> new controller card to do your upgrade on while still preserving the old
> one. Version 1.938 was released in June 2001, and I suspect that we are
> using features of the Ethernet interface that didn't exist back then. We
> have only ever used 1.941 and 1.943 and we have been running since 2005.
> 
> As to where to start, start with the PMAC quick reference:
>  - http://www.deltatau.com/fmenu/PMAC%20QUICK%20REFERENCE.PDF
> 
> However, this will quickly exhaust you and you will find yourself
> needing the full 800 pages of the software reference manual:
>  - http://www.deltatau.com/fmenu/TURBO%20SRM.PDF
> 
> Also, go on a course (we run them at regular intervals) or come and
> visit. Finally, CosyLab are Delta Tau partners and resellers, so I am
> surprised you haven't heard from them already :-).
> 
> What you will find is that the Delta Tau is an extremely capable,
> extremely well documented controller that is basically a pain in the
> neck if you just want to do something simple. A lot of information is
> via indirection registers that can be redefined at will. Woe betide
> anyone who deviates from the standard settings. Unfortunately, your
> controller does seem to have deviated.
> 
> The standard place to find the motor actual position (which is normally
> the same as the encoder position, but can also be a stepper motor pulse
> count) is M(100*n+62). This is because M162 (taking axis 1 for example)
> is normally defined by the expression: M162->D:$00008B, which means that
> it refers to a double word (48 bit) integer location at address 0x8B in
> the PMAC address space and that holds the actual position expressed in
> units of 1/(I109*32) counts. I109 is normally 1, so units are 1/32 of a
> count. You get the general idea.
> 
> The other way to get the actual position is to use the P command. This
> returns a value in counts, and does not rely on indirection registers.
> That is what pmacAsynMotor does.
> 
> On the other hand, the PMAC is fairly open, so you shouldn't have to
> reverse engineer it at all. With the aid of a manual, you can understand
> it, and the command line interface allows you to dump all of
> configuration and nearly all of the running programs and PLC's as simple
> ASCII text, so you can find out what is going on inside.
> 
> Good Luck,
> 
> Cheers,
> 
> Nick Rees
> Principal Software Engineer           Phone: +44 (0)1235-778430
> Diamond Light Source                  Fax:   +44 (0)1235-446713
> 
>> -----Original Message-----
>> From: Dirk Zimoch [mailto:[email protected]]
>> Sent: 13 January 2009 14:13
>> To: Rees, NP (Nick)
>> Cc: tech-talk
>> Subject: Re: PMAC IP and motor records
>> 
>> Hi Nick,
>> 
>> The PMAC says its version is 1.938. The controller is a Turbo
>> PMAC2. The 
>> connection uses TCP.
>> 
>> The PMAC is part of a "turn key" system which came with a
>> Windows program. But
>> the program is not flexible enough. Thus, our users asked me
>> to replace the 
>> Windows computer with an EPICS ioc. I have not configured the
>> PMAC and cannot 
>> change the configuration. I can only reverse-engineer the
>> system from what I
>> found in the source code of the Windows program and from
>> spying on the network
>> traffic.
>> 
>> In particular I found in the configuration, that for any
>> motor number n, the
>> encoder can be read with M210+n. For example for motor 1 read
>> M211. I do not now
>> if that is typical for PMAC or special to this application.
>> 
>> Where can I learn the communication protocol, for example,
>> what "M211" actually
>> means or does? I found many documents on the delta tau pages
>> but which one 
>> should I read a beginner? At the moment all your talking
>> about Q and P 
>> variables, and coordinate systems does not mean much to me.
>> 
>> I also have the problem that if I open and close a TCP socked
>> to the PMAC a few
>> times, the PMAC hangs up and needs a power cycle. Have you
>> ever seen such an
>> effect? On the other hand, restarting the Windows program
>> does not show this effect.
>> 
>> Dirk
>> 
>> Rees, NP (Nick) wrote:
>>> Dirk,
>>> 
>>> Gosh, suddenly everyone wants to know about the PMAC.
>>> 
>>> As far as I can tell, you have configured your pmac
>> correctly - in fact
>>> better than the example I gave in the earlier response to Richard
>>> Pastrick because the last parameter in
>> drvAsynMotorConfigure should be
>>> one more than the last parameter in pmacAsynMotorCreate
>> (because of a
>>> 1-based and 0-based numbering conflict).
>>> 
>>> What seems to be happening is the first error message you get is a
>>> timeout when sending a VR_PMAC_FLUSH command to the PMAC.
>> This is what
>>> pmacFlush does in the interpose layer. I can't explain this
>> unless you
>>> have a old version of the PMAC firmware which doesn't
>> support all the
>>> current functionality. Please let me know what the "ver"
>> command returns
>>> and what type of PMAC you are trying to control. This is my
>> best guess
>>> as to the problem. I assume you have it running TCP as
>> discussed in the
>>> last thread on this back in December.
>>> 
>>> In answer to your other questions:
>>> 
>>>> Can the motor record read the encoder values from PMAC?
>>> 
>>> The motor record has the current profiled demand position
>> in RMP and the
>>> encoder value in REP. What is meant by "encoder value"
>> depends on how
>>> you have configured the PMAC.
>>> 
>>>> How can I use programs (homing an scanning procedures) on the PMAC?
>>> 
>>> You have full access to all PMAC functionality via the
>> asynOctet port.
>>> At DLS, we also have a set of interface guidelines to
>> interface motion
>>> programs so everything is standardised, and if you abide by these
>>> guidelines, then we also have a pmacAsynCoord driver to connect
>>> coordinate system axes to motor records. The specific pmacAsynCoord
>>> driver requirements are:
>>> 
>>>  - Q71..79 are reserved for the axis demand positions, and
>> are set by
>>> the EPICS software
>>>  - A position reporting PLC must be implemented which
>> reports back the
>>> positions of co-ordinate system axes A,B,C,U,V,W,X,Y,Z on variables
>>> Q81..89
>>>  - The axis deadbands must be reported on variables Q91..Q99
>>>  - A standard motion program to move the co-ordinate system
>> axes must
>>> also be implemented
>>>  - If motor resolution and offset parameters need to be
>> incorporated,
>>> they should be defined in the variables P1xx and P3xx
>> respectively (xx
>>> represents the axis number)
>>> 
>>>> How to access other values (analog and binary IO) on the PMAC?
>>> 
>>> These are accessed directly through the asynOctet port.
>> Unfortunately,
>>> it seems that streamDevice and asynMotor drivers conflict
>> and end up in
>>> a deadlock, so currently we use asynRecord and scalc to do
>> the parsing.
>>> We suspect that if we change asynMotor to use FIFO's for the status
>>> callbacks (like Mark modified all the standard asyn types to do last
>>> year) then the deadlock will go away, but we haven't checked this.
>>> 
>>> My corrected example fo Richard Pastrick for a 4 axis PMAC
>> you should
>>> do:
>>> 
>>>  Configure the standard Ethernet asynIPPort
>>> drvAsynIPPortConfigure("pmac1E", "172.23.86.84:1025", 0, 0, 0)
>>> 
>>> # Create the interpose layer on this port to properly
>> handle the PMAC
>>> protocol
>>> pmacAsynIPPortConfigure("pmac1E", 0)
>>>  
>>> # Create a pmacAsynMotor driver connected tto this port
>>> pmacAsynMotorCreate("pmac1E", 0, 0, 4)
>>>  
>>> # Setup the asynMotor layer (note the last parameter has to
>> be one more
>>> than the number of axes you specified in pmacAsynMotorCreate).
>>> # Note the new asynPort name.
>>> # There will be a warning at this stage about not being
>> able to create
>>> axis 0 - you should ignore this.
>>> drvAsynMotorConfigure("pmac1", "pmacAsynMotor", 0, 5)
>>> 
>>> Cheers,
>>> 
>>> Nick Rees
>>> Principal Software Engineer           Phone: +44 (0)1235-778430
>>> Diamond Light Source                  Fax:   +44 (0)1235-446713
>>> 
>>>> -----Original Message-----
>>>> From: [email protected]
>>>> [mailto:[email protected]] On Behalf Of Dirk Zimoch
>>>> Sent: 13 January 2009 09:19
>>>> To: tech-talk
>>>> Subject: PMAC IP and motor records
>>>> 
>>>> Hi all,
>>>> 
>>>> I am trying to set up a few motors on a PMAC system with
>>>> ethernet connection. I
>>>> have never worked with PMAC before and need some help.
>>>> 
>>>> I tried the tpmac package but I do not understand completely
>>>> what I have to
>>>> write in the startup script and how set up the motor records.
>>>> I need access to
>>>> 13 motors with the numbers 1,2,3,4,5,7,8,9,10,11,17,18,19.
>>>> 
>>>> Can someone send me an example startup script and an example
>>>> motor record, please?
>>>> 
>>>> So far, I guessed from various bits of documentation:
>>>> 
>>>> drvAsynIPPortConfigure pmac xx.xx.xx.xx:1025
>>>> pmacAsynIPPortConfigure pmac 0
>>>> pmacAsynMotorCreate pmac 0 0 19
>>>> drvAsynMotorConfigure pmacmotor pmacAsynMotor 0 20
>>>> 
>>>> After pmacAsynMotorCreate, I get error messages like these:
>>>> 
>>>> Creating PMAC motor driver on port pmac, address 0: card:
>> 0, naxes: 19
>>>> 2009/01/13 10:06:18.004 pmac read pmacFlush failed -
>>>> thisRead=0, eomReason=0,
>>>> status=1
>>>> 2009/01/13 10:06:18.666 pmac read pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:18.882 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:19.182 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:25.801 Read/write error to
>>>> PMAC card 0, axis 9
>>>> command I900=1. Status=1, Error=192.6.94.5:1025 timeout:
>>>> Resource temporarily
>>>> unavailable
>>>> 2009/01/13 10:06:26.117 pmac read pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:26.317 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:26.910 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:27.127 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:27.427 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:34.050 Read/write error to
>>>> PMAC card 0, axis
>>>> 14 command I1400=1. Status=1, Error=192.6.94.5:1025
>> timeout: Resource
>>>> temporarily unavailable
>>>> 2009/01/13 10:06:34.367 pmac read pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:34.567 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:36.050 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:36.270
>>>> drvPmacGetAxisInitialStatus: not all
>>>> status values returned
>>>> 2009/01/13 10:06:42.269 pmac read pmacFlush failed -
>>>> thisRead=0, eomReason=0,
>>>> status=1
>>>> 2009/01/13 10:06:42.370 pmac read pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:42.570 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:42.870 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:43.270 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:43.770 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:50.523 pmac read
>> pmacFlush failed -
>>>> thisRead=0, eomReason=0, status=1
>>>> 2009/01/13 10:06:50.624 pmac read pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:50.824 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:51.124 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:51.526 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:52.028 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:52.751 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:53.452 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:54.252 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:55.153 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:56.153 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:57.153 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:58.153 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:06:59.153 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:07:05.694 pmac read
>> pmacFlush failed -
>>>> thisRead=0, eomReason=0, status=1
>>>> 2009/01/13 10:07:05.794 pmac read pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:07:05.994 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:07:06.294 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:07:06.694 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:07:07.194 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:07:07.794 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:07:08.494 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=02009/01/13 10:07:09.294 pmac read
>>>> pmacReadReady failed
>>>> status=1,retval=0
>>>> 
>>>> With only drvAsynIPPortConfigure and pmacAsynIPPortConfigure,
>>>> I can get access
>>>> to the asynOctet layer and get responses to strings like
>>>> "M9", but only
>>>> sometimes. Often, stopping the ioc brings the PMAC in a state
>>>> where it does not
>>>> respond any more. Only a power cycle of the PMAC help. Any
>>>> idea what is wrong?
>>>> 
>>>> Some more questions:
>>>> Can the motor record read the encoder values from PMAC?
>>>> How can I use programs (homing an scanning procedures) on the PMAC?
>>>> How to access other values (analog and binary IO) on the PMAC?
>>>> 
>>>> Thanks in advance for any help
>>>> Dirk
>>>> 
>>>> -- 
>>>> Dr. Dirk Zimoch
>>>> Paul Scherrer Institut, WBGB/006
>>>> 5232 Villigen PSI, Switzerland
>>>> Phone +41 56 310 5182
>>>> 
>>>> 
>>> <DIV><FONT size="1" color="gray">This e-mail and any
>> attachments may contain confidential, copyright and or
>> privileged material, and are for the use of the intended
>> addressee only. If you are not the intended addressee or an
>> authorised recipient of the addressee please notify us of
>> receipt by returning the e-mail and do not use, copy, retain,
>> distribute or disclose the information in or attached to the e-mail.
>>> Any opinions expressed within this e-mail are those of the
>> individual and not necessarily of Diamond Light Source Ltd.
>>> Diamond Light Source Ltd. cannot guarantee that this e-mail
>> or any attachments are free from viruses and we cannot accept
>> liability for any damage which you may sustain as a result of
>> software viruses which may be transmitted in or with the message.
>>> Diamond Light Source Limited (company no. 4375679).
>> Registered in England and Wales with its registered office at
>> Diamond House, Harwell Science and Innovation Campus, Didcot,
>> Oxfordshire, OX11 0DE, United Kingdom
>>> </FONT></DIV> 
>> 
>> -- 
>> Dr. Dirk Zimoch
>> Paul Scherrer Institut, WBGB/006
>> 5232 Villigen PSI, Switzerland
>> Phone +41 56 310 5182
>> 
> <DIV><FONT size="1" color="gray">This e-mail and any attachments may contain
> confidential, copyright and or privileged material, and are for the use of the
> intended addressee only. If you are not the intended addressee or an
> authorised recipient of the addressee please notify us of receipt by returning
> the e-mail and do not use, copy, retain, distribute or disclose the
> information in or attached to the e-mail.
> Any opinions expressed within this e-mail are those of the individual and not
> necessarily of Diamond Light Source Ltd.
> Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments
> are free from viruses and we cannot accept liability for any damage which you
> may sustain as a result of software viruses which may be transmitted in or
> with the message.
> Diamond Light Source Limited (company no. 4375679). Registered in England and
> Wales with its registered office at Diamond House, Harwell Science and
> Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
> </FONT></DIV> 

-- 
+-------------------------------------------------+
Dr. Krzysztof Lazarski
Structural Biology Center, Beamline Software Development Coordinator
Argonne National Laboratory
9700 South Cass Avenue, Building 435 D002
Argonne, IL 60439-4830
ph: 630-252-3855, fax: 630-252-0564
[email protected]
www.sbc.anl.gov
 +-------------------------------------------------+
-- 




References:
RE: PMAC IP and motor records Rees, NP (Nick)

Navigate by Date:
Prev: RE: stop all motors Mark Rivers
Next: 答复: MAXvSetup is an undefined symbol 汪启胜
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: PMAC IP and motor records Rees, NP (Nick)
Next: Re: PMAC IP and motor records Dirk Zimoch
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 31 Jan 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·