Communication via UDP (User Datagram Protocol) / IP

A few terminals with Ethernet adapter and TCP/IP protocol stack also support UDP (User Datagram Protocol).
By the time of this writing, it wasn't clear yet how the display application could communicate via UDP - but most likely, there will be a set of interpreter commands and function for this purpose.  Thus, the following overview describes -more or less- the planned functionality. Please ask the software development engineer (Mr. Wolfgang Buescher) for details if you need them ...


  1. Introduction, technical background, limitations
  2. Interpreter commands and -functions to communicate via UDP
    1. udp.conn : sets the communication parameters, and optionally 'maps' interpreter variables into UPT packets
    2. udp.send : sends a single datagram
    3. udp.ra[0..3] : retrieves the N-th byte of the remote IP address.
    4. udp.rcvd : checks for reception, and (with udp.rvcd=0) prepares the next reception.
    5. udp.rcnt : returns the number of received packets
    6. udp.rd.b[N] : reads the N-th data byte of the received data field.
      Also available to access 16-bit 'words'and 32-bit 'doublewords'.
    7. udp.rd.len : retrieves the length (in bytes) of the last received data field.
    8. udp.tcnt : returns the number of sent packets
  3. Debugging UDP- and other LAN traffic using Wireshark
    1. Testing UDP with the demo application 'UDP_test.cvt'

See also (links to other documents):

  1. Manual for the UPT programming tool
    1. Interpreter functions (overview)
    2. Interpreter commands (overview)

1. Introduction, technical background, limitations

The User Datagram Protocol (short: UDP), is a relatively trivial, connection-less protocol. For general information on UDP, search the internet, or read this Wikipedia article.

UDP belongs to the 'Internet Protocol Suite' - but it must not be confused with TCP/IP. UDP is much simpler than TCP, which is the reason why UDP is sometimes used for field-bus communication over Ethernet. (in fact, the programmable devices by MKT can only use UDP "over Ethernet", nothing else, since there is no PPP-, nor SLIP protocol implemented in these devices).

Furthermore, in contrast to a fully fledged UDP implementation, this one is limited to a maximum blocksize of one Ethernet frame, thus the maximum 'net data size' is something near 1472 bytes per packet (size of one Ethernet frame minus IP- and UDP headers). In the author's opinion, this limitation is not too severe, because to replace CAN by UDP, a maximum "message" size of 1400 bytes (netto) should be sufficient - especially when compared with the 8-byte data field in a CAN message. Fragmentation of UDP packets would make the firmware too complicated, and require a lot of RAM to re-assemble the received fragments.

