RE: Reading multiple parameters from an incoming message.

[Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>]

Hi Ji Li,

 

It would be cleaner to define the output terminator with asynOctetSetEos in your st.cmd.  Then you could delete this line from your protocol file:

 

OutTerminator = CR LF;

 

and this line from your st.cmd:

 

dbpf $(Sys){$(Dev)}ASYN.OEOS "\r\n"

 

You said

Ø  I included PollPeriod in my protocol file.

 

However, that line is commented out:

 

#PollPeriod = 500;

 

This alarm:

XF:28ID2-ES:1{Pump:1}ASYN.ERRS is showing "Overflow nread 40" with MAJOR(READ_ALARM).

 

is expected because you are using the ASCII input mode on the asyn record, which is limited to 40 characters, but the device sent more than 40.

 

I don’t understand the following.  Something sent the “status” command, I am assuming that was the RATE:RBV record?

 

epics> 2020/12/30 13:07:42.654 /dev/ttyUSB0 write 8

status\r\n

2020/12/30 13:07:42.681 /dev/ttyUSB0 read 48

50000000000 0 0 w...I.\n83333333330 0 0 i...I.\n::

=================

 

XF:28ID2-ES:1{Pump:1}ASYN.ERRS is showing "Overflow nread 40" with MAJOR(READ_ALARM).

XF:28ID2-ES:1{Pump:1}ASYN.TINP is showing "50000000000 0 0 w...I.\n83333333330 0 0" with MINOR(READ_ALARM).

XF:28ID2-ES:1{Pump:1-Ax:A}:RATE:RBV is shown INVALID(UDF_ALARM).

 

But then why did the response get read into the ASYN record?

 

Mark

 

From: Li, Ji <liji at bnl.gov>
Sent: Wednesday, December 30, 2020 2:11 PM
To: Mark Rivers <rivers at cars.uchicago.edu>
Cc: tech-talk at aps.anl.gov
Subject: 回复: Reading multiple parameters from an incoming message.

 

Hi Mark,

 

I put it on github:

 

https://github.com/solofrain/harvard

 

I loaded asynRecord.db in st.cmd.

 

dbLoadRecords("$(ASYN)/db/asynRecord.db", "P=$(Sys), R={$(Dev)}ASYN, PORT=$(Port), ADDR=0, OMAX=80, IMAX=80")

 

ASYN record is not included in database files.

 

Best,

 

-Ji Li

 

---

发件人: Mark Rivers <rivers at cars.uchicago.edu>
发送时间: 2020年12月30日 13:28
收件人: Li, Ji <liji at bnl.gov>
抄送: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
主题: RE: Reading multiple parameters from an incoming message.

 

Ø  XF:28ID2-ES:1{Pump:1}ASYN.ERRS is showing "Overflow nread 40" with MAJOR(READ_ALARM).

 

That looks like you have an asyn record in your database.  But none of the database files you have shared contain an asyn record.  It is hard to help without seeing the actual database file you are using.  Is it on Github?

 

Mark

 

 

 

From: Li, Ji <liji at bnl.gov>
Sent: Wednesday, December 30, 2020 12:13 PM
To: Mark Rivers <rivers at cars.uchicago.edu>
Cc: tech-talk at aps.anl.gov
Subject: 回复: Reading multiple parameters from an incoming message.

 

Hi Mark,

 

I included PollPeriod in my protocol file. Currently these PVs (FORCE, STATUS) look fine without alarms. But I still couldn't get RateA out of the incoming message after I had issued a "status" message.

 

=================

epics> 2020/12/30 13:07:42.654 /dev/ttyUSB0 write 8

status\r\n

2020/12/30 13:07:42.681 /dev/ttyUSB0 read 48

50000000000 0 0 w...I.\n83333333330 0 0 i...I.\n::

=================

 

XF:28ID2-ES:1{Pump:1}ASYN.ERRS is showing "Overflow nread 40" with MAJOR(READ_ALARM).

XF:28ID2-ES:1{Pump:1}ASYN.TINP is showing "50000000000 0 0 w...I.\n83333333330 0 0" with MINOR(READ_ALARM).

XF:28ID2-ES:1{Pump:1-Ax:A}:RATE:RBV is shown INVALID(UDF_ALARM).

 

Does that mean the last 8 bytes of the message got lost which caused streamdevice failed to read correctly?

 

Best,

 

-Ji Li

 

---

发件人: Mark Rivers <rivers at cars.uchicago.edu>
发送时间: 2020年12月30日 12:22
收件人: Li, Ji <liji at bnl.gov>
抄送: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
主题: RE: Reading multiple parameters from an incoming message.

 

Hi Ji Li,

 

Ø  The last two characters are the status of the two axes. Each of them can be anyone of the six characters (":", ">", "<", "*", "T", "?").

 

I understand.  I just looked at the protocol file I wrote for the Harvard PHD2000 pump.  It is in the synApps “ip” module.  It looks like the command/reply syntax is very similar to your pump.

 

That protocol file starts like this:

 

OutTerminator = "\r";

ExtraInput = Ignore;

ReplyTimeout = 3000;

PollPeriod = 500;

 

getString {

   out "\$1";

   in  "\n%[ A-Z]\r\n%*[><:/*^]";

}

 

setString {

   out "\$1 %s";

   in "\n%*[><:/*^]";

}

 

Note that I did not set an input terminator, but I did tell it what possible reply characters to expect for each command.  I set the ReplyTimeout to be 3000 ms, but the PollPeriod to 500 ms.  I believe this keeps StreamDevice from timing out, because it will poll before it times out.

 

You should try this approach.

 

Mark

 

 

From: Li, Ji <liji at bnl.gov>
Sent: Wednesday, December 30, 2020 10:23 AM
To: Mark Rivers <rivers at cars.uchicago.edu>
Cc: tech-talk at aps.anl.gov
Subject: 回复: Reading multiple parameters from an incoming message.

 

Hi Mark,

 

The last two characters are the status of the two axes. Each of them can be anyone of the six characters (":", ">", "<", "*", "T", "?").

 

===================

:    The pump is idle

>   The pump is infusing

<   The pump is withdrawing

*    The pump stalled

T   The target was reached

?   The pump status is unknown

===================

 

"::" means both axes are idle. If axis A is idle and axis B is infusing, they become ":>". These two characters are parsed by macro:

 

ax_status = "%(\$1{\$2-Ax:A}:STATUS){:|>|<|*|T|?}%(\$1{\$2-Ax:B}:STATUS){:|>|<|*|T|?}";

 

Best,

 

-Ji Li

 

---

发件人: Mark Rivers <rivers at cars.uchicago.edu>
发送时间: 2020年12月30日 11:08
收件人: Li, Ji <liji at bnl.gov>
抄送: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
主题: RE: Reading multiple parameters from an incoming message.

 

Hi Ji Li,

 

It appears to me from your output that the device always terminates its reply with the characters “::”.  Try setting the input terminator to “::”.

 

Mark

 

 

From: Li, Ji <liji at bnl.gov>
Sent: Wednesday, December 30, 2020 9:45 AM
To: Mark Rivers <rivers at cars.uchicago.edu>
Cc: tech-talk at aps.anl.gov
Subject: 回复: Reading multiple parameters from an incoming message.

 

Hi Mark,

 

I had the asyn traceError, traceODriver, traceIOEscape and streamError on. I tried both cases with InTerminator defined and undefined and set the force of axis A.

 

The PVs related to force of axis A:

• XF:28ID2-ES:1{Pump:1-Ax:A}:FORCE

• XF:28ID2-ES:1{Pump:1-Ax:A}:FORCE:RBV

They are defined as:

 

========================================

record(ao, "$(P){$(Q)-Ax:$(AX)}:$(CMD)") {

  field(DESC, "Axis $(AX) $(CMD)")

  field(DTYP, "stream")

  field(FLNK, "$(P){$(Q)-Ax:$(AX)}:$(CMD):RBV")

  field(OUT, "@pump33dds.proto setIntAx($(P), $(Q), $(AX), $(CMD)) $(PORT)")

  field(PREC, "0")

  field(EGU, "$(EGU)")

  field(DRVH, "100")

  field(DRVL, "0")

#  field(SDIS, "$(P){$(Q)-Ax:$(AX)}:DISABLE")

}

 

record(ai, "$(P){$(Q)-Ax:$(AX)}:$(CMD):RBV") {

  field(DESC, "Axis $(AX) $(CMD) readback")

  field(DTYP, "stream")

  field(INP, "@pump33dds.proto getIntEGUAx($(P), $(Q), $(AX), $(CMD), $(EGU)) $(PORT)")

  field(PREC, "0")

  field(EGU, "$(EGU)")

#  field(SDIS, "$(P){$(Q)-Ax:$(AX)}:DISABLE")

}

 

record(mbbi, "$(P){$(Q)-Ax:$(AX)}:$(CMD):RBV:EGU") {

  field(ZRVL, "0")

  field(ZRST, "$(EGU)")

  field(SDIS, "$(P){$(Q)-Ax:$(AX)}:DISABLE")

}

========================================

 

substituted as:

 

========================================

file "$(HARVARD)/db/pump33dds-ax-int.db"

{

pattern

{ AX    , CMD     , EGU }

{ "A"   , "FORCE" , "%" }

{ "B"   , "FORCE" , "%" }

{ "AB"  , "FORCE" , "%" }

}

========================================

Protocols used:

 

========================================

setIntAx {

        out "\$4 \$3 %d";

        in $ax_status;        in "%*s";

}

getIntEGUAx {

        out "\$4 \$3";

        in "\$3: %d%(\$1{\$2-Ax:\$3}:\$4:RBV:EGU){%}\n" $ax_status;

        @mismatch {

               in "\$3: %d%(\$1{\$2-Ax:A}:\$4:RBV:EGU){%|mm}\n\$3: %d%(\$1{\$2-Ax:B}:\$4:RBV:EGU){%|mm}\n" $ax_status;

        }

}

========================================

The PVs for the status of two axes:

 

========================================

• XF:28ID2-ES:1{Pump:1-Ax:A}:STATUS

• XF:28ID2-ES:1{Pump:1-Ax:B}:STATUS

defined as:

 

========================================

record(mbbi, "$(P){$(Q)-Ax:$(AX)}:STATUS") {

  field(DESC, "Pump Status")

  field(ZRVL, "0")

  field(ZRST, "Idle")

  field(ONVL, "1")

  field(ONST, "Infusing")

  field(TWVL, "2")

  field(TWST, "Withdrawing")

  field(THVL, "3")

  field(THST, "Stalled")

  field(FRVL, "4")

  field(FRST, "Target Reached")

  field(FVVL, "5")

  field(FVST, "Unknown")

}

========================================

 

With InTerminator on.

 

######################################################

Since the manual doesn't give what terminating character in the incoming message, I tried

• InTerminator=0x11  - from the pump support for Harvard PHD ULTRA by Diamond Light Source, which I expect to be similar.
• InTerminator=0x0d

Both of them procuded the same result.

 

========================================

2020/12/30 10:34:42.411 /dev/ttyUSB0 write 12

FORCE A 10\r\n

2020/12/30 10:34:42.432 /dev/ttyUSB0 read 2

::

2020/12/30 10:34:42.636009 L0 XF:28ID2-ES:1{Pump:1-Ax:A}:FORCE: Timeout after reading 2 bytes "::"

2020/12/30 10:34:42.636 /dev/ttyUSB0 write 9

FORCE A\r\n

2020/12/30 10:34:42.656 /dev/ttyUSB0 read 9

A: 10%\n::

2020/12/30 10:34:42.856032 L0 XF:28ID2-ES:1{Pump:1-Ax:A}:FORCE:RBV: Timeout after reading 9 bytes "A: 10%<0a>::"

========================================

 

The force of axis A was changed to 10 as checked on the pump.

Both XF:28ID2-ES:1{Pump:1-Ax:A}:FORCE and XF:28ID2-ES:1{Pump:1-Ax:A}:FORCE:RBV have value 10, and both are showing READ_ALARM.

XF:28ID2-ES:1{Pump:1-Ax:A}:STATUS and XF:28ID2-ES:1{Pump:1-Ax:B}:STATUS are not updated.

######################################################

 

With InTerminator off.

 

######################################################

 

Write 10 to the PV:

 

========================================

epics> 2020/12/30 10:26:21.765 /dev/ttyUSB0 write 12

FORCE A 10\r\n

2020/12/30 10:26:21.791 /dev/ttyUSB0 read 2

::

2020/12/30 10:26:21.993 /dev/ttyUSB0 write 9

FORCE A\r\n

2020/12/30 10:26:22.015 /dev/ttyUSB0 read 9

A: 10%\n::

========================================

 

The force of axis A was changed to 10 as checked on the pump.

Both XF:28ID2-ES:1{Pump:1-Ax:A}:FORCE and XF:28ID2-ES:1{Pump:1-Ax:A}:FORCE:RBV have value 10. No alarms shown.

XF:28ID2-ES:1{Pump:1-Ax:A}:STATUS and XF:28ID2-ES:1{Pump:1-Ax:B}:STATUS are in normal state. No alarms shown.

 

 

Best,

 

-Ji Li

 

---

发件人: Mark Rivers <rivers at cars.uchicago.edu>
发送时间: 2020年12月30日 8:51
收件人: Li, Ji <liji at bnl.gov>
抄送: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
主题: Re: Reading multiple parameters from an incoming message.

 

Hi Ji Li,


> The protocols without InTerminator work for me, at least I can set parameters and read them out from the pump.

> I think asyn returns as soon as the input message matches the expected pattern - for most of them, $ax_status, such as "::".


No, that is not possible.  asyn does not know anything about the expected pattern.  The way stream device and asyn work is that stream device does a "read" from the asyn driver.  If asyn is configured with noProcessEos=0 (the default) then the asyn read will return when any of the following occur:


- The specified terminator is found.  You have not specified a terminator in your protocol file, so this cannot be happening unless you specified a terminator in your startup script.

- The specified number of characters has been read.  It is possible that streamDevice is only asking for 1 character, so it may return because of this.

- The specified timeout has occurred.

- EndOfMessage has been received.  This is only for GPIB.


> There're alarms for those PVs, but I doubt they are related to InTerminator.


The UDF alarm means the record has not processed successfully, so the value is undefined.


You should enable asynTrace on the underlying asyn driver, and you should set streamDebug so you can see what stream is doing.


Mark




________________________________
From: Li, Ji <liji at bnl.gov>
Sent: Tuesday, December 29, 2020 9:14 PM
To: Mark Rivers
Cc: tech-talk at aps.anl.gov
Subject: 回复: Reading multiple parameters from an incoming message.

Happy New Year, Mark.

This problem is still on my table and to be solved.

============================

Your .db file passes 3 arguments to the protocol file, %(P), $(Q), $(CMD).  But in the protocol file I only see \$1 and \$2, not \$3.  Is this correct?


The first two parameters $(P) and $(Q) are common for all records, so I assigned values to them in global{} in the .substitutions file. The command sent out by this specific protocol is "status" which was hard coded it in the protocol (for others protocols the commands vary), so $(P) and $(Q) are sufficient for this record. I put $(CMD) in it as a dummy argument since I could not make empty substitution in the .substitutions file as loading

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

file "$(HARVARD)/db/pump33dds-ax-status-a.db"

{

pattern

}

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

throws errors.


But I think would be an good idea to make use of $(CMD) for disambiguation.

============================
You have commented out the line that defines the input terminator in the protocol file:

#InTerminator = 0x11;

How will asyn know when to return a string without a timeout if there is no terminator defined?


The returned messages from the pump don't have terminators. When InTerminator was defined, asyn would not return until timeout. The protocols without InTerminator work for me, at least I can set parameters and read them out from the pump. I think asyn returns as soon as the input message matches the expected pattern - for most of them, $ax_status, such as "::".

There're alarms for those PVs, but I doubt they are related to InTerminator.

 ============================

I think the protocol would be easier to read if you change this:

in "%d %*d %*d %*c%*c%*c%*c%*c%*c\n%*d %*d %*d %*c%*c%*c%*c%*c%*c\n" $ax_status;

to this:

in "%d %*d %*d %*6c\n%*d %*d %*d %*6c\n" $ax_status;


This looks much better. I updated the protocol.
============================

Best,

-Ji Li


________________________________
发件人: Mark Rivers <rivers at cars.uchicago.edu>
发送时间: 2020年12月29日 18:45
收件人: Li, Ji <liji at bnl.gov>
抄送: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
主题: RE: Reading multiple parameters from an incoming message.


Hi Ji Li,



Sorry for the delay in replying.  Maybe you have figured this out?



If not, I have some questions:



