Re: streamdevice I/O Intr

[William Kirstaedter via Tech-talk <tech-talk@aps.anl.gov>]

unfortunately I dont see any errors. but the lock theory sounds reasonable...

I also tried specifying "wait 100" in the streamdevice protocol, but this didnt slow down the input.

William Kirstaedter (PP&B)
Fritz-Haber-Institut der MPG
Faradayweg 4-6
14195 Berlin
Tel: 030 8413 5405
Mail: kirstaedter@fhi-berlin.mpg.de

Am 29.11.2018 um 17:29 schrieb Mark Rivers:

Hi William,

 

I have a suspicion what the problem is.  If streamDevice is locking the port with pasynManager->lockPort() and then reading the device in a tight loop the port may always be locked.  Your bo record will result in a call to pasynManager->queueRequest, but that request will never be serviced because the port is busy.  We have seen this problem in the past with drivers that call lockPort(). In response to those problems I added another function to asynDriver a long time ago.  It is pasynManager->queueLockPort().  It locks the port, but via the request queue, so other requests get a chance to run.

 

Are you seeing any error messages on the IOC console?  If the problem is what I describe then I would expect to see queueRequest timeout error messages.

 

I will look at the streamDevice code to see if this is indeed the likely problem.

 

Mark

 

 

From: tech-talk-bounces@aps.anl.gov <tech-talk-bounces@aps.anl.gov> On Behalf Of William Kirstaedter via Tech-talk
Sent: Thursday, November 29, 2018 10:01 AM
To: Michael Westfall <mwestfal@gemini.edu>
Cc: tech-talk@aps.anl.gov Talk <tech-talk@aps.anl.gov>
Subject: Re: streamdevice I/O Intr

 

Yes, I am issuing

caput CRYVISIL:TC09:Toggle 0

--

when the IOC starts and the device doesnt already send data, I am able to toggle with

caput CRYVISIL:TC09:Toggle 1

which results in "STM\r" showing up in the asyn TraceMask, followed by the stream.

When simulating the process "by hand" with telnet, it's no problem sending STM and ETM.

William Kirstaedter (PP&B)

Fritz-Haber-Institut der MPG

Faradayweg 4-6

14195 Berlin

Tel: 030 8413 5405

Mail: kirstaedter@fhi-berlin.mpg.de

Am 29.11.2018 um 16:10 schrieb Michael Westfall via Tech-talk:

How are you commanding the bo record? 
Are you sure its value is being commanded to zero when you want to stop reading?

Did you try something like, 'caput xxx:Toggle 0' ?

 

On Thu, Nov 29, 2018 at 10:21 AM William Kirstaedter via Tech-talk <tech-talk@aps.anl.gov> wrote:

Hi Dirk,

thanks for the quick answer.

I have set

field(PRIO, "HIGH")

but this doesnt seem to do anything?

I have asynTraceMask on aswell but I dont see the "ETM" command ever
pass through...

William Kirstaedter (PP&B)
Fritz-Haber-Institut der MPG
Faradayweg 4-6
14195 Berlin
Tel: 030 8413 5405
Mail: kirstaedter@fhi-berlin.mpg.de

Am 29.11.2018 um 13:37 schrieb Dirk Zimoch via Tech-talk:
> Hi William,
>
> Have you tried to give the output record a high priority?
>
> Dirk
>
> On 29.11.2018 13:27, William Kirstaedter via Tech-talk wrote:
>> I'm sorry to send this again but my first mail got soft-rejected
>> because I wasnt a subscriber.
>>
>> William Kirstaedter (PP&B)
>> Fritz-Haber-Institut der MPG
>> Faradayweg 4-6
>> 14195 Berlin
>> Tel: 030 8413 5405
>> Mail: kirstaedter@fhi-berlin.mpg.de
>>
>> Am 29.11.2018 um 11:34 schrieb William Kirstaedter:
>>> Hi,
>>>
>>> I have a small problem with a fast Device, maybe somebody already
>>> had this problem and can help out? :)
>>>
>>> It runs via I/O Intr.
>>> I am able to start the reporting, but I cant stop it. It seems that
>>> the stop command doesnt get through....
>>> could it be that somehow the communication is blocked by the fast
>>> input? how could I fix that?
>>>
>>> Its really simple to control:
>>> You send "STM\r", it starts reporting every 18ms
>>> "tmp,<float>,<float>\r"
>>> You send "ETM\r", it stops doing that, terminating communication
>>> with "txx\r".
>>>
>>> all ASCII formatted.
>>>
>>> my records:
>>>
>>> tc.db file:
>>>
>>> record(bo, "$(P):$(R):Toggle"){
>>>    field(DESC, "Toggle Reading")
>>>    field(DTYP, "stream")
>>>    field(OUT, "@tc.proto toggle $(BUS)")
>>>    field(ZNAM, "ETM")
>>>    field(ONAM, "STM")
>>>    field(VAL, "0")
>>> }
>>>
>>> record(ai, "$(P):$(R):Temperature") {
>>>   field(DESC, "Temperature")
>>>   field (DTYP, "stream")
>>>   field (INP, "@tc.proto read_K $(BUS)")
>>>   field (SCAN, "I/O Intr")
>>>   field(EGU, "K")
>>> }
>>>
>>> record(ai, "$(P):$(R):ThermoVoltage"){
>>>   field(DESC, "TC Thermovoltage")
>>>   field(DTYP, "stream")
>>>   field(INP, "@tc.proto read_nV $(BUS)")
>>>   field(SCAN, "I/O Intr")
>>>   field(EGU, "nV")
>>> }
>>>
>>> tc.proto file:
>>>
>>> Terminator = CR;
>>> ExtraInput = Ignore;
>>>
>>>
>>> toggle {
>>>         out "%{ETM|STM}";
>>>         in "txx";
>>> };
>>>
>>> read_K {
>>>         in "tmp,%f,%*f";
>>> };
>>>
>>> read_nV {
>>>         in "tmp,%*f,%f";
>>> };
>>>
>>
>> ----------------------------------------------------------------------
>> Das FHI verarbeitet, speichert und loescht Daten im Rahmen seiner
>> Geschaeftstaetigkeit gemaess der Datenschutz-Grundverordnung (DSGVO)
>> [General Data Protection Regulation (GDPR)] der Europaeischen Union.
>>

----------------------------------------------------------------------
Das FHI verarbeitet, speichert und loescht Daten im Rahmen seiner
Geschaeftstaetigkeit gemaess der Datenschutz-Grundverordnung (DSGVO)
[General Data Protection Regulation (GDPR)] der Europaeischen Union.

--

Mike Westfall

Control Systems Software Engineer

----------------------------------------------------------------------

Das FHI verarbeitet, speichert und loescht Daten im Rahmen seiner

Geschaeftstaetigkeit gemaess der Datenschutz-Grundverordnung (DSGVO)

[General Data Protection Regulation (GDPR)] der Europaeischen Union.

----------------------------------------------------------------------
Das FHI verarbeitet, speichert und loescht Daten im Rahmen seiner
Geschaeftstaetigkeit gemaess der Datenschutz-Grundverordnung (DSGVO)
[General Data Protection Regulation (GDPR)] der Europaeischen Union.