RE: Asyn + Streamdevice: Gamma Vacuum Digtial QPC, missmatch after some time

[Abdalla Ahmad via Tech-talk <tech-talk at aps.anl.gov>]

Protocol looks fine, very similar to ours. Another thing to look for is trying updating the device’s firmware, we faced a similar issue years ago with our Gamma QPC model and the solution was to update all devices’ firmware. In more details, the issue was a LOT of input mismatch exception. For example, the IOC requests a pressure reading and it gets a voltage reading in return, therefore an exception occurs resulting in an INVALID alarm severity.

 

Best Regards,

Abdalla.

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Marco Filho via Tech-talk
Sent: Monday, October 14, 2024 1:00 PM
To: Ralph Lange <ralph.lange at gmx.de>; tech-talk at aps.anl.gov
Subject: Re: Asyn + Streamdevice: Gamma Vacuum Digtial QPC, missmatch after some time

 

Last time we had something similar adding this:

@replytimeout { disconnect; wait 1000; connect 1000;}

To the protocol solved everything. It was a suggestion from someone, I think Mark.

Cheers :)

 

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Ralph Lange via Tech-talk <tech-talk at aps.anl.gov>
Sent: 14 October 2024 11:53:14
To: EPICS Tech Talk
Subject: Re: Asyn + Streamdevice: Gamma Vacuum Digtial QPC, missmatch after some time

 

(Without looking at your protocols...)

 

That out-of-sync behavior often happens when the device takes an unusually long time to reply once in a while. (E.g., a small controller that has to do something at higher priority for a while.)

 

The IOC times out and sends the next request, then the device sends the reply to the last request, which the IOC doesn't like. The IOC sends the next request, the device answers with the reply for the previous request, and so on...

 

Try increasing your timeouts, so that the IOC waits even in the cases where the device takes a break. Analyze your log timestamps. Are specific commands taking longer? Increase the timeout for those. I have also seen devices taking a nap after specific commands complete successfully - in those cases, "wait;" instructions in the protocol can keep StreamDevice from sending the next command immediately.

 

Good luck!
~Ralph