Acquire data over UDP

[CDLapoint]

I am a complete beginner with LabView, trying to use the example "Simple UDP" but I am stuck. I need position data from a motor controller. I have the controller ip address and the datasheet says that it "does not require a specific port number". To report the position I need to send the ASCII message "TPD" and it should respond with a number of encoder counts. I don't know for sure but I expect a signed 32bit integer as a response. The position value will need to be continuously updated, ie: each new value replaces the last, so that only the most current value is available to other parts of the VI. if a few updates get lost it is not a big deal, or if the updates are a little slow (10-100hz would be nice).

This is all the information I have and I have created the attached VI. There are probably many things wrong with it, but could someone please help me get it working?

its not clear to me when to use a different port, or to just use a service name? The help text seems to imply that I should write on one port and listen on another but that doesnt seem like how the examples are set up?

[CDLapoint]

I am still struggling with this. Using windows terminal, I can "telnet 192.168.0.20 23" and I get the command prompt. entering "TPD" and carriage return (found that is important so I added to VI), the controller indeed returns the encoder value 65326 as expected. I just need to replicate this in Labview.

I went back to the examples and tried working from them directly, changing only what is needed, the IP address, port, and how the received message is displayed (controller will return a string). For the sake of convenience I placed sender and receiver in same VI, but it doesn't work when separated as original either.

today is my last day to collect data before I lose access to the lab. Any help is hugely appreciated.

[altenbach]

I would start with the shipping example. Your VI is no good (most likely due to a complete misunderstanding of graphical programming and dataflow principles).

You have a data dependency such that your second loop cannot start until the first loop has finished. All you probably need is one loop where you send the query then receive the response.

You might also want to brush up on ethernet. For example telnet is TCP, not UDP, so something entirely different. I also don't think you should use a very low local port. Are you really sure your device is listening on UDP/24?

Can you point us to the manual for your device?

We need to know how the return value is encoded. As a first step, just look at the returned string and see if it is readable (e.g. formatted in decimal) or binary, e.g. two characters representing a U16 value in binary that needs to be cast/unflattened to the correct datatype.. 

[Fuergrissa85]

Sorry for switching accounts, I had no idea there is a 2 post/day limit for new users... so I was unable to respond to you in a timely way otherwise.

---

@altenbach wrote:

I would start with the shipping example. Your VI is no good (most likely due to a complete misunderstanding of graphical programming and dataflow principles).

---

Yes, 100%. I am complete novice with graphical programming and network communication (at this level). I am now working from the examples, changing the address and the string sent seems to execute fine. The receiver vi however throws error 56 (time out) at the UDP read node, so it just keeps looping, but always err56. 

Attaching the complete manual (~200pgs) and what I believe are the relevant two pages separately, hopefully to save some time. A third PDF I am attaching shows examples of sending TCP and UDP data, but not in labview. perhaps this shows the data type for the received UDP packets?

and this is an excerpt from manuf. website:

Part I - Standard Communication

1) Opening a Socket

Most programming languages that have an Ethernet interface have an "OpenSocket" type of function that will handle establishing the UDP or TCP/IP connection.  The arguments will usually be the IP address of the device you are connecting to as well as a port number.  For a standard connection to a Galil controller, the user should connect on port number 23 (Telnet).  Other port numbers are allowed such as those above port 1000 when needed for special applications.  See the IK command for more info.

2) Sending a Command

Once a socket is established, the user will need to send a Galil command as a string to the controller (via the opened socket) followed by a Carriage return (0x0D).

3) Receiving a Response

The controller will respond to that command with a string.  The response of the command depends on which command was sent.  In general, if there is a response expected such as the "TP" Tell Position command.  The response will be in the form of the expected value(s) followed by a Carriage return (0x0D), Line Feed (0x0A), and a Colon (:).  If the command was rejected, the response will be just a question mark (?) and nothing else.  If the command is not expected to return a value, the response will be just the Colon (:).

4) Closing the Socket

The socket should be left open during general operation to send/receive commands.  In order to close the connection, the programming language should have a "CloseSocket" that will close the TCP/IP connection to the controller.

[altenbach]

As I said, you need one loop containing send and receive in sequence. Have you tried UDP port 502?

Are you really sending "TPD<CR>" (i.e. the "TPD" string concatenated with a carriage return) or just "TPD"?

With each iteration, send your command to the device, then wait for a response. Can you show us your code?

[altenbach · Accepted solution]

Maybe try something like this (very rough draft for testing!):

Parsing the response can be implemented later, once we see how it looks.

Of course you need to make sure that you have the correct remote IP, i.e. the IP of the device.

Note that we wire a zero as local source port, meaning the system will chose an ephemeral random port that is guaranteed to be available. Your device will respond to whatever source port is in the incoming query. You might need to play around with the remote port. The manual is not very clear. Is there a configuration setting where you can set the UCP port it is listening on?

[Fuergrissa85]

It works! port 502 did not, but 23 does!

I was previously typing \n\r in my string to do the CRLF, but I changed it  using concatenate to follow your example. -399948 is the result I expected, the encoder outputs ~406k counts per revolution. If I turn the encoder by hand while running this it updates exactly as I would expect!

Thank you!

[altenbach]

Glad it works. According to the manual, the termination is a cr, not a crlf.