Experimental Physics and
| |||||||||||||||||
|
Shepherd, EL (Emma) wrote: Hi all, Thanks, Emma, for pointing this out. The sseq record uses standard EPICS links, but it does have a problem with PINI, when any of its links are to PV's in a different IOC, and there's a looseness about the way it initializes itself that I'd like to find a good way to fix. The sseq record needs to know the type (string or numeric) of the PV's it's linking to, in order to do its job. (Its job is to be a seq record that correctly handles strings, as well as numbers). If the sseq record doesn't know the data type of a linked PV, it doesn't do anything with the corresponding link. If the linked PV is in a different IOC, the sseq record cannot discover the PV's data type until after EPICS' interruptAccept (because no communication outside the IOC can happen until after that time). But PINI processing occurs before interruptAccept. So, PINI cannot ever work for links outside the IOC. (This should be true for all record types.) But you have CP links, and they will cause the record to process again, after interruptAccept, when the sseq record can, at least in principle, be ready for processing. I suspect that the record simply hasn't gotten around to finding out the data type by the time the CP-initiated processing occurs. I haven't verified this, but it seems plausible, because the sseq record gets data types by checking periodically (at 2 Hz) to see if dbGetLinkDBFtype() returns a valid field type. If the command to process comes in the ~.5 second after interruptAccept, and before the sseq record's periodic link check has succeeded, then the sseq record will not do the right thing. It also seems plausible that this timing problem could be systematically different on different operating systems. One way to fix the problem would be to have the record postpone link processing until after the linked PV's data type is known. The sseq record does all of its real work in callback routines (as does the seq record), so this would not hold up other records in the same task. But if the linked-to PV doesn't exist, then processing will be postponed indefinitely, so some limit is needed. I'm not sure if this is the best way to solve the problem, but it certainly seems like an improvement over the current code. -- Tim Mooney ([email protected]) (630)252-5417 Beamline Controls & Data Acquisition Group Advanced Photon Source, Argonne National Lab.
| ||||||||||||||||
ANJ, 02 Sep 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |