Hi Josh,
StreamDevice cannot do this "double encoding" at the moment. I have seen this request several times but do not have a
solution yet. One may implement an asynInterpose layer which converts between the string
"A1 61 00 00 00 05 DC 02 58 00 11 00 0D"
and the byte sequence
0xA1 0x61 0x00 0x00 0x00 0x05 0xDC 0x02 0x58 0x00 0x11 0x00 0x0D
Then StreamDevice can work on the byte sequence and can convert between the two byte sequence 0x05 0xDC and the integer
0x05dc=1500 and scale it to 15.00.
But first converting between 15.00 and 0x05 0xDC and then again to "05 DC" is beyond what StreamDevice can do alone.
Dirk
On Wed, 2021-11-10 at 16:20 -0500, Josh Fiddler via Tech-talk wrote:
> Hi EPICS mavens!
>
> I'm having a lot of fun building IOCs left and right.
>
> Here are some important details:
>
> I've got a HV power supply to charge up a system that comms over RS485.
> We send 13 bytes worth of data to the unit, including 2 bytes for the terminator.
> byte are
> 1 for address,
> 2 for command
> 2 used as header in certain commands: to hold status bytes in some, and is null in others
> 2 when we want to set a voltage
> 2 when we want to set the ramping current
> 2 for checksum
> 2 for terminator
>
> To pass a voltage, it must first be in tens of kV, sensitive to 0.1 kV. This value is multiplied by 100 then can be
> converted to hex. Current is similar, but is not scaled (x1)
>
> The checksum is the sum of the bits in the binary representation of the first 9 bytes. When I send the request, I must
> include this value. It is to ensure the message is composed of characters, according to the docs (which are very, very
> minimal).
>
> So, an example command to set the device to 15kV, with 600mA current is:
>
> A1 61 00 00 00 05 DC 02 58 00 11 00 0D
> where 05 DC represents 15kV (hex(15 * 100))
> and 02 58 represents 600mA (hex(600))
> and 00 11 represents checksum on A1 61 00 00 00 05 DC 02 58
> The checksum is computed by summing the individual bits in the binary of each value:
> 0b10100001', '0b1100001', '0b0', '0b0', '0b0', '0b101', '0b11011100', '0b10', '0b1011000'
> means 3+3+0+0+0+2+5+1+3=17 or 0x11 in hex.
>
> When we receive responses from the PS, it has the same structure as the request. The second 'Command' bytes is
> modified to 0x0A. The rest of the bytes are unique to the request.
>
> We can request the 'parameters' that are currently set by calling
>
> A1 63 00 00 00 00 00 00 00 00 07 00 0D where the checksum is 0x0007
> since A1->3, 63->4 and 7 in hex is 0x07.
>
> The response would contain the same first 2 bytes, with the 3rd now 0A to show is a response. In the parameter
> response, the 4th and 5th bytes represent the system state when each is converted to a binary representation, and each
> bit indicates some status.
>
> The ask:
>
> How can I extract this information and use it? Should I use record redirection to put the values and formatters?
>
> Could someone point me in the right direction?
>
> Thanks for reading.
>
> I also have another question here that I could use some help with
> Search: "StreamDevice checksum Methods"
- Replies:
- Re: StreamDevice response parsing and redirection Zimoch Dirk (PSI) via Tech-talk
- References:
- StreamDevice response parsing and redirection Josh Fiddler via Tech-talk
- Navigate by Date:
- Prev:
StreamDevice response parsing and redirection Josh Fiddler via Tech-talk
- Next:
Re: StreamDevice response parsing and redirection Zimoch Dirk (PSI) via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
<2021>
2022
2023
2024
- Navigate by Thread:
- Prev:
StreamDevice response parsing and redirection Josh Fiddler via Tech-talk
- Next:
Re: StreamDevice response parsing and redirection Zimoch Dirk (PSI) via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
<2021>
2022
2023
2024
|