Use cases

• Control the state of the Academic RIO Device onboard devices and external peripherals from an HMIHuman Machine Interface, often a VI running on the PC host that communicates with the RIO RT target via its network connection. running on the PC host by transmitting UDPUser Datagram Protocol, a connectionless protocol based on sending data packets known as datagrams, a word play on “data” and “telegrams” -based client requests to a server running on the Device
• Retrieve information about the Device system state and external sensors and peripheral devices

Features

• UDP client:
  • Create a JSONJavaScript Object Notation, structured information encoded in ASCII text strings transferred between Web services string from a cluster containing client information (name, IP address, system time) and the desired state of the Academic RIO Device onboard LEDs
  • Transmit the JSON string as a UDP datagram client request
  • Receive the server response (another JSON string) and convert to a cluster display showing server information (name, IP address, system time) and the state of the onboard pushbutton and 3-axis accelerometer
• UDP server:
  • Listen for UDP datagrams on a user-defined port
  • Receive the client request (JSON string), convert to a cluster display, and set the state of the onboard LEDs according to the request
  • Create the JSON string containing server information and pushbutton and accelerometer states and return it to the client
• Display all IP addresses known to the host
• Code can be easily modified to transfer any type of information between the client and server

Keep in mind

• RT requires a network connection to at least one other host; connecting the Device to the PC via the USB cable establishes the USBLANUSB-based local area network (LAN) established between the Academic RIO and the PC host computer. network.

LabVIEW block diagram elements

Locate these elements with "Quick Drop" (press Ctrl+Space and start typing the name); click on an icon to see more sample code that uses that element:

Example code

• Connect your Academic RIO Device to your PC using USBLAN, Ethernet, or Wi-Fi. NOTE: Not all Academic RIO Devices have Ethernet and Wi-Fi connectivity options.
• Download and unpack the rt_udp-client-server.zip (for use with NI myRIO 1900) or the NIELVISIII-rt_udp-client-server.zip (for use with NI ELVIS III) archive, and then double-click the ".lvproj" file to open the project. NOTE: This project was written for a NI myRIO 1900 or NI ELVIS III connected by USBLAN at IP address 172.22.11.2. If you are using a different IP address or another Academic RIO Device (Example: NI myRIO 1950 or NI RIO Control Module) do the following:
  • If using the NI myRIO 1950 or NI RIO Control Module start with the NI myRIO 1900 Archive.
  • Different IP address: Right-click on the "NI myRIO 1900" Device, choose "Properties", and then enter the new IP address
  • Different device:
    • Right-click on the top of the project hierarchy, select "New Targets and Devices", keep the "Existing target or device" option, and then find and select your particular device
    • Select all of the components under the "NI myRIO 1900" device: click the first one and then shift+click the last one
    • Drag the selected components to the new device
    • Right-click the "NI myRIO 1900" device and select "Remove from project"
• Open and run “RT Main” under “NI myRIO 1900” to start the UDP server
• Open “PC Main” under “My Computer”:
  • Ensure that “server IP address” matches one of the available IP addresses of the UDP server running on the Device; you should see 172.22.11.2 when the Device is connected by USBLAN, otherwise another IP address when connected by wireless
  • Ensure that the “server port” number matches the “listening port” indicator on the UDP server
• Run “PC Main and observe the following:
  • “client message sent” cluster indicator updates with PC-related information
  • “server message received” cluster indicator shows the Device system information and sensor states
  • The same sets of information sent and received appear on the cluster indicators of the UDP server running on the Device
• Click the “client LED request” buttons on the UDP client (“PC Main”) to generate single messages to control the Device onboard LEDs
• Click “auto-send” to generate periodic client requests; change the physical orientation of the Device to change the accelerometer values, and push the onboard button, too
• Note that the “my available IP addresses” process updates once a second on the client and well as the server; try enabling/disabling the Device wireless or connecting/disconnecting the wired Ethernet to get a feel for the various networks available to each system

Expected results

Developer walk-through

Outline

• Review overall structure
  • PC Main: Initiate client-server transaction with RT server on change in value of any front panel control
    • Send client request: PC host name, IP address, system time/date, and desired LED state
    • Receive server response: RT target name, IP address, server time/date, and state of onboard devices (accelerometer and pushbutton)
  • RT Main: Set onboard indicator state according to client request and return onboard device state
    • Receive PC client request (described above)
    • Set the onboard LED state according to client request
    • Return server response (described above)
• PC Main:
  • Event-driven single-loop design
  • Use “First Call?” function to execute client-server transaction one time when application first runs
  • “Auto-send” button selects one-second event time-out to repeatedly execute the client-server transaction process
  • Open a UDP socket on the user-defined port number
  • “UDP client info” type definition creates standard data structure for PC host and RT target VIs as a cluster of:
    • Client name, time, date, and IP address strings
    • Four-element Boolean array for requested LED state
  • “Flatten to JSON” function converts cluster to a string
  • Write the client request message to the remote server
  • Read the server response as a JSON string; wait for up to five seconds before timing out with an error
  • Unflatten the JSON string to a cluster defined by the “UDP server info” data type:
    • Server name, time, date, and IP address strings
    • Three-axis onboard accelerometer values
    • Onboard button state
  • Report available IP addresses with “my IP addresses” subVI:
    • “String To IP” with “Multiple Output” enabled returns array of U32 integers
    • “IP To String” converts to a string array in dot-decimal notation
  • Close the UDP socket after loop exits
• RT Main:
  • Open a UDP socket on the user-defined port number
  • Wait for client requests:
    • Wait for up to 1 second before timing out; clear time-out error code 56 and continue waiting
  • Read client message and also return client IP address and port number
  • Unflatten the JSON string to “UDP client info” cluster
  • Extract the LED state and set the LEDs accordingly
  • Read the onboard button state and three-axis accelerometer values
  • Assemble the “UDP server info” cluster values and flatten the cluster to a to JSON string
  • Send the message as the response back to the client
  • Display available IP addresses on each loop iteration
  • Close the UDP socket after loop exits
• Locate the functions subpalettes
  • UDP
  • System time and date
  • JSON
  • “First Call?”

Related content

Tags:

• networking
• IP address
• UDP
• client-server
• application example

Targets:

• RT
• PC

LabVIEW VIs and block diagram elements:

• UDP Open
• UDP Close
• UDP Read
• UDP Write
• String To IP
• IP To String
• Flatten To JSON
• Unflatten From JSON
• Get Date-Time String
• Event Structure
• First Call?