RE: Force one record to run before all others

[Mark Rivers <rivers@cars.uchicago.edu>]

Hi Kathryn,

 

I think it was just coincidence that your Init.db worked.  It has to do with the order in which iocInit processes records with PINI=YES.  It processes all records of a given record type first, then the next record type, etc.  Your ADDRESS record type is ao.  But I don’t think there is any guarantee of the order in which different record types are processed, so there is no guarantee your ao record will process first.

 

PINI does obey PHAS.  But that would be quite a bit of work, since you would need to set PHAS for the ADDRESS record to 0 and PHAS for all other records to something higher.

 

I think an easier solution is to not use a record for this task at all.  You can just add these lines to your st.cmd file after creating the drvAsynSerialPort

 

asynOctetConnect portName deviceName

asynOctetWrite deviceName “myString”

 

portName is the name you gave to the drvAsynSerialPort

deviceName is a name you give to this device for the iocsh

myString is the string you need to send to the device to set its address

 

It’s not very pretty, but it is less work than having to set PHAS on a lot of records.

 

Mark

 

 

From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of kathryn.baker@stfc.ac.uk
Sent: Thursday, April 14, 2016 10:44 AM
To: tech-talk@aps.anl.gov
Subject: Force one record to run before all others

 

Hi all,

 

I have just written an Asyn driver for the Lambda TDK Genesys power supply, and I got it working after realising that before I can get it to do anything with comms I have to address it properly. This is RS232 comms, but for some reason these PSUs seem to demand that the first command I send it when trying to interact with it is an “ADR” command with its RS485 address. I have managed to get it to work, by having one tiny db (let’s call it Init.db) file as follows:

 

record (ao, "$(P)ADDRESS"){

field(DTYP, "stream")

field(OUT, "@TDK_Lambda_Genesys.proto address $(PORT)")

field(VAL, "$(ADR)")

field(PINI, "YES")

}

 

This is then loaded with the subsection of the st.cmd along with the Main db file as follows:

 

dbLoadRecords("db/Init.db", "P=$(IOCNAME), PORT=L0, ADR=10")

dbLoadRecords("db/Main.db", "P=$(IOCNAME), PORT=L0")

 

This does seem to ensure that the address is set before any of the other records are actioned, with the few PINI Yes and Scan records connecting. However, this doesn’t seem quite right, I’m not even sure that it is meant to work the way it seems to be. I did try having the record in my main db file, I think before any other interactions with the device, although not at the top of the file, and it didn’t seem to work. There is a chance I wasn’t where I thought in the file as this was being tested on a production system, so was a little more hurried and I’m now trying to tidy the code up to be production ready, so the answer of put it at the top of the file might be the solution. A colleague suggested checking to see if PINI respected the PHAS field, but I can’t find this information easily in the on line manuals, and I’m not sure I want to dissect the code to check this out, when someone here might have the answer available easily. The manuals tell me that linking records is a better option than using PHAS, and that PINI is run before the normal scan tasks, which doesn’t exactly answer my question.

 

So, the simple version of the question:

Does PINI respect the PHAS field?

 

Alternatively:

Is there a tidier solution than my one above?

 

Regards,

Kathryn