Using Sockets with the cRio in Wind River

[C222]

I've been trying to use "sockLib.h" in wind river to send custom data back to my laptop. sockLib came with an html guide, but it all seems needlessly complicated. Is there an easier way to send data packets from the cRio to a laptop over the network?

[virtuald]

Its exactly the same as sockets on a normal operating system (well, mostly the same), so the difficulty is around the same.

Otherwise, you could use the dashboard class in conjunction with the labview dashboard viewer to send data that way.

Something we've been doing is just writing data files to the cRio filesystem and retrieving the file via FTP. You have to call Priv_SetWriteFileAllowed(1) or something to that effect for it to allow you to write to the filesystem however.

[nathanww]

Look at the exaple code for the robot and dashboard--this has some examples of how the user data function works. An important thing to keep in mind if you go ahead ande use your own protocol is that everything except the control port and the dashboard port will be firewalled at the competition.

[C222]

Thanks everyone, I got it working. If people would like it, I stuck it on my server here.
I also included a simple C# program to recieve from port 1027.

[byteit101]

can I have the source (so i don't have to decompile it, which is vvveeeerrrrrrrryyy easy w/ .net apps except the resources)?

[C222]

Originally Posted by byteit101

can I have the source (so i don't have to decompile it, which is vvveeeerrrrrrrryyy easy w/ .net apps except the resources)?

Sure, once I get home. I hope you dont mind that it's C#. You could also use a packet sniffer such as Wireshark.

[byteit101]

I hope you dont mind that it's C#.

My favorite Language is C# Followed by PHP, and then C++

[C222]

Here ya go. This'll just display the pure text of the packet on the screen. Ignore the "Send" button, it was originally created to be a chat client. Also, make sure you change the ports and IP addresses. I would also suggest you leave the protocol as Dgram.

This is also on my server 'cause its to big too upload to CD. Here ya go.

[kiettyyyy]

Well,

I want to be able to use this at comp, so, what port would we have to transfer data on?

[EHaskins]

Originally Posted by kiettyyyy

Well,

I want to be able to use this at comp, so, what port would we have to transfer data on?

FIRST has stated that there will be network monitoring in place to prevent any non-control system data from being transferred during the competition.

To send data during competition you must use the dashboard data, which is included in a control system packet, so it won't be blocked.

Any other system will likely be illegal at competition.

[kiettyyyy]

Well, how do you pull the dashboard data off of the control system packets?

[EHaskins]

Originally Posted by kiettyyyy

Well, how do you pull the dashboard data off of the control system packets?

The protocol is simple, but, AFAIK, undocumented. They intended for the Labview dashboard to be used.

When your PC's IP address 10.xx.yy.6, you'll receive UDP packets from the DS on port 1165.

There is some header data which includes team number, battery level, field status, ect. After that is your user data.

I don't remember what the index of the user data is in the packet, but you can figure it out by filling the user data with some value(255), and looking at the data in a packet sniffer.

[nadavsen2]

So using sockes is illegal?

[byteit101]

Originally Posted by nadavsen2

So using sockes is illegal?

Yes, no socks, just your bare feet in your shoes (You mean sockets i'm sure)

[Greg McKaskle]

I pretty sure they are OK with any sort of dashboard you want to build. They do not want or intend to allow communication from the dashboard to the robot or FMS, and they want to limit the data from robot to dashboard to ensure that every team gets a good quality connection and to make sure the joystick data isn't sacrificed.

I've posted a couple times on what the data types are in the dashboard data. By the way, there really is no reason to use the default dashboard anyway, it is really too low level. The first picture shows the mandatory header that is attached by the infrastructure.

The second shows how the dashboard decodes the remaining 984 bytes.
The first field is to identify duplicates and skips and you can probably ignore.
The next field, the string is the user data you can do anything you want with.
The next field, also a string is an error stream from WPILib. I'm not certain how this is controlled on C/C++, but on LV, this is optional, and you can turn it off on the Error Display VI. The third field is the buffer of binary data produced by the Build Dashboard Data.vi or by the default C code for sending low level I/O values to the dashboard.

Again, I'm not sure how this is done in C, but in LV, when all of the data won't fit, the first thing to be dropped is the I/O values, then the error info, and finally, the user data will be truncated.

Also, keep in mind that LV strings are not null terminated, but are preceded by an four byte count of bytes. Ditto for the array.

If you have further questions, fire away.

Greg McKaskle