Mapping data ("values") to and from UDP packets is done by virtue of the terminal's built-in command interpreter. In fact, the same subroutines are used which also map and unmap CAN 'signals' from ("CANdb-") messages. Using the terminal's 'programmable events' (or, in future, the terminal's scripting language), you can even implement your own, UDP-based protocol to communicate between two devices via Ethernet (LAN).

Note: Sending and receiving UDP packets is only possible with the real hardware - the simulator in the programming tool doesn't support UDP (at least not yet.... 2010-05-25).

2. Interpreter commands and -functions to communicate via UDP

Work in progress ! ...

The following list is only informal, because by the time of this writing, the implementation of these functions was not finished yet (2010-05-25) !

Up to four different UDP 'channels' (all with different port numbers, and/or remote IP addresses) can be used. The channel number is passed as a formal array index after the keyword "udp". Like array indices in most (better) programming languages, these channel numbers begin at zero. If the UDP channel number (<channel>) is omitted, the program uses the first channel (with index zero).

Examples: T.B.D. ...

3. Debugging UDP (and other LAN traffic) using Wireshark

Even though UDP may be considered a 'simple' protocol, getting it to work on a particular local area network (LAN) can be troublesome. For example, firewalls, Ethernet routers with different levels ( of complexity and difficulty ;-) can turn an easy task into a nightmare. This chapter contains a few notes by the software developer which may help you to get the UDP communications running.

The most valuable tool to debug network traffic (here: LAN, Ethernet) proved to be Wireshark; formerly known as Ethereal. Wireshark is a free, and possibly the world's best network protocol analyser. We strongly suggest you become familiar with this program; it can save hours of brainless "trial-and-error" debugging, especially if you don't know what's going on in your network, and 'where those packets get lost' between the sender and receiver.

Before starting a Wireshark capture, turn off the port number translation : Edit -> Preferences... -> Name Resolution -> uncheck 'Enable transport name resolution' .
Otherwise, (UDP-) port numbers (like 1235) would be replaced by some wildly guessed names (like "mosaicsyssvc1"), which doesn't really help in most cases, because 'our' port numbers are usually not what Wireshark thinks they are. Don't forget to SAVE the modified Wireshark settings !

ToDo: Write a step-by-step introduction including....

3.1 Testing UDP with the demo application 'UDP_test.cvt'

After installing the programming tool, you will find an application named 'UPT_test.cvt' in the programming tool's "programs" folder (whereever the installer decided to place it..).

You can use this application as a first crude test for UDP communications. For a quick start (without any special hardware), we will first try to send a few UDP packets, using the programming tool's built-in simulator (note: The simulator uses the windows socket services, aka "winsock", and thus may behave completely different than the 'real' firmware).

Step 1 : Load the demo application with the programming tool

In the tool's main menu, select File .. Load Program . Locate the programming tool's programs folder (not to be confused with the "windows" programs folder).

Once you got there, select the file UDP_test.cvt .

Step 2 : Try to run the demo application in the programming tool (simulator)

In the tool's main menu, select Reset. This resets the simulated terminal firmware, and switches from edit mode into simulator mode (like "Run !"). The simulated LCD screen should become visible, showing something similar as this screen:

screenshot 'UDP test'
(Screenshot of the UDP test application)

Unfortunately, by default, the windows firewall doesn't seem to like UDP, so it will block any UDP traffic. With a bit of luck, windows will prompt you with a message like the following (here, when calling the udp.conn command from the UPT programming tool, i.e. from the simulator):

(Screenshot of windows firewall message saying
"Der Windows-Firewall (der Brandmauer?!) hat aus Sicherheitsgründen einige Funktionen dieses Programms geblockt.",
which means (in English): "The windows firewall has blocked something for security reasons." )

In most cases, you should be very suspicious if such a message pops up. But here, in this special case, we know the program 'ctptwin1' (= the CAN-Terminal Programming Tool for Windows) tried to communicate via UDP, so we allow (un-block) this function. (Sidenote: it would be extremely helpful if windows told us WHAT EXACTLY the blocked program tried to do, but hey, it's windows...). So, on a german PC, click on "Nicht mehr blocken" ("don't block.." (??) in English).

At this point, it's time to start Wireshark to see what's going on (on the local network).

Next, again in the UPT simulator screen, click on the programmed button labelled

Send datagram on Channel #0

The (simulated) display application will now try to send a UDP packet to some recipient, for simplicity with a hard-coded IP address .
The IP protocol stack (in this case, the IP protocol under the hood of windows) will try to resolve the Ethernet address first. That's the reason why, for the very first step, we will not see a UDP packet in Wireshark (... that'd be too easy ...) but something like the following:

(Wireshark protocol capture: ARP request)
No. Time Source Destination Protocol Info
16 19.810005 CameoCom_08:01:e4 Broadcast ARP Who has Tell

Here, the sender (PC running the UPT programming tool / simulator; Ethernet adapter made by "Cameo"?) had the local IP address , and -to send an IP frame via Ethernet to the intended recipient- it needed to know the recipient's MAC address. This is what ARP (Address Resolution Protocol) is for. If all works well, 'someone' (whoever it is) with IP address will answer the ARP request. The result should look similar to this (again, on the Wireshark screen):

(Wireshark protocol capture: ARP response)
No. Time Source Destination Protocol Info
17 19.810177 IeeeRegi_8e:70:39 CameoCom_08:01:e4 ARP is at 00:50:c2:8e:70:39

... which means that the recipient (here: an MKT-View II with IP address and MAC address 00:50:C2:8E:70:39) has answered the ARP request after about 1.7 microseconds, so the sender know knows which MAC address to use when trying to send the UDP packet - which happens in the next step: 18 UDP Source port: search-agent Destination port: mosaicsyssvc1

(Wireshark protocol capture: UDP packet from to
No. Time Source Destination Protocol Info
18 19.810181 UDP Source port: 4096 Destination port: 4097

This means that we successfully sent the first UDP packet. But still things may go wrong. For example, in the next step, the recipient didn't have a matching UDP port opened, which caused the IP protocol to send a 'error message' as a response (in geek speak, ICMP):

(Wireshark protocol capture: ICMP response when destination UDP port is invalid)
No. Time Source Destination Protocol Info
19 19.810451 ICMP Destination unreachable (Port unreachable)

Thanks to Wireshark, you can check what's going on, know how to can fix it : If you can see the ICMP message, you know the recipient could be reached, so it's not a "hardware" problem but a problem with the port numbers.

If all works as planned, you will see the counter on the receiving terminal's LCD, labelled "Received UDP packets, Channel X" increases by one, each time you press the "Send.." button on the other devices.  If you got this far: Congratulations, UDP seems to work properly in your network !

<ToDo: Complete this, especially what to do when things do not work as easily as described above >