EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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  <20212022  2023  2024  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  <20212022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: StreamDevice response parsing and redirection
From: "Zimoch Dirk \(PSI\) via Tech-talk" <tech-talk at aps.anl.gov>
To: "[email protected]" <[email protected]>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Thu, 11 Nov 2021 08:28:43 +0000
.. or isn't this the string "A1 61 00 00 00 05 DC 02 58 00 11 00 0D" but really only the byte squence?

In that case:
I do not have a bitsum yet. But if I had, it would look like:

terminator = 0x0d;
set_A_AND_I {
    out 0xa1 0x61 0x00 0x00 0x00 "%2r%(\$1:CURRENT)2r%<bitsum>";
    in  0xa1 0x0a 0x00 0x00 0x00 "%=2r%(\$1:CURRENT)=2r%<bitsum>";
}

I use redirection for the second value (current) while taking the first (voltage) from the active record. The reply is
checked for correctness with %= against the current settings. (I hope I understood this right.)



On Thu, 2021-11-11 at 08:13 +0000, Zimoch Dirk (PSI) via Tech-talk wrote:
> 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"

References:
StreamDevice response parsing and redirection Josh Fiddler via Tech-talk
Re: StreamDevice response parsing and redirection Zimoch Dirk (PSI) via Tech-talk

Navigate by Date:
Prev: Re: StreamDevice response parsing and redirection Zimoch Dirk (PSI) 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  <20212022  2023  2024 
Navigate by Thread:
Prev: Re: StreamDevice response parsing and redirection Zimoch Dirk (PSI) 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  <20212022  2023  2024 
ANJ, 11 Nov 2021 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·