Re: StreamDevice communication problems

[Burkhard Kolb <b.kolb@gsi.de>]

Hi Tito,

the correct command would be

var streamDebug=1

Do I understand it right that you get the values for 8 channels with one read?

You would need to include these responses and sort them into different records by specifying

the record names in the protocol.

Burkhard

--

Dr. Burkhard Kolb
Tel +49 6159 712667

GSI Helmholtzzentrum für Schwerionenforschung GmbH

Planckstraße 1 | D-64291 Darmstadt | www.gsi.de

Gesellschaft mit beschränkter Haftung

Sitz der Gesellschaft: Darmstadt

Handelsregister: Amtsgericht Darmstadt, HRB 1528

Geschäftsführung: Professor Dr. Dr. h.c. mult. Horst Stöcker, Peter Hassenbach

Vorsitzende des Aufsichtsrates: Dr. Beatrix Vierkorn-Rudolph

Stellvertreter: Ministerialdirigent Dr. Rolf Bernhardt

Am 28.08.2013 um 14:38 schrieb Tito Körner:

Hi everyone,

Thanks for the replies.

@ Mark Rivers: This FLNK field is just a relict from my very first attempts. This FLNK should keep the record going even though there is a mismatch. Using the SCAN field it is pretty unnecessary I admit, but it shouldn't be responsible for my problem - however I deleted the line now.

@ Fabian S.: I tried to enter "streamDebug=1" at the epics console but I got the message "Command streamDebug=1 not found".

I don't really thinkg the output really appears in the input. When I take a look at the packages sent via telnet it looks like the out commands from the read_volt record are sent in between the out and in command from the set_volt record.

@ Dirk Zimoch: I'm using asyn4-21.

As I see it my problem is that the device is not locked by a protocole once the first out command is sent (or may I just don't understand locking correctly) and that the response to the out command of read_volt is not unique for a specific channel (like it for example would be when the level and channel number would be part of the output - then I could parse these values.
I can't change the strings coming from the box unfortunatelly. So is there a away to actually check how and if a protocol really locks a device? Or is there the possibility to somehow manually lock the box - with a field for example.

I'm also thinking of using the DISA und DISV field. My basic idea would be to stop the read_volt record via first writing to the DISA/DISV field in the read_volt record so it no longer processes, then set the voltage and restart the read_volt record afterwards. I guess it may possible somehow.

Tito

2013/8/27 Dirk Zimoch <dirk.zimoch@psi.ch>

Hello Tito,

Which asyn version are you using?

Dirk

On 26.08.2013 17:33, Tito Körner wrote:

Hello,

I am using Streamdevice (
http://epics.web.psi.ch/software/streamdevice/doc/index.html) to control a
high voltage box. The box has 5 levels with 8 channels each, so it controls
40 channels. The boxes receive commands and send output via telnet.
Currently I only have two records - one for reading one for writing values.
To access all channels I use a template. The problem is whenever I give one
channel the command to change the value - the entire traffic gets mixed up:

My .db looks like this:

record (stringout, "$(P):BOX:$(BOXNO):$(LEVELNO):$(CHANNELNO):set_volt")
{
     field (DTYP, "stream")
     field (OUT,  "@$(PROTO) set_voltage($(LEVELNO),$(CHANNELNO))
termBox$(BOXNO)")
}

record (ai, "$(P):BOX:$(BOXNO):$(LEVELNO):$(CHANNELNO):read_volt")
{
     field (DTYP, "stream")
     field (INP, "@$(PROTO) read_voltage($(LEVELNO),$(CHANNELNO))
termBox$(BOXNO)")
     field (SCAN, "1 second")
     field (FLNK, "$(P):BOX:$(BOXNO):$(LEVELNO):$(CHANNELNO):read_volt")
     field (PACT, "")
     field (STAT, "")
     field (SEVR, "")
     field (VAL, "")
}

My protocol file looks like this:

terminator = CR LF;
LockTimeout = 10000;

read_voltage {
     out "read_adc floats_csv \$1 \$2";
     in "%*d.%*d.%*d %*d:%*d:%*d,%f";
     @mismatch{out "read_adc floats_csv \$1 \$2";  in "%*d.%*d.%*d
%*d:%*d:%*d,%f";}
}

set_voltage {
     out "SetVpmF \$1 \$2 %s";
     in "DAC: \$1   CH: \$2   U: %*f  Uk: %*f";
     in "Nachregelung aktiv!";
     in "Messwert: %*f   DAC: \$1   CH: \$2   Value: %*f   korrigiert: %*f";
     in "Messwert: %*f   DAC: \$1   CH: \$2   Value: %*f   korrigiert: %*f";
     in "Messwert: %*f   DAC: \$1   CH: \$2   Value: %*f   korrigiert: %*f";
     in "Messwert: %*f   DAC: \$1   CH: \$2   Value: %*f   korrigiert: %*f";
     in "Messwert: %*f   DAC: \$1   CH: \$2   Value: %*f   korrigiert: %*f";
     in "Messwert: %*f   DAC: \$1   CH: \$2   Value: %*f   korrigiert: %*f";
     in "Messwert: %*f   DAC: \$1   CH: \$2   Value: %*f   korrigiert: %*f";
     in "Messwert: %*f   DAC: \$1   CH: \$2   Value: %*f   korrigiert: %*f";
     in "Messwert: %*f   DAC: \$1   CH: \$2   Value: %*f   korrigiert: %*f";
     in "Messwert: %*f   DAC: \$1   CH: \$2   Value: %*f   korrigiert: %*f";
}

I created a python script that prints all values to the terminal. As long
as only the read record is activ everything works out. But when I use
another terminal to set a voltage like: 'caput
CB:HV:BOX:19:0:0:1480:set_volt' the voltage values start to  'jump around'.
I monitored the network traffic with wireshark and saw this:

read_adc floats_csv 2 5

01.01.1900 04:23:55,1345.003

read_adc floats_csv 2 6

01.01.1900 04:23:55,1345.123

read_adc floats_csv 2 7

01.01.1900 04:23:55,1345.156

read_adc floats_csv 3 0

01.01.1900 04:23:56,1346.075

read_adc floats_csv 3 1

01.01.1900 04:23:56,1343.827

read_adc floats_csv 3 2

01.01.1900 04:23:56,1376.977

read_adc floats_csv 3 3

01.01.1900 04:23:56,1346.537

read_adc floats_csv 3 4

01.01.1900 04:23:56,1341.462

read_adc floats_csv 3 5

01.01.1900 04:23:56,1368.079

SetVpmF 0 0 1480

*read_adc floats_csv 3 6 *

DAC: 0   CH: 0   U: 1480.000  Uk: 1584.800
Nachregelung aktiv!
Messwert: 1479.545   DAC: 0   CH: 0   Value: 1480.350   korrigiert:
1585.165
Messwert: 1479.941   DAC: 0   CH: 0   Value: 1480.395   korrigiert:
1585.212
Messwert: 1479.935   DAC: 0   CH: 0   Value: 1480.445   korrigiert:
1585.264
Messwert: 1480.045   DAC: 0   CH: 0   Value: 1480.410   korrigiert:
1585.228
Messwert: 1480.046   DAC: 0   CH: 0   Value: 1480.375   korrigiert:
1585.191

Messwert: 1479.941   DAC: 0   CH: 0   Value: 1480.420   k*read_adc
floats_csv 3 6 *

orrigiert: 1585.238
Messwert: 1480.052   DAC: 0   CH: 0   Value: 1480.379   korrigiert:
1585.196
Messwert: 1479.963   DAC: 0   CH: 0   Value: 1480.408   korrigiert:
1585.226
Messwert: 1480.063   DAC: 0   CH: 0   Value: 1480.359   korrigiert:
1585.175
Messwert: 1479.963   DAC: 0   CH: 0   Value: 1480.388   korrigiert:
1585.205

read_adc floats_csv 3 7

01.01.1900 04:23:59,1344.063

read_adc floats_csv 4 0

01.01.1900 04:23:59,1344.070

read_adc floats_csv 4 1

01.01.1900 04:23:59,1346.169

read_adc floats_csv 4 2

01.01.1900 04:23:59,1357.607

read_adc floats_csv 0 0

01.01.1900 04:24:00,1352.217

read_adc floats_csv 0 1

01.01.1900 04:24:00,1340.962

As you can see (marked bold) in between the command 'SetVpmF 0 0 1480' and
the response from the box there are two out commands from the read_volt
record. The problem now is - the first response from the box after the
response to the set_voltage command is '01.01.1900 04:23:59,1344.06. This
is actually the voltage value belonging to the command 'read_adc floats_csv
3 6'. But because the read_volt record sent this command in between the
command and response of  the set_volt record, Epics 'thinks' this is the
value for 3 7. At the StreamDevice website it says that a protocols first
out command locks the device for exclusive access until the protocol is
finished. But here this does not seem to work because obviously the
read_volt record sends the out command of its protocol while the protocol
called in the set_volt record is active. I hope someone can help me to
figure out what's going wrong and how to fix it.

Regards,
Tito Koerner