Experimental Physics and Industrial Control System
Ah, I see.
It would seem to me that this is a problem on the IOC side. Since if I
were to open up an IOC (that does not have the record HELLO:WORLD) and
type: dbpf HELLO:WORLD 5, I get the result PV 'HELLO:WORLD' not found. I
get the same result if I put the command before iocInit and start it up.
If HELLO:WORLD is actually a record, then dbpf HELLO:WORLD 5 before
iocInit crashes the IOC as we found. So during initialisation, if the
record hasn't been defined, or isn't 'ready', I would expect a PV not
found error from the IOC.
Alternatively, it could be take as dbpf is an illegal command to execute
before an iocInit, so it should be blocked/discarded from execution until
iocInit is done, returning an 'Illegal Command' error, or perhaps 'Command
xxx not found', as you get if you typed 'fpbd'. Both seem like IOC things
to me, but I digress.
On the issue at hand I don't see why I actually need an @init on the IDN
(I'm coming from a modifying code POV) since I poll it periodically now,
so removing that portion may be the simplest solution. I don't need to
know the IDN immediately, but I'm using it as a device standard command to
determine if I have a device connected, to throttle error messages, and
unnecessary network traffic, and IOC processing on devices that are turned
off. So running the IDN now or 10 seconds from now is somewhat
inconsequential because I don't really really care about the IDN itself so
to speak, more that I get one. The medium is the message to get all
McLuhan about it.
I would like to try the code modification of StreamCore.cc but that is
impractical in my current setup since the devices are being used so my
changes and tests have to be minimally invasive. I'll verify that
removing the @init as suggested for this function works and it sounds like
it will now I know the problem. Thanks so much for your help in looking
at this!
Cheers
James Larsson, P.Eng.
Control Systems Engineer
Triumf
>> a) Disable error handlers during @init. This is the easy way out.
>
> In StreamCore.cc method finishProtocol(ProtocolResult status)
> find the line
> if (runningHandler)
> and replace it with
> if (runningHandler || flags & InitRun)
>
> Then @writetimeout will not be called during @init, only later during
> periodic processing. But at least it will not crash.
>
> Maybe it is better not to use @init for this purpose but instead set
> field(PINI, "YES") in the record. @init was meant to read start values
> for output records because this needs a different protocol than normal
> processing.
>
> Dirk
>
>
> On 20.10.2017 11:39, Dirk Zimoch wrote:
>> Hello James,
>>
>> I could reproduce your problem with an Agilent E5810A Lan/GPIB gateway
>> and no device connected.
>>
>> The crash happens only when @writetimeout is triggered during @init and
>> executes dbpf. If one of the three prerequisites is not fulfilled, it
>> does not crash.
>>
>> Thus I guessed calling dbpf before iocInit finishes is the actual
>> problem. I checked that theory by simply adding the following line to
>> the startup script before iocInit:
>> dbpf HEBT:SCOPE1:ALIVE.A 1
>> It crashes.
>>
>> Thus the crash is not directly related to StreamDevice but to the fact
>> that dbpf is called on a not yet fully initialized database.
>>
>> I need to investigate how I can fix the problem. I have two options in
>> mind:
>> a) Disable error handlers during @init. This is the easy way out.
>> b) Run @init later. At the moment, it is run during init_record. Other
>> records may not have been initialized at this time. Maybe I can move
>> @init to a later time using initHooks.
>>
>> Dirk
>>
>>
>> On 20.10.2017 10:52, Dirk Zimoch wrote:
>>> Hi James,
>>>
>>> How is your GPIB device connected? Do you have a GPIB card or do you
>>> use
>>> a LAN-GPIB box (which model?) or does the device itself have a vxi11
>>> (GPIP over TCP) interface? In your mail I could not see how the asyn
>>> port is created. Do you use vxi11Configure?
>>>
>>> If you use a LAN-GPIB box, is the box running when the device is
>>> offline?
>>>
>>> Dirk
>>>
>>> BTW: When I replied on your first tech-talk mail on Oct 6, I got an
>>> error from your mail server: "<[email protected]>... Account disabled
>>> 05/Oct/2017"
>>> Seems to be fixed by now.
>>>
>>> Dirk
>>>
>>>
>>> On 19.10.2017 21:02, [email protected] wrote:
>>>> Hey there,
>>>>
>>>> Thanks for taking a look. The theory and practice I use the ASYN /
>>>> StreamDevice for is as follows. I use the an IDN record and function
>>>> to
>>>> query the device name, once every 10 seconds. In an Agilent WFG for
>>>> example. I have a separate periodic scan record that queries/sets the
>>>> device qualities.
>>>>
>>>> In the IDN portion of the proto file I execute a 'dbpf SOMERECORD 1'
>>>> and a
>>>> reply timeout exception of 'dbpf SOMERECORD 0'. It acts like a ping.
>>>> I
>>>> then use that bit in epics to drive the DISV / DISA / SDIS, of a
>>>> common
>>>> scan record.
>>>>
>>>> So if my Agilent WFG is turned off, then I stop trying to read/write
>>>> the
>>>> device qualities. But the IDN still checks. So if someone comes and
>>>> turns
>>>> the WFG on, epics starts reading and writing the qualities again.
>>>>
>>>> It's nice because it cleans up unnecessary (and polled typically)
>>>> network
>>>> traffic as well limits the number of error messages generated, and
>>>> lastly
>>>> stops an IOC from processing things unnecessarily.
>>>>
>>>> I tried this with GPIB devices, but I don't get exception code called
>>>> in
>>>> the proto file.
>>>>
>>>> Here is the record text that is relevant, I can send you attached
>>>> complete
>>>> ones if you like. The ALIVE record referenced below in the proto is a
>>>> simple calc record.
>>>>
>>>> [ the record .... ]
>>>> record(stringin,"HEBT:SCOPE1:IDN") {
>>>> field(DESC,"string input record")
>>>> field(SCAN,"10 second")
>>>> field(PINI,"YES")
>>>> field(PHAS,"0")
>>>> field(EVNT,"0")
>>>> field(DTYP,"stream")
>>>> field(DISV,"1")
>>>> field(SDIS,"0.000000000000000e+00")
>>>> field(DISS,"NO_ALARM")
>>>> field(PRIO,"LOW")
>>>> field(FLNK,"0.000000000000000e+00")
>>>> field(VAL,"string")
>>>> field(INP,"@tektds8000.proto IDN(HEBT:SCOPE1) GPIB0 10")
>>>> field(SIOL,"0.000000000000000e+00")
>>>> field(SIML,"0.000000000000000e+00")
>>>> field(SIMS,"NO_ALARM")
>>>> }
>>>>
>>>> [ the proto that fails to call the exception exec.... ]
>>>> IDN {
>>>>
>>>> InTerminator = LF;
>>>> @init {
>>>> out "HEADER OFF";
>>>> out "*IDN?";
>>>> # in "%s %s";
>>>> in "%64c";
>>>> }
>>>> out "*IDN?";
>>>> # in "%s %s";
>>>> in "%64c";
>>>>
>>>> # Added by James Larsson Oct. 5 2017 to throttle ASYN Error
>>>> Messages
>>>> exec "dbpf \$1:ALIVE.A 0";
>>>> @replytimeout
>>>> {
>>>> exec "dbpf \$1:ALIVE.A 1 ";
>>>> }
>>>> }
>>>>
>>>> [ the proto that crashes the IOC (just a @writetimeout delta).... ]
>>>> IDN {
>>>>
>>>> InTerminator = LF;
>>>> @init {
>>>> out "HEADER OFF";
>>>> out "*IDN?";
>>>> # in "%s %s";
>>>> in "%64c";
>>>> }
>>>> out "*IDN?";
>>>> # in "%s %s";
>>>> in "%64c";
>>>>
>>>> # Added by James Larsson Oct. 5 2017 to throttle ASYN Error
>>>> Messages
>>>> exec "dbpf \$1:ALIVE.A 0";
>>>> @writetimeout
>>>> {
>>>> exec "dbpf \$1:ALIVE.A 1 ";
>>>> }
>>>> }
>>>>
>>>>
>>>> [The script portion that configures the GPIB device: and the '.....'
>>>> are mine
>>>> .....]
>>>> asynSetOption("GPIB0",10,0x0c,0)
>>>> .....
>>>> asynSetTraceIOMask(GPIB0,10,0x0005)
>>>> asynSetTraceMask (GPIB0,10,0x001f)
>>>> .....
>>>> dbLoadRecords("asynRecord.db","P=HEBT:SCOPE1:,R=ASYN,PORT=GPIB0,ADDR=2,IMAX=0,OMAX=0")
>>>>
>>>>
>>>> ....
>>>> asynSetTraceMask (GPIB0,10,0x0000)
>>>> asynSetTraceIOMask(GPIB0,10,0x0000)
>>>>
>>>>
>>>> Cheers and Thanks again!
>>>>
>>>> James Larsson, P.Eng.
>>>> Triumf Control Systems Engineer
>>>>
>>>>
>>>>> Hello James,
>>>>>
>>>>> I am back from ICALEPCS, thus I can start debugging your StreamDevice
>>>>> problem.
>>>>>
>>>>> In order to reproduce your problem, I need some more information from
>>>>> you.
>>>>>
>>>>> Please send me:
>>>>> * The part of your startup script where you configure the GPIB device
>>>>> * The record that causes the crash
>>>>> * The protocol file used by this record.
>>>>>
>>>>> Best regards,
>>>>> Dirk
>>>>>
>>>>> On 06.10.2017 17:40, [email protected] wrote:
>>>>>> Hey hey!
>>>>>>
>>>>>> I have a device on my Linux IOC, using Asyn GPIB. The device works
>>>>>> on
>>>>>> the
>>>>>> IOC and, connected with EDM - is controllable.
>>>>>>
>>>>>> When the device is turned off I get an error message: asynError in
>>>>>> write:
>>>>>> GPIB0 writeGpib failed ENOL 2: No listeners
>>>>>>
>>>>>> The function in the proto file uses exception @replytimeout, but
>>>>>> that
>>>>>> never executes, which I would expect (I queried a device, it's not
>>>>>> there,
>>>>>> I should have a timeout). This works on TCP/IP devices, just not
>>>>>> GPIB.
>>>>>>
>>>>>> Does anyone have any thoughts, or hacks, or updates on getting GPIB
>>>>>> exceptions to run the proto file exception commands?
>>>>>>
>>>>>> Also when I try using the @writetimeout exception to more closely
>>>>>> mimic
>>>>>> the error message, the IOC crashes on boot, not even an IOC command
>>>>>> prompt, which looks like a separate problem, any help on that would
>>>>>> also
>>>>>> be appreciated. Error message is:
>>>>>>
>>>>>> A call to 'assert(dbLockIsInitialized)'
>>>>>> by thread 'cbLow' failed in ../dbLock.c line 239.
>>>>>> EPICS Release EPICS R3.14.11 $R3-14-11$ $2009/08/28 18:47:36$.
>>>>>> Local time is 2017-10-06 08:13:40.495885987 PDT
>>>>>> Please E-mail this message to the author or to [email protected]
>>>>>> Calling epicsThreadSuspendSelf()
>>>>>> Thread cbLow (0x9a12518) suspended
>>>>>>
>>>>>>
>>>>>> Cheers
>>>>>> James Larsson
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
>
>
- References:
- Asyn GPIB proto file exception @writetimeout jlarsson
- Re: Asyn GPIB proto file exception @writetimeout Dirk Zimoch
- Re: Asyn GPIB proto file exception @writetimeout Dirk Zimoch
- Navigate by Date:
- Prev:
Re: Asyn GPIB proto file exception @writetimeout Dirk Zimoch
- Next:
s7plc more than one 240-byte PDU Paul Sichta
- 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:
Re: Asyn GPIB proto file exception @writetimeout Dirk Zimoch
- Next:
Writing PVs from an amalgamated structure Iain Marcuson
- 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