| 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: | Tue, 8 Jan 2019 16:43:35 +0000 |
|
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]]
Sent: 04 December 2018 16:01 To: Joao Afonso Cc: [email protected] Subject: RE: asynDriver - UDP server 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
|