Your .db file passes 3 arguments to the protocol file, %(P), $(Q), $(CMD).  But in the protocol file I only see \$1 and \$2, not \$3.  Is this correct?



You have commented out the line that defines the input terminator in the protocol file:

#InTerminator = 0x11;



How will asyn know when to return a string without a timeout if there is no terminator defined?



I think the protocol would be easier to read if you change this:

in "%d %*d %*d %*c%*c%*c%*c%*c%*c\n%*d %*d %*d %*c%*c%*c%*c%*c%*c\n" $ax_status;



to this:

in "%d %*d %*d %*6c\n%*d %*d %*d %*6c\n" $ax_status;



Mark





From: Li, Ji <liji at bnl.gov>
Sent: Thursday, December 24, 2020 5:36 PM
To: Mark Rivers <rivers at cars.uchicago.edu>
Cc: tech-talk at aps.anl.gov
Subject: 回复: Reading multiple parameters from an incoming message.



Hi Mark,



I was referring to the PV for RATEA - $(P){$(Q)-Ax:A}:RATE:RBV.



Please see the attached files for the protocol, the database, the substitutions file, and the st.cmd. I only worked on Independent Condition to operate the two syringes separately. For better clarity I removed other protocols/databases definitions.



The .proto file contains the definition of this protocol and the referenced macro.



I have several .db files for different categories of information (rate/volume/time/...). The attached .db file defines the status PV - currently only RATEA. I expect implementation of other PVs that get values from this status message would be similar once I'm done with RATEA.





Best,



-Ji Li





________________________________

发件人: Mark Rivers <rivers at cars.uchicago.edu<mailto:rivers at cars.uchicago.edu>>
发送时间: 2020年12月24日 14:53
收件人: Li, Ji <liji at bnl.gov<mailto:liji at bnl.gov>>
抄送: tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov> <tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov>>
主题: Re: Reading multiple parameters from an incoming message.



Hi Ji Li,


Can you send the rest of the database and protocol files, or at least the Status record and the $ax_status definition.

> The PV was showing INVALID(UDF_ALARM). Since the IOC didn't throw errors, I suppose the message was parsed correctly. How could this alarm have been caused?

Which PV are you referring to?

Mark



________________________________
From: Tech-talk <tech-talk-bounces at aps.anl.gov<mailto:tech-talk-bounces at aps.anl.gov>> on behalf of Li, Ji via Tech-talk <tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov>>
Sent: Thursday, December 24, 2020 11:04 AM
To: tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov>
Subject: Reading multiple parameters from an incoming message.

Hi,

I'm working on an EPICS package for a Harvard Pump 33 DDS syringe pump using streamdevice protocols. I need to read several parameters from an incoming message that combines the status of two axes/syringes, which has the following format:

RATEA TIMEA VOLA STATUSA
RATEB TIMEB VOLB STATUSB

RATEA/B, TIMEA/B and VOLA/B are integers, and STATUSA/B are 6-character strings with each character indicating a specific status.

I'm trying to parse the message using multiple protocols and records. For RATEA, only grab the first integer:

Protocol:
=======================
getStatusRateAxA {
    out "status";
    in "%d %*d %*d %*c%*c%*c%*c%*c%*c\n%*d %*d %*d %*c%*c%*c%*c%*c%*c\n" $ax_status;
}
=======================

Record:
=======================
record(ai, "$(P){$(Q)-Ax:A}:RATE:RBV") {
  field(DESC, "Axis A rate readback")
  field(DTYP, "stream")
  field(INP, "@pump33dds.proto getStatusRateAxA($(P), $(Q), $(CMD)) $(PORT)")
  field(PREC, "0")
}
=======================

The .substitutions file referring to this record was loaded without errors. When I tried to retrieve status information, the IOC shell printed the following information without errors:

=======================
epics> 2020/12/24 11:29:06.797 /dev/ttyUSB0 write 8
status\r\n
2020/12/24 11:29:06.833 /dev/ttyUSB0 read 71
50000000000 0 22307784 w...I.\n83333333330 24723 2055394602192 i...I.\n::
=======================

"::" in the incoming message should be parsed by "$ax_status" in the protocol and it worked for other messages.

The PV was showing INVALID(UDF_ALARM). Since the IOC didn't throw errors, I suppose the message was parsed correctly. How could this alarm have been caused?

Best,

-Ji Li