Experimental Physics and
Industrial Control System

Hi All.

I have a device that sends its status as a UDP broadcast with port 30304 and I’d like to use asynIP to get it but can’t get it working using simple interactive commands in EPICS iocsh.

 

I have successfully tested the server and host in question  using a little python socket program, essentially:

 

########### start PYTHON CODE###############

broadcastIP = '255.255.255.255'   #note that 10.6.255.255 doesn’t work, though I expected it to…

idBroadcast = (broadcastIP,30304)

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)

s.bind(idBroadcast)

m, reportedAddress = s.recvfrom(bufMax)  #m gets the data and reportedAddress indicates where it was broadcast from

################END PYTHON CODE######################

and it works, gets the status every second. So no firewalls getting in the way and the port number is OK and status is being broadcast every second as expected.

 

Trying to use asynIP in EPICS, I do the following to test, using asynDriver release 4.34:

 

#########start EPICS IOCSH commands############

drvAsynIPPortConfigure("CRYOREAD01","255.255.255.255:30304 UDP*",0,0,0)  #Have also tried the specific subnet broadcast 10.6.0.255 and 10.6.255.255 with no luck

…… #no errors reported

iocInit()

asynSetTraceMask  ("CRYOREAD01",-1,0xFF)  

asynSetTraceIOMask("CRYOREAD01",-1,0xFF)

…..#no errors reported

epics>

#Then ran the following interactively

epics> asynOctetConnect CR CRYOREAD01 0 10  200  #address 0, timeout of 10 sec, buffer 200

epics> asynOctetRead CR 100

From asynTrace I get:

 

2019/03/18 15:10:17.359 CRYOREAD01 asynManager::queueLockPort locking port

2019/03/18 15:10:17.359 CRYOREAD01 asynManager::queueLockPort created queueLockPortPvt=0x183c0f0

2019/03/18 15:10:17.359 CRYOREAD01 asynManager::queueLockPort created queueLockPortPvt=0x183c0f0, event=0x183c110, mutex=0x18318c0

2019/03/18 15:10:17.359 CRYOREAD01 asynManager::queueLockPort taking mutex 0x18318c0

2019/03/18 15:10:17.359 CRYOREAD01 asynManager::queueLockPort queueing request

2019/03/18 15:10:17.359 CRYOREAD01 addr -1 queueRequest priority 0 not lockHolder

2019/03/18 15:10:17.359 CRYOREAD01 schedule queueRequest timeout

2019/03/18 15:10:17.359 CRYOREAD01 asynManager::queueLockPort waiting for event

2019/03/18 15:10:17.359 asynManager::portThread port=CRYOREAD01 callback

2019/03/18 15:10:17.359 CRYOREAD01 asynManager::queueLockPortCallback signaling begin event

2019/03/18 15:10:17.359 CRYOREAD01 asynManager::queueLockPortCallback waiting for mutex from queueUnlockPort

2019/03/18 15:10:17.359 CRYOREAD01 asynManager::queueLockPort got event from callback

2019/03/18 15:10:17.359 255.255.255.255:30304 UDP* read.

…..waits 10 sec

2019/03/18 15:10:27.369 CRYOREAD01 read from low-level driver returned 1

2019/03/18 15:10:27.369 CRYOREAD01 queueUnlockPort

2019/03/18 15:10:27.369 CRYOREAD01 asynManager::queueUnlockPort waiting for event

2019/03/18 15:10:27.369 CRYOREAD01 queueUnlockPort unlock mutex 0x18318c0 complete.

2019/03/18 15:10:27.369 Error reading, ninp=0 error 255.255.255.255:30304 UDP* timeout: Resource temporarily unavailable

and it always timesout with nothing received.

 

 

I also tried asynReport 4 CRYOREAD01 and got the following. Somewhat suspicious of nDevices=0 but this might be ok for a nonMultiDevice?

CRYOREAD01 multiDevice:No canBlock:Yes autoConnect:Yes

    enabled:Yes connected:Yes numberConnects 1

    nDevices 0 nQueued 0 blocked:No

    asynManagerLock:No synchronousLock:No

    exceptionActive:No exceptionUsers 1 exceptionNotifys 0

    traceMask:0xff traceIOMask:0xff traceInfoMask:0x1

    interposeInterfaceList

        asynOctet pinterface 0x7f986797d6e0 drvPvt 0x16d1410

    interfaceList

        asynCommon pinterface 0x7f986797a750 drvPvt 0x16cd7c0

        asynOption pinterface 0x7f986797a770 drvPvt 0x16cd7c0

        asynOctet pinterface 0x16cd8e0 drvPvt 0x16cd7c0

    Port 255.255.255.255:30304 UDP*: Connected

                    fd: 4

    Characters written: 0

       Characters read: 0

 

 

Can anyone suggest why this isn’t working or what I should do to better test it? (I did see comment in techtalk about UDP broadcast issues, but I think they were for versions older than the one I am using)

 

Thanks,

Terry