Using Sockets with the cRio in Wind River
 

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?

Re: Using Sockets with the cRio in Wind River
 

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.

Re: Using Sockets with the cRio in Wind River
 

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.

Re: Using Sockets with the cRio in Wind River
 

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.

Re: Using Sockets with the cRio in Wind River
 

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

Re: Using Sockets with the cRio in Wind River
 

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

Re: Using Sockets with the cRio in Wind River
 

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

Re: Using Sockets with the cRio in Wind River
 

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.

Re: Using Sockets with the cRio in Wind River
 

Well,

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

Re: Using Sockets with the cRio in Wind River
 

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.

Re: Using Sockets with the cRio in Wind River
 

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

Re: Using Sockets with the cRio in Wind River
 

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.

Re: Using Sockets with the cRio in Wind River
 

So using sockes is illegal?

Re: Using Sockets with the cRio in Wind River
 

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

Re: Using Sockets with the cRio in Wind River
 

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