Receiving Streamed UDP data


#1

Hello,

I have a device that steams serial data (a simple ASCII string) over the Ethernet network the controller is connected to.
It uses an UDP socket, the destination IP address and port number can be changed.

How can I receive the string with a Snap-PAC-R1?

The existing documentation explains how to stream memory data from the controller; I want to receive a simple string.

Any pointers will be appreciated.

Luis


#2

Hi Luis,

I’m glad you asked. The SNAP-PAC controller firmware currently has support for communicating via udp using communication handles (just like tcp), we just don’t “officially” support it.

That is, we haven’t fully documented/tested all the ways it could be used and abused so it’s an “at your own risk” feature at the moment, partly because udp is tricky, and using it with our current implementation you have to handle sequencing of packets yourself.

However, every time a SNAP-PAC controller communicates to an Ethernet brain, it’s using an internal udp comm handle. This feature is on the list of undocumented features we plan to officially support/document in the (hopefully near) future. Be sure you’re subscribed to OptoNews to make sure you don’t miss when it’s officially supported.

In the meantime, using a udp comm handle is very similar to tcp, just use “udp” in place of “tcp” in your comm handle’s initial value or set it using the [B]Set Communication Handle Value[/B] command BEFORE doing the [B]Open Outgoing Communication[/B] command. You can omit the IP address if you don’t need it (so the comm handle might be something like “udp:22004”).

Other tidbits that may be helpful:

• A document on port numbers: http://www.opto22.com/documents/1940_TCP_and_UDP_Port_Assignments_Tech_Note.pdf

• Controller firmware version 9.1 has get.src & set.dest options in [B]Send Communication Handle Command[/B]:
[INDENT]If you haven’t already, you may want to upgrade to 9.1 firmware since Send Communication Handle Command now includes these options which may be useful to you:

  •        For both udp and tcp, the new [B]get.src[/B] command returns the IP address from which the connection originated. 
    
  •        For upd, the new command, [B]set.dst:n.n.n.n:pppp[/B], sets the destination for the next messages, until another set.dst command is sent.
    

[/INDENT]
• [B]PAC Sim[/B]: Your udp comm handles should work in [URL=“http://www.opto22.com/site/downloads/dl_drilldown.aspx?aid=3690”]PAC Sim too, which might be helpful for testing.

-OptoMary


#3

Hello OptoMary,
Thanks a lot for your quick response, after a bit of trial and error I got the UDP comms working, I can send a string and receive a string.
I found a couple of free UDP testing tools on the net to test the PAC code.
I am including the code here in case someone else needs the example:

SetCommunicationHandleValue(“udp:22004”,chHealth_Monitor);

intFunction_Status = OpenOutgoingCommunication (chHealth_Monitor);

if (intFunction_Status) Then
NumberToString(intFunction_Status, strError_Message);
strError_Message += " - Failed to open Health Monitor channel";
endif

DelaySec(5);

SetEndOfMessageTerminator (chHealth_Monitor , 10);

intFunction_Status = SendCommunicationHandleCommand(chHealth_Monitor, “set.dst:192.168.1.46:12345”);
if (intFunction_Status) Then
NumberToString(intFunction_Status, strError_Message);
strError_Message += " - Failed to set destination for Health Monitor channel";
endif

DelaySec(5);
intFunction_Status = ReceiveString (strHealth_Monitor, chHealth_Monitor);

if (intFunction_Status) Then
NumberToString(intFunction_Status, strError_Message);
strError_Message += " - Failed to receive string from Health Monitor channel";
endif

DelaySec(3);

intFunction_Status = TransmitString(“test Text”, chHealth_Monitor);
if (intFunction_Status) Then
NumberToString(intFunction_Status, strError_Message);
strError_Message += " - Failed to transmit string from Health Monitor channel";
endif

Regards,
Luis


#4

Luis,

Thanks for the code snippet, a great timer saver for other UDP pioneers.

We used UDP at the hospital for years and years (it’s still in and running as far as I know) to talk to the main paging system.
Believe it or not, it was the only way to communicate with the system outside of the VT100 terminal on the switchboard operator’s desk!
Hooking the Opto 22 system up to the paging system was an important step in notifying staff of the different statuses that the Opto system was controlling in the hospital. (We still use the paging system a lot, even now that ‘everyone’ is carrying cell phones; the Opto system simply sends text messages as well, via email).

Since we were only talking to one device, we set up our comm handle a little different. Here is a screen shot showing the details:


The chart is pretty much the same as your OptoScript, so similar in fact, that I am not going to bother to display it.
I just thought the comm handle was different enough to be worth a comment.

Ben.


#5

Is UDP still inching closer to official support? If not, referencing this thread in the manual could be a time saver too. In the absence of any other guidance, I would probably have guessed UDP can be inserted in the comm handle value in place of TCP, since it is sort of referenced in the documentation of the “Synchronize Clock SNTP” command. However, it was nice to find this thread and get confirmation.


#6

Good question, thanks for asking. Not sure when it’ll be “official” yet, but in the meantime, besides the set/get commands I mentioned above, these addition options are also supported in the latest-and-greatest firmware:

  • get.srcport to get the port from which an incoming packet originated
  • get.ttl to get the current time-to-live value
  • set.ttl to set the current time-to-live value