Experimental Physics and
Industrial Control System
| 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: VAL field of PV in ASYN driver |
| From: | "Vishnu Patel" <[email protected]> |
| To: | "Vikram Bhagat" <[email protected]> |
| Cc: | "[email protected]" <[email protected]> |
| Date: | 23 Jun 2013 17:50:14 -0000 |
Is your problem solved? If not.
Just clarify the Mark's answer.
As i understand when you are putting value in VAL field and it is not reflacted at actual output.
You might have your write reason in your asynInt32, asynUInt32 or asynFloat64 write() method.
In asyn record initialisation it read() method returns asynSuccess the VAL field is overwrite by value read.
you can refer initialisation of Longout record in devAsynUInt32Digital.c initLo() Method.
To resolve
You have to write code in such away that the same asyn reason return asynError in read() method for first time and then behave normally and then return asynSuccess.
Vishnu
From: Mark Rivers <[email protected]>
Sent: Fri, 14 Jun 2013 21:56:54
To: "'Andrew Johnson'" <[email protected]>, "[email protected]" <[email protected]>, Vikram Bhagat <[email protected]>
Subject: Re: VAL field of PV in ASYN driver
I think there may be another issue here.
Standard asyn device support for output records does the following in the init_record routine:
- Tries to read the current value from the driver via pasynInt32SyncIO->read(), pasynFloat64SyncIO->read(), etc.
- If the driver returns asynSuccess then the device support puts the value read from the driver into the VAL field of the output record. This will replace the value in your DB file.
- If the driver does not return asynSuccess then the device support does not change the VAL field and the DB value will be used.
These steps are designed for "bumpless reboots", so the output record agrees with the device.
After these steps, if there is a value from autoSave then that value will replace the VAL field from either the DB file or the driver.
So you may need to modify your driver so that its read() routine does not return success on an initial when presumably the value is invalid.
Note that if your driver is derived from asynPortDriver then the base class implementation will returns asynError on the read() function if your driver has never called setInt32Param, etc. for that parameter. It returns asynSuccess on the read() function if your driver has called setInt32Param, etc. for that parameter.
Mark
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Andrew Johnson
Sent: Friday, June 14, 2013 10:43 AM
To: [email protected]; Vikram Bhagat
Subject: Re: VAL field of PV in ASYN driver
Hi Vikram,
On 2013-06-14 Vikram Bhagat wrote:
> as i understand of i defiend VAL field to some value in DB file then it
> sould be written on output.
> I have develop my own driver to write value on serial port using asyn
> driver. and it is working fine.
> if i write some value . it is output on port.
>
> But if i write VAL field in DB file. it is not writting that value to the
> output
To write the record value to the port you have to arrange for the record to
be processed. You can do this in several different ways, but depending on
your port driver not all of them will work. The simplest is to set the PINI
field of the record to YES, which will cause it to be processed automatically
at IOC Initialization time. However if your Asyn port has not connected up
to the device in time that might not work, and in that case a better solution
might be to put a command in your startup script to put the value at some
time after the call to iocInit, like this:
...
iocInit()
epicsThreadSleep(2)
dbpf TEST:VAL 7
The epicsThreadSleep command might not be necessary in some cases, or you
might have to make the sleep delay longer according to how long it takes for
your particular Asyn port to connect.
- Andrew
--
It is difficult to get a man to understand something, when his salary
depends upon his not understanding it. -- Upton Sinclair
Get your own FREE website and domain with business email solutions, click here
- Navigate by Date:
- Prev: Re: Problem in errlogRemoveListener Andrew Johnson
- Next: Re: Problem in errlogRemoveListener Benjamin Franksen
- 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
- Navigate by Thread:
- Prev: feller release 0.4 Benjamin Franksen
- Next: PyEpics speed Jeremy Iken
- 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
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·