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 2021 2022 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 2021 2022 2023 2024 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | RE: asynDriver - UDP server |
| From: | Joao Afonso via Tech-talk <[email protected]> |
| To: | Mark Rivers <[email protected]> |
| Cc: | "[email protected]" <[email protected]> |
| Date: | Wed, 9 Jan 2019 12:35:15 +0000 |
|
Thank you for the response Mark.
The states will not be more than ~20, so two mbbi records should be enough. Anyway, this should be a read-only record, so I am leaning to return the state as a string and use a simple stringin record. Upon reading more about it, it seems
to be the most straightforward solution.
There are 8 or 16 bits, depending on the parameter. The mbbiDirect record is almost what I need, but instead of an array of single chars, I would like an array of strings (with the names of flags that were set as '1'). I could just return a long string with all the strings concatenated, but I was just wondering if there was a more appropriate way of doing it.
Best regards, Joao
From: Mark Rivers [[email protected]]
Sent: 08 January 2019 18:26 To: Joao Afonso Cc: [email protected] Subject: RE: asynDriver - UDP server Ø However, mbbi is limited to 16 states, which is not enough. What is the best approach to overcome this?
How many states do you have? One option would be to use a few mbbi records, each one handling up to 16 states. The nice thing about mbbi records is that the XXVL fields can be any integer, so the first mbbi could be values 0-15, the second 16-31, etc. You driver could select which mbbi to use by either of 2 mechanisms:
- Have a different drvUser string for each record (CHOICES_0, CHOICES_1, etc.) - Make the driver have asynMultiDevice=true and then use the asyn “addr” field for the different records.
Ø Is there a record that can be used to aggregate all the 'bi' record values, or a way to read all of their values simultaneously?
There are mbboDirect and mbbiDirect records. I’m not sure if they do what you want.
How many bits are there? Again you might be able to use the asynMultiDevice and use the “addr” field to specify which bit this is.
Mark
From: Joao Afonso <[email protected]>
Hello Mark,
Thank you for the previous response. I was able to design an asyn driver that does the parsing of the UDP binary data, and unpacks it into multiple parameters that can be used by different records.
However, I am not sure of the best approach to display some of these parameters:
1) Enum values
Some of the parameters are enum values, for now defined as "asynParamInt32". Each value defines one of N possible states. From what I understood, a straightforward solution would be to use a mbbi record, to match each value to a string.
However, mbbi is limited to 16 states, which is not enough. What is the best approach to overcome this?
One possible solution I see, would be to translate the enum value into a string, inside the driver, and provide it as a "asynParamOctet" parameter that could be read by a stringin record. But this "hides" the range of possible states from the clients, unlike mbbi.
Is there any other approach that wouldn't hide the range of states from the client? What whould be the best practice for situations like this?
2) Bitmasks
Other parameters correspond to bitmask values, where each bit would be translated into a flag (defined as a string) and put into a list. If the bit is unset, it means the flag should be absent from the list.
The 'bi' record seems to be the right choice for this, but it applied to each bit individually. What is the best approach to aggregate all these flags under the "same box"?
Is there a record that can be used to aggregate all the 'bi' record values, or a way to read all of their values simultaneously?
Thank you in advance, Joao
From: Mark Rivers [[email protected]] Hi Joao,
The example in asyn/testAsynPortDriver is a simple example.
This tutorial starts with a simple driver and gets more complex in subsequent versions: https://github.com/epics-modules/measComp/blob/master/documentation/measCompTutorial.pdf
This page has links to 2015 YouTube video lectures on asyn and asynPortDriver: https://epics.anl.gov/docs/APS2015.php
This page also has links to 2018 YouTube videos on asyn and asynPortDriver under the areaDetector section:
Mark
From: Joao Afonso <[email protected]>
Hi Mark,
Thank you for the quick answer. I will take a look into asynPortDriver documentation, to see if writing a driver is a good approach for us.
Is there any specific documentation you would recommend to help writing it?
Thanks, Joao
From: Mark Rivers [[email protected]] Hi Joao,
What you have tried seems reasonable, but unfortunately it won’t work. The reason is that the drvAsynIPPort driver does not have a mechanism to asynchronously call back to device support when new input arrives. There are several other ways to do this.
- You can use streamDevice. It works with SCAN=I/O Intr records by polling the device. streamDevice should even be able to parse the UDP buffer for you into the individual records you want to use. - You could write your own little asyn driver, derived from asynPortDriver. It would just have a small loop like this:
while (1) { pasynOctet->read(myBuffer) value1 = parseMyBuffer(1) setIntegerParam(myParam1, value1) value2 = parseMyBuffer(2) setIntegerParam(myParam2, value2) callParamCallbacks() }
Mark
From:
[email protected] <[email protected]>
On Behalf Of Joao Afonso via Tech-talk
Hello!
First, sorry if any of these questions seems too simple. I started working recently with EPICS and I am still learning how it works.
Basically, I am trying to create an IOC that works as a UDP server. It should be listening at a certain port and, when a new packet arrives, it should update a set of records with the incoming data. It doesn't need to respond to any of the packets.
The data is a binary array, which will be read into a waveform record, and then unpacked into other records in order to be read by the clients (I don't know if this is the best approach, for now I am just experimenting). The structure of the binary array is fixed and known beforehand.
For now, I just want to update the waveform record with the binary data when the UDP packet arrives. I am using asynDriver since it seems to provide all the tools I need:
On the 'st.cmd' file I have:
[...] drvAsynIPServerPortConfigure ("fgc_udp", "localhost:2906 udp", 10, 0, 0, 0) dbLoadRecords("db/fgc_udp.db","GW=${FGC_GW_NAME}:") [...]
And on the 'db/fgc_udp.db' I have:
record(waveform, "$(GW)UDP") {
Since I am using 'I/O Intr', I would expect the record to be updated when a new UDP packet arrives, but it is not working. It only updates if I use the IOC shell command "dbtr xxx:UDP", or if I change SCAN to a "N seconds" option.
Do you know how I can fix it? I guess it is something simple, but I am stuck.
I would also like to know if using a waveform record is a good starting point for unpacking binary data, or if there is a better alternative.
Thank you in advance, Joao
|
- References:
- RE: asynDriver - UDP server Joao Afonso via Tech-talk
- RE: asynDriver - UDP server Mark Rivers via Tech-talk
- Navigate by Date:
- Prev: RE: https://ics-web.sns.ornl.gov/css/nightly/ down? GAGET Alexis via Tech-talk
- Next: Re: asynError in write on Power PMAC IOC Wayne Lewis 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: RE: asynDriver - UDP server Mark Rivers via Tech-talk
- Next: Support for Lakeshore 625 Super Conducting Magnet Power Supply Ivashkevych, Oksana 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
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·