Re: StreamDevice Raw converter

[Henrique Silva via Tech-talk <tech-talk at aps.anl.gov>]

Hi,

I was investigating what could be this problem with the raw conversion for the waveform record, and I managed to identify what could be the problem.

After some changes in the protocol, streamDevice would still complain about not being able to convert from DBF_INT64 to anything (I tried all possible FTVL types, they all behave the same):

StreamCore.cc:1103: StreamCore::readCallback(LAB:SCP-02:Wfm1) input line: "C1:WF DAT1,#9000000040<f4><ff><0c><00><1d><00>"<00><1d><00><17><00><18><00><1e><00>$<00>"<00><18><00><0b><00><09><00><16><00>1<00>M<00>c<00>k<00>f<00>X<00>"
StreamCore.cc:1192: StreamCore::matchInput(LAB:SCP-02:Wfm1): format = "%*9d"
StreamCore.cc:1192: StreamCore::matchInput(LAB:SCP-02:Wfm1): format = "%02r"
StreamEpics.cc:1498: sevr=major readData LAB:SCP-02:Wfm1: can't convert from DBF_UINT64 to DBF_LONG

Looking at StreamDevice code,  specifically the readData function on devwaveformStream.c, I can see that it can handle conversion for most numerical format types, except DBF_INT64 and DBF_UINT64, which fall under the default case, giving a conversion error.

I then added a print before the conversion loop to check which was the received format type by this function and the result I got is that for raw conversion (%r) the type is "DBF_INT64" (or DBF_UINT64 if I use %02r format). As mentioned before, these are the only types that aren't handled by readData(), so that was the source of the error.

Checking deeper in the code, I can see that this type value is passed to readData() by the function Stream::matchValue() (StreamEpics.cc, line 1270). On this line, the dbfMapping array is used to convert the format type from the enum StreamFormatType to a dbfType, but the Raw LONG type was modified to be promoted to INT64 (commit 8000f41d on streamDevice).

If I change this mapping back to DBF_LONG, either by disabling INT64 support, or just hard-coding it back to LONG, then the waveform conversion works with no problems.

Did anyone have this problem before? I'm investigating which changes can be made to support the INT64 types, but if anyone has suggestions, that would speed this up a lot :)

Just for info, I'm using the current master branches on epics-base (R7.0.3.1), streamDevice and asyn.

Best regards,

Henrique Silva

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Henrique Silva via Tech-talk <tech-talk at aps.anl.gov>
Sent: Tuesday, February 11, 2020 4:11:55 PM
To: tech-talk at aps.anl.gov
Subject: StreamDevice Raw converter

 

Hi,

I'm trying to retrieve a waveform from an oscilloscope using StreamDevice, but I'm having some problems converting the binary data.

The scope sends the waveform raw data using the IEEE 488.2 definite length block format (a small ASCII header indicating how many bytes will be sent and right after that the binary data). For example, when it sends 3 16-bit points, the received message is:

C1:WF DAT1,#9000000006<BIN1><BIN1><BIN2><BIN2><BIN3><BIN3>

I have the following records:

record(waveform, "$(P)$(R)Wfm1")
{
    field(SCAN, "Passive")
    field(DTYP, "stream")
    field(FTVL, "SHORT")
    field(INP,  "@scope.proto read_wave_bin(C1, $(P)$(R)Wfm1ByteCount) $(PORT)")
    field(NELM, "50")
}

record(ai, "$(P)$(R)Wfm1ByteCount")
{
    field(DESC, "Waveform byte count channel 1")
}

And the following protocol function:

read_wave_bin {
    separator="";
    out "\$1:WF? DAT1";
    in "\$1:WF DAT1,#9%(\$2)9d%02r";
}

But when I process this waveform record, I get the following error:

sevr=major readData LAB:SCP-02:Wfm1: can't convert from DBF_INT64 to DBF_SHORT
2020/02/04 17:25:01.657852 WAVEPRO LAB:SCP-02:Wfm1: Input "%<b8>/<b8>4<b8>" does not match format "%02r"

I can see that the "Wfm1ByteCount" record is being set correctly, matching the "#9000000006" string, so the problem is only on the binary matching/conversion.

I've tried changing the waveform FTVL type to INT64, but it still complains about the type conversion ("can't convert from DBF_INT64 to DBF_INT64").

Does anyone know how to fix this problem?

Thanks in advance,

Henrique Silva