Experimental Physics and
Industrial Control System

"Leblanc, Gregory via Tech-talk" <tech-talk at aps.anl.gov> · Tue, 27 Jun 2023 16:37:47 +0000

Hi Dirk,

Some comments inline below.

> -----Original Message-----
> From: Zimoch Dirk <dirk.zimoch at psi.ch>
> Sent: Tuesday, June 27, 2023 10:37 AM
> To: Leblanc, Gregory <leblanc at ohio.edu>; tech-talk at aps.anl.gov
> Subject: [External] Re: Strangeness in ai/mbbiDirect with StreamDevice on PINI
> 
> Hello Greg,
> 
> I notice that all your set protocols don't expect any reply. Is that so that the
> device does not send replies? Unfortunately, I cannot find the manual online.

The device generally doesn't send replies to any commands, except when it gets confused or doesn't recognize the command.  Here's a snippet of my correspondence with it via minicom:

L
S1H
408000
SD1H?
PCU 50-300/EARG
lkajds?
PCU 50-300/EARG
STB
DA 0,002000
N
F

Input sent by me: L, S1H, SD1H?, lkajds?, STB, DA 0,002000, N, F

Any string that ends with ? that it doesn't recognize it replies to with the ID of the unit. 

I put the manual online, because I couldn't find it anywhere: https://github.com/leblancOUAL/PCU_50-300/blob/ac0839a285339d5109eef6ba26f08dc1021e1716/Manual_PCU_400V_2019-05-24%20V1.7.pdf

> The point is that if the device sends a reply and StreamDevice does not consume
> it in the set protocol, then it may accidentally receive it processing the next get
> protocol. This would be a race condition between the device sending the reply
> and StreamDevice discarding old input when starting the next protocol.

Hmm, this triggered another thought.  On PDF page 24 (manual page 22) it says:

7.3.2. End of Message
The end of all sent messages is marked by the carriage return character (ASCII 13).
The end of all received messages is marked with the line feed character (ASCII 10)
and carriage return character (ASCII 13).

And when I turn in debugging in st.cmd I see:

2023/06/27 10:31:29.269 /dev/ttyUSB0 write 5
AD 0\n
2023/06/27 10:31:29.287 /dev/ttyUSB0 read 8
000000\n\r

Which says that I'm sending \n and getting back \n\r.  I changed my st.cmd to have these lines:

asynOctetSetOutputEos("USB0", 0, "\r")
asynOctetSetInputEos("USB0", 0, "\n\r")

but I still don't get the StatusRegister properly populated if the other two records have PINI yes.  Updating the record once the IOC is running, either via a periodic scan or dbtr, will get the right value in that record, but I don't know why it doesn't get populated on startup.  
     Greg 

[snip]

--
Gregory Leblanc
Accelerator Engineer
Edwards Accelerator Lab - Ohio University
123 University Terrace
Athens, OH 45701 USA
leblanc at ohio.edu
M: (401) 52-OUAL1 or (401) 526-8251

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System