Transmitting data to the cRIO from the Driver's station via TCP/UDP

[Pirate programe]

See the edit.

[Greg McKaskle]

UDP is a very basic communications protocol, quite good for sending small amounts of data in a repeating fashion. If you find yourself with more data than will fit in UDP ( about 1500 bytes is typical ), I'd suggest using TCP.

TCP will automatically break a big packet into smaller ones, and reassemble on the read end. It ignores duplicates, checks for missing elements and corrupted elements, and puts sub packets back in order if they happen to arrive out of order. There are other difference too, but the camera and other HTTP sessions are based on TCP.

The error you received was indicating that the buffer was bigger than the UDP limit. When the issue looked cleared up, it was just that you were discarding the error.

As I pointed out in the other thread, there is no reason to send an image. The dashboard already displays it. Why send it again?

Greg McKaskle

[Pirate programe]

How big is the UDP buffer? Because all that I'm sending is the Target Info array from the vision code flattened to a string...

[Greg McKaskle]

I believe the UDP limit is somewhat dependent on the devices being used, but in this instance, I think 1500 bytes or so.

Greg McKaskle

[Pirate programe]

The TCP code in the screenshot is giving me the following error:

Error 56 in TCP Write in Dashboard Main.Vi

Possible reason(s); The network operation exceeded the user specified or system time limit.

I can only assume this means it's timing out, but why would it do that? It seems as if all of the parts are in the right place.

[Bendito]

This thread has been quite helpful. I am still somewhat stuck with an issue on the cRIO crashing when I send UDP to it. I suspect it has something to do with the buffers, but if anyone has helpful advice, I'm open to it!

[apalrd]

A couple of TCP and UDP tips and comments:

-A UDP packet is designed to fit in one Ethernet frame, limiting it to 1500bytes minus UDP headers. I believe a UDP header is 8 bytes, but don't quote me on that

-TCP is designed to send streams of bytes instead of packetized data. The disadvantage to this is that the sending application must explicitly manage the send buffer and force TCP to send it all of the bytes, and the receiving application must manage packet starts/ends.

-TCP is also a reliable medium, with error checking and retransmission. This is usually a bad thing if you care more about getting the data fast than getting all of it (if you miss a targeting packet, you will get another one in about 50ms, so you just ignore it).

-UDP is a better choice for this application due to the speed and packet-oriented nature.


-The UDP listener should have errors trapped and a timeout set to a fairly low number (I use 1000ms) - I use trapped errors as a source of determining if I actually should unbundle the packet and use it

-The UDP listener should exist in its own thread (While loop) throttled by nothing other than itself - There should be no waits. The UDP listener will block for new packets, and if you are behind in receiving packets then it's a bad thing.

-Send the smallest packets possible - Do all target filtering and multiple target analysis (stuff that works with arrays of targets) on the laptop, and send a single target coordinate to the robot over UDP - This keeps the packet size under the limit and non-variable.

[Greg McKaskle]

I didn't run your code yet, but looking at the screenshots, it does look like you are only reading the udp data five times a second, pretty slow. But you shouldn't crash the cRIO doing that. What sort of crash is it?

Greg McKaskle

[Doug Norman]

Originally Posted by Bendito

This thread has been quite helpful. I am still somewhat stuck with an issue on the cRIO crashing when I send UDP to it. I suspect it has something to do with the buffers, but if anyone has helpful advice, I'm open to it!

When you say crash - exactly what happens? If you can reproduce a crash with a simplified program, please contact National Instruments via our FRC forum. We can have application engineers look into it.

[marccenter]

CD,
Man, most of this stuff is over my head. Is there a simple example somewhere to show how to display a PWM channel, Joystick Input, or global variable on the Dashboard?

[Mark McLeod]

There is an example in the Tutorials that come with LabVIEW.
From the Getting Started window, look at

Tutorials -> Tutorial 7 - Integrating Examples into Robot Code

Then page down to Part 2 and it gives a step-by-step using a gyro output as an example.

[Bendito]

The UDP listener should have errors trapped and a timeout set to a fairly low number (I use 1000ms) - I use trapped errors as a source of determining if I actually should unbundle the packet and use it

-The UDP listener should exist in its own thread (While loop) throttled by nothing other than itself - There should be no waits. The UDP listener will block for new packets, and if you are behind in receiving packets then it's a bad thing.

Thank you, I fixed this, and created a much more simplified communication system. It actually works flawlessly now (even through repeated power ups/downs between robot and driverstation) I have some screenshots of it included.

When you say crash - exactly what happens? If you can reproduce a crash with a simplified program, please contact National Instruments via our FRC forum. We can have application engineers look into it.

The crash that occurs was happening whenever I was trying to debug the robot through running the robot program while still in labview with probes set up. It seems that when the driverstation tries to connect with the robot, it boots off labview's connection with the cRIO. A "Connection with the cRIO was lost" would appear, and there would be no way to put more code on without closing the driverstation. This was causing me to think it was crashing, and causing a lot of hair pulling in the debugging process, but was eventually figured out.

[marccenter]

Thanks Mark for pointing me to the right section. One observation and one question remains.

Observation - It may be implied or understood, however, in order to have the Dashboard Main.vi become updated with the changes shown in the tutorial I found myself creating my own dashboard project on the classmate and then manually moving the 3 files created by the dashboard project (C:\Users\developer\documents\Labview Data\builds|FRC Dashboard Project|FRC PC Dashboard) to the C:\Program Files\FRCDashboard subdirectory in order for the classmate to find the new Dashboard Main.vi (did I rename the two original files in the directory late last night before copying?).

Question: I am trying to extend the example to multiple pieces of data rather than just one by trying to use the bundle function in the Dashboard Main.vi function but it doesn't seem to take it. I was able to bundle, flatten to string and input this to the Driver station Set User Data HI function inside my robot project code. Should I be able to unpack this in my new dashboard project or is the Data Hi function simplistic?

[Alan Anderson]

Originally Posted by marccenter

I was able to bundle, flatten to string and input this to the Driver station Set User Data HI function inside my robot project code. Should I be able to unpack this in my new dashboard project or is the Data Hi function simplistic?

You can certainly do what you are suggesting. When you do the "unflatten" operation in the Dashboard, you need to show it an example of the data type you want it to create. That means you need either a bundle constant that matches the arrangement of the bundle you created in the robot project, or a typedef that you can share between the robot and dashboard projects so the robot code can do a bundle by name instead of just bundling raw data.

[Mark McLeod]

Copying the Dashboard files to FRC Dashboard works, you also have the options of changing the build destination to FRC Dashboard so it always gets put there when you build, or changing the Driver Station .ini file to point to your dashboard location.

Here is an example of some quick Dashboard diagnostics looked at from both the robot and the PC side of things. This is slapped together, so take it as development code. The elements are in the order they were added to the cluster on the robot side. I recreate an indicator "358 Custom data" whenever I add or remove elements, then copy that to the Dashboard side to define the order/types of elements in the cluster.
In the final robot I'd create a TypeDef to define each data element. That gives everything a name making it easier to digest and clearer to work with.