Experimental Physics and
Industrial Control System

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):

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