Re: Processing a record a in loop

[David Michel <dmichel76@googlemail.com>]

Thanks Bob, I'm aware of being able to change the scan rate this way. But longer scan rate is not really desirable. The typical task performed by the device is only a couple of seconds, so long scan rate for status updates would be close to useless.

David

---
Dr. David Michel
Address: 8 Viking Drive, Didcot, OX11 9RD, Oxfordshire
Mobile: 0789 670 98 01 - Home: 0123 581 46 93

On 3 September 2014 14:26, Dalesio, Leo <dalesio@bnl.gov> wrote:

If you need a longer scan rate - you can modify menu.dbd. I think that the instructions in the Application Developer's Guide covers this.
Bob

________________________________________
From: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on behalf of Mark Rivers [rivers@cars.uchicago.edu]
Sent: Wednesday, September 03, 2014 8:08 AM
To: David Michel; EPICS mailing list
Subject: RE: Processing a record a in loop

What is the maximum/typical time between when you send a query and receive a response?

You should be able to set the timeout to a value just longer than the maximum and then you can process the record with any fixed rate (1 seconds, 10 seconds, etc.).  The record will be busy (PACT=1) if the next scan interval happens before the reply from the previous one.  So it will not keep sending query messages, it will wait for a reply before proceeding.

What does your protocol file look like?  Is it a single query per response, etc.?

Mark

________________________________
From: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on behalf of David Michel [dmichel76@googlemail.com]
Sent: Wednesday, September 03, 2014 6:02 AM
To: EPICS mailing list
Subject: Processing a record a in loop


Hi All,

I'm using StreamDevice to talk to a custom device that doesn't support I/O interrupt so one has to keep sending commands to it to get status information.

Problem is that after a while (~ couple of hours), the device's buffer fills up and doesn't reply anymore. Increasing the ReplyTimeOut improves things slightly, but the problem still eventually occurs.

One potential solution would be to send the next command only once the previous one has returned in a loop (instead of using a set frequency).

Making the record FWD link to itself doesn't seem to do it... I started something using purely database trickery with a FANOUT record set with a fixed SCAN field and disabling it depending on whether the streamdevice record has finished processing or not... but it's getting messy

Is there an elegant way of doing this?

David