UDP Socket sendto error

I have a machine that is broadcasting UDP packets that require an acknowledgement sent before it tries to send the next packet.

Up until about Mar. 10 (based on the date of the current message being received) the following code linked to a value change in the message was working as expected.

“”"
import socket

UDP_IP = “10.50.132.194”
UDP_PORT = 26601
MESSAGE = “ACK:26101\r”

sock = socket.socket( socket.AF_INET, # Internet
socket.SOCK_DGRAM ) # UDP
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock.sendto( MESSAGE, (UDP_IP, UDP_PORT) )
“”""

But since about Mar. 10, the tag change scripts error out with the following error message:
“”"
com.inductiveautomation.ignition.common.script.JythonExecException: Traceback (most recent call last): File “”, line 10, in File “user-lib\pylib\socket.py”, line 1284, in sendto raise _map_exception(jlx) socket.error: (-1, ‘Unmapped exception: java.net.SocketException: Invalid argument: no further information’)

at org.python.core.PyException.doRaise(PyException.java:219)

at org.python.core.Py.makeException(Py.java:1239)

at org.python.core.Py.makeException(Py.java:1243)

at org.python.core.Py.makeException(Py.java:1247)

at socket$py.sendto$154(user-lib\pylib\socket.py:1284)

at socket$py.call_function(user-lib\pylib\socket.py)

at org.python.core.PyTableCode.call(PyTableCode.java:165)

at org.python.core.PyBaseCode.call(PyBaseCode.java:301)

at org.python.core.PyBaseCode.call(PyBaseCode.java:157)

at org.python.core.PyFunction.call(PyFunction.java:338)

at org.python.core.PyMethod.call(PyMethod.java:139)

at org.python.pycode._pyx862.f$0(:10)

at org.python.pycode._pyx862.call_function()

at org.python.core.PyTableCode.call(PyTableCode.java:165)

at org.python.core.PyCode.call(PyCode.java:18)

at org.python.core.Py.runCode(Py.java:1275)

at com.inductiveautomation.ignition.common.script.ScriptManager.runCode(ScriptManager.java:636)

at com.inductiveautomation.ignition.common.script.ScriptManager.runCode(ScriptManager.java:603)

at com.inductiveautomation.ignition.common.script.TagChangeScriptExecutor$TagChangeExecutionCallback.execute(TagChangeScriptExecutor.java:192)

at com.inductiveautomation.ignition.common.script.TagChangeScriptExecutor$TagChangeExecutionCallback.execute(TagChangeScriptExecutor.java:135)

at com.inductiveautomation.ignition.common.util.SerialExecutionQueue$PollAndExecute.run(SerialExecutionQueue.java:102)

at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)

at java.util.concurrent.FutureTask.run(Unknown Source)

at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

at java.lang.Thread.run(Unknown Source)

Caused by: org.python.core.PyException: Traceback (most recent call last): File “”, line 10, in File “user-lib\pylib\socket.py”, line 1284, in sendto raise _map_exception(jlx) socket.error: (-1, ‘Unmapped exception: java.net.SocketException: Invalid argument: no further information’)

… 26 common frames omitted
“”"
Does anyone know what in the sendto function might be causing the error?

I should also mention that this only appears to be a gateway issue as I can run the code in the Script Console without any issues.

Hmm, never seen that error before and not finding much useful searching for it…

Is that the entirety of your script? Maybe it has something to do with the fact you never close your sockets and now some resource is depleted.

1 Like

Hi Kevin,

Yes that is the entirety of the script. When I checked into what open sockets I had on the gateway, there were a bunch of UDP sockets that were open on a java.exe process that I am assuming is Ignition, I think you are correct in the problem being us never closing the sockets.

I have updated my script as follows and it appears to be working:
“”"
import socket

UDP_IP = “10.50.132.194”
UDP_PORT = 26601
MESSAGE = “ACK:26101\r”

sock = socket.socket( socket.AF_INET, # Internet
socket.SOCK_DGRAM ) # UDP
sock.sendto( MESSAGE, (UDP_IP, UDP_PORT) )
sock.close()
“”"

Can you think of any reason why this might cause issues in the future? I’m fairly new to socket programming so I just want to make sure I’m covering all my bases.

Thanks,
Kyle

If sendto errors out close() won’t be reached. Best practice is generally to close a resource like this in a finally block.

2 Likes