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: EDM |
From: | Zenon Szalata <[email protected]> |
To: | Andrew Johnson <[email protected]> |
Cc: | "[email protected]" <[email protected]> |
Date: | Fri, 10 May 2013 12:14:29 -0700 |
Hi Andrew, On 05/10/13 11:08, Andrew Johnson wrote:
Hi Zenon, On 2013-05-10 Zenon Szalata wrote:The hardware registers are read/write. When the IOC starts, the register has some value previously set. After IOC init, I issue a series of dbpf commands, one for each register. These trigger processing a record that reads the register. After the register is read, the read value is put into the output record with NPP.The record you showed was Soft Channel though, was this what you're calling an an output record? I see that it does have a forward link.
Yes, it is a longout record, so I called it output.
These are Beckhoff bus terminal records which are a bit complicated to read from and especially to write to. To have it work correctly, I need to insert a 0.2 second delay between dbpf commands. I decided to use NPP because the output record, although it is soft channel, when processed will result in the value being written back to the register, which should be harmless, but I wanted to avoid it, because significantly more delay would be needed.Unfortunately for most record types doing a dbPut() to the VAL field without processing the record will *not* trigger a CA monitor for the field. If the VAL field is PP(TRUE) the code in dbPut() assumes that puts to the field will cause the record to be processed and that processing will trigger a monitor, so it doesn't do one itself to avoid sending an unnecessary double update. In your case though you're not processing the record, so EDM never gets sent an update even though subsequent caget or dbpr commands do show the new value.
I started this thread after observing that EDM was singling out one particular record and always the same one. Number of similar records were handled the same way and their values made it to the Text Controls. Also, relaunching the EDM was not enough to get the correct value. Just this morning I discovered that restarting the EDM program would get the correct value. I was strongly convinced and no longer am that closing a screen (one of many control by an EDM program) resulted in CA disconnect to all PVs referenced by that screen. I thought that just putting the screen in question in a debug mode and then back in execute, would also do CA disconnect/connect or at least the correct values would be obtained. This was not happening. Well, I am still confused by this whole thing.
If this is really the cause of my difficulty, I will think how to modify the records such that the target output record gets the value and gets processed and somehow writing back to the register will be suppressed. I was trying to avoid the extra complication.The SDIS link of the subsequent record might be useful here. - Andrew
Thanks Andrew, Zen