Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Fri, 13 Dec 2013 00:14:15 +0000

Hi Peter,

> I had this nagging suspicion that I should indeed be basing my record on motor.db, but was confused
> from the motorR6-8 README file saying that serial devices needed asyn4-2.  Live and learn I guess.

Your confusion is understandable.  There are actually 2 layers in the motor software that use asyn.

1) The interface between the motor driver and message based interfaces like RS-232, GPIB, and TCP/IP.  The motor drivers always use asyn for this layer, even the old Model 1 drivers.

2) The interface between motor record device support and the motor driver.  Only Model 2 and Model 3 drivers use asyn in this layer.

> I changed the PM304Config(0, "test-se1-1", 1) line from PM304Config(1, "test-se1-1", 1), since 
> I assumed from the "#C0 S0" syntax that if I only have one card, then it must be card 0.  
> In this case, the IOC seg faults immediately after boot.

The correct command is card 0, as you did.

These are the command in my startup script:
##############################
# PM304 driver setup parameters:
#     (1) maximum # of controllers,
#     (2) motor task polling rate (min=1Hz, max=60Hz)
PM304Setup(1, 10)
# PM304 driver configuration parameters:
#     (1) controller
#     (2) asyn port
#     (3) MAX axes
# Example:
#   PM304Config(0, "serial1", 1)
PM304Config(0, "serial9", 1)
##############################

So now we need to figure out why it is segfaulting for you.

Your startup script has these lines:

drvAsynIPPortConfigure("test-se1-1", "172.16.0.108:5300") # Add these lines for asynTrace debugging
asynSetTraceIOMask("test-se1-1",0,2)
asynSetTraceMask("test-se1-1",0,9)

The last line is turning on ASYN_TRACEIO_DRIVER for the TCP driver.  So you should see messages for every write and read operation to the device.  Do you see any such I/O before it crashes?  You could change the last line to:

asynSetTraceMask("test-se1-1",0,255)

to turn on all possible messages.

See if you get any messages before it seg faults.

You should also run gdb to figure out where it is crashing.  Here's how to do that:

- Enable core dumps.  With the csh this is done with

limit core 1000000

With bash it is

ulimit -c 1000000

Now run your application so it seqfaults.  You will get a core file, core.XXXXX, where XXXXX is a number.

Now run gdb on your application with that core file:

gdb PATH_TO_YOUR_APPLICATION core.XXXXX

When you get the gdb prompt type the command 

backtrace

That should show what function was executing when it crashed.

Here is something else to do.  Load your application, but comment out the line to load the motor database.  At the IOC prompt type this command

dbior "drvPM304",10

That should give you a report like the following:

Driver: drvPM304
    PM304 controller 0, id: Mclennan Servo Supplies Ltd  PM304  V6.17 

Mark

________________________________________
From: Peter Linardakis [[email protected]]
Sent: Thursday, December 12, 2013 5:39 PM
To: Mark Rivers; [email protected]; [email protected]
Subject: RE: Mclennan PM600 motor controller

Hi Mark

I had this nagging suspicion that I should indeed be basing my record on motor.db, but was confused from the motorR6-8 README file saying that serial devices needed asyn4-2.  Live and learn I guess.

However, I still am unable to get it to work.  The full record database is:

        record(motor, "test:motor") {
          field(DTYP, "Mclennan PM304")
          field(OUT, "#C0 S0 @")
          field(RRES, "1.0")
          field(PREC, "0")
          field(TWV, "10")
          field(VELO, "50")
        }

And the relevant part of the st.cmd file is

        ...
        # Test SE (test-se1)
        drvAsynIPPortConfigure("test-se1-1", "172.16.0.108:5300")
        # Test for Mclennan PM600 stepper motor controller
        # PM304Setup(controller count, poll rate (Hz))
        # PM304Config(card being configured, asyn port name,  number of axes)
        PM304Setup(1,5)
        PM304Config(0, "test-se1-1", 1)
        ...

I changed the PM304Config(0, "test-se1-1", 1) line from PM304Config(1, "test-se1-1", 1), since I assumed from the "#C0 S0" syntax that if I only have one card, then it must be card 0.  In this case, the IOC seg faults immediately after boot.

If I leave it as PM304Config(1, "test-se1-1", 1), then the IOC runs, but you get the

        Illegal field value PV: test:motor motor_init_record_com(): card does not exist!

line at start up.

Naturally, I'm lost.

Cheers
Peter

-----Original Message-----
From: Mark Rivers [mailto:[email protected]]
Sent: Friday, 13 December 2013 2:11 AM
To: [email protected]; Peter Linardakis; [email protected]
Subject: RE: Mclennan PM600 motor controller

> The DTYP should be asynMotor - all new style motors drivers have the
> same DTYP since they share the same device support.

No, I don't think so.  Peter is using the McLennan support in the synApps motor module, which is an old-style Model 1 driver, not a newer Model 2 or Model 3 driver using the asyn interfaces.

He originally had both the incorrect DTYP and OUT link specification for the motor.  My first post had him correct the DTYP, but he still had a problem with OUT.  I hope it will work once he corrects OUT to have the proper VMEIO syntax, e.g.

    field(OUT,"#C0 S0 @")

Mark

________________________________________

From: [email protected] [[email protected]] on behalf of [email protected] [[email protected]]
Sent: Thursday, December 12, 2013 3:15 AM
To: [email protected]; [email protected]
Subject: RE: Mclennan PM600 motor controller

Hi Peter,

The DTYP should be asynMotor - all new style motors drivers have the same DTYP since they share the same device support.

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 Peter Linardakis
Sent: 12 December 2013 04:25
To: Mark Rivers; [email protected]
Subject: RE: Mclennan PM600 motor controller

Hi Mark

Thank you very much for the assistance.  As you may have gathered, EPICS is not a full time task for me, so assistance is much appreciated.

Indeed I am using the Mclennan driver.  Your direction allowed me to progress greatly, but I am at another stumbling block.  I have managed to communicate and move the motor through an asynRecord device by simply connecting to port "test-se-1" and address "0".  The .OEOS field must be set to "\r\n" for the commands to actually be acted upon (otherwise it just reads back the input command).  However, when I try connecting through a motor record, I get the trace below on IOC start up:

...
# Test SE (test-se1)
drvAsynIPPortConfigure("test-se1-1", "172.16.0.108:5300") # Add these lines for asynTrace debugging
asynSetTraceIOMask("test-se1-1",0,2)
asynSetTraceMask("test-se1-1",0,9)
# Test for Mclennan PM600 stepper motor controller # PM304Setup(controller count, poll rate (Hz)) # PM304Config(card being configured, asyn port name,  number of axes)
PM304Setup(1,5)
PM304Config(1, "test-se1-1", 1)
## Load record instances
dbLoadRecords("../../db/sum.db","INST=pitest")
Can't set "test:buncher:motor.OUT" to "@asyn(test-se1-1, 0)"
Error at or before ")" in file "../../db/sum.db" line 34
iocInit()
Starting iocInit
############################################################################
## EPICS R3.14.12.3 $Date: Mon 2012-12-17 14:11:47 -0600$ ## EPICS Base built Aug 13 2013 ############################################################################
Illegal field value PV: test:buncher:motor motor_init_record_com(): card does not exist!

I'm aware the last line means there is a communication issue, but I have no idea about the "Can't set to @asyn" line.  I assume from asyn_motor.db that that is correct format for that field.  In any case, I have tried a few different ways, but no dice.

The full db record is:

# Test record for Mclennan PM600 Stepper Motor driver record(motor, "test:buncher:motor") {
  field(DTYP, "Mclennan PM304")
  field(OUT, "@asyn(test-se1-1, 0)")
  field(RRES, "1.0")
  field(PREC, "0")
  field(TWV, "10")
  field(VELO, "50")
}

Regards
Peter

-----Original Message-----
From: Mark Rivers [mailto:[email protected]]
Sent: Wednesday, 11 December 2013 4:04 PM
To: Peter Linardakis; [email protected]
Subject: RE: Mclennan PM600 motor controller

Hi Peter,

I assume you are using the McLennan driver that is included in synApps/motor/motorApp/MclennanSrc/?

If so, then the problem is the DTYP field in the motor record in your database. You specified

    record(motor, "test:buncher:motor")  {
        field(DTYP, "asynMotor")

DTYP "asynMotor" is only for Model 2 and 3 motor drivers, where the communication between the motor record device support and the driver uses the standard asyn interfaces.

The Mclennan driver is an old Model 1 driver.  This is the correct definition of DTYP for the McLennan motors.

    record(motor, "test:buncher:motor") {
        field(DTYP, "Mclennan PM304")

You can find that required string ("Mclennan PM304") by looking in the DBD file your application is including:

        pitest_DBD += devMclennanMotor.dbd

That file, motorApp/MclennanSrc/devMclennanMotor.dbd, contains the following line:

        device(motor,VME_IO,devPM304,"Mclennan PM304")

That tells you what the device support string name is.

Cheers,
Mark

--
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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System