RE: Packed Data Message Formats With Fixed-Length Strings

[Iain Marcuson <Iain.Marcuson@sydorinstruments.com>]

Thanks.  My trouble was reading the input into a waveform record.  I discovered I could do that with the %r format in Stream Device.  Now in CSS BOY, I can display the waveform as a string and see the results.

Iain.

> -----Original Message-----
> From: Mooney, Tim M. [mailto:mooney@aps.anl.gov]
> Sent: Tuesday, November 08, 2016 12:12 PM
> To: Iain Marcuson <Iain.Marcuson@sydorinstruments.com>; tech-
> talk@aps.anl.gov
> Subject: RE: Packed Data Message Formats With Fixed-Length Strings
> 
> Hi Iain,
> 
> I think I would do this with an aSub record: read the input into a waveform
> record; configure an aSub record input to be an array of char, and point the
> input link at the waveform record's VAL field; and write an aSub routine to
> parse it.
> 
> Tim Mooney (mooney@aps.anl.gov) (630)252-5417 Beamline Controls Group
> (www.aps.anl.gov) Advanced Photon Source, Argonne National Lab
> 
> 
> ________________________________________
> From: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on
> behalf of Iain Marcuson [Iain.Marcuson@sydorinstruments.com]
> Sent: Tuesday, November 08, 2016 10:46 AM
> To: tech-talk@aps.anl.gov
> Subject: Packed Data Message Formats With Fixed-Length Strings
> 
> I am writing EPICS code to interface with a custom device.  The device
> protocol is fixed-length messages.  I can read and write the message
> parameters with Stream Device, and have done so successfully except for
> the fixed-length string, which I have had to bypass in assorted ways.
> 
> The output command message has the Python struct format "ii128s12i".  The
> input message has the Python struct format "128s12ii".  The "12i" refers to 12
> parameters, passed or returned.
> 
> My two questions are:
> 
> 1) How can I parse the fixed-length string?  The normal string-handling
> routines fail either because of terminator characters in the string or because
> the string is two long.
> 2) I handle the parameters by having a PV for each parameter, and a
> separate "group" of PVs for each command.  Is this best practice?
> 
> Thank you,
> 
> Iain Marcuson.