Sending Data from Dashboard to Robot?

Hey Chief Delphi,

Head Programmer from 3878 here.

I want to be able to send a number value set by a control on the dashboard to be usable in Teleop.vi on our robot. I want the ability to set a motor’s speed through the dashboard. I was thinking of using UDP to send the numeric data to the robot, but I do not know how I would go about such a task. How would I retrieve the data on the robot (possibly using Periodic Tasks?) and be able to access it in Teleop?

This is really stumping me. Could someone help us with this?

Thanks very much,
Chris
Team 3787

Try this thread.

I had already seen this thread and found it very helpful. Thanks anyway. :slight_smile:

What I need help with receiving the data and processing it properly on the cRIO.

Data will be sent (via UDP/TCP) in string form. You’ll have to use flatten to string and unflatten from string to, well, flatten and unflatten your data from a string. You’ll have to supply the desired datatype when you unflatten (i.e. a constant that represents the cluster you’ve flattened). See the attached VIs in this post to see what I mean. Then, once you get your data from the string, you can do whatever you need to with it - just as if it was any other input to your robot.

And what if it’s a number from a slider? What I did was I converted it into a string using the Decimal Number to String and then flattened it, and sent that. I didn’t use a constant. What I was wondering was where should I put the receive stuff in my robot code? I want to access the data in Teleop, but I don’t think that is where the Open and Close should go. That’s what I was wondering about.

Thanks very much,
Chris
Team 3878

Actually, you can flatten the double output from the slider to a string, and when you unflatten it, wire a double constant to the unflatten VI (to tell LV what datatype out you want).

I would probably put the UDP listener in Periodic Tasks.vi, so it won’t slow down your other code. You’re also going to want to wire a timeout to UDP read (make it small: ~50 ms) so that your code won’t hang there. You can open/close your references inside Periodic Tasks (but outside of a while loop) and put your listener code inside a while loop.

udp read.png


udp read.png

Using TCP has been giving us a whole strong problems with no apparent cause or solution, and UDP’s buffer size is too small for the data we want to send.

The code in the second thumbnail is in the PC Dashboard, and the first’s from Periodic Tasks.vi. It seems like we’ve conformed with the proper way of setting up a TCP connection, but we’ve been getting timeout errors, corrupt data structure errors, error 62, among other things.

Is there a flaw in the code somewhere? Do I need to adjust some settings somewhere?

scrncap1.png




scrncap1.png

I’m not sure about the code you posted; it looks fine to me - how do you open the connections?

I think the best way for you to tackle your problem is to use UDP and split the data up into multiple packets. For an example of this, look in Build DashBoard Data.vi (VI snippet attached). You see how it rotates through sending all the data in 50 iteration cycles. The first 15 send analog data, digital data is sent on 20 and 30, and solenoid data on 40. This process repeats, and that’s how the dashboard sends lots of information over UDP.





I’m not sure about the code you posted; it looks fine to me - how do you open the connections?

We open them with the robot IP, 10.te.am.2, and the port number 1180. Is that wrong? It seems like there are a lot of things that are semantically and logically correct but don’t work for unseen reasons this year…

I think I’d prefer to make this TCP connection work than start using another completely different code, only to have it not work and then need to debug it again… but I’ll give it a try.

EDIT: And I’m not sure that would even work. How would I reassemble the data on the other side?

ANOTHER EDIT BECAUSE BUMPS ARE BAD: It seems that UDP isn’t having much of a problem sending information anymore, as I’m not getting the internal message buffer error anymore, but the UDP Read.vi seems to be timing out without receiving any information.

First off, that is quite the error message, but to answer the question.

It looks to me like the flatten and unflatten nodes do not match. You turned off the prepend size on one and left it unwired and on on the other. My suggestion would be to delete the False constant and leave it default. The case where you decide not to send size info is when it is a fixed amount in the protocol and the size is just extra overhead.

Kinda like in the other threads about comms, rather than delay your read loop, you can just let the read control the speed of communications. If you aren’t careful, your read gets a little behind and cannot catch up.

I can’t see a delay in the write loop, but hopefully something throttles how often it sends data.

Greg McKaskle

Okay, Thanks guys! It works great! :slight_smile:

Just one problem, I can’t get the unflattened, unbundled data from Periodic Tasks to Teleop. I tried some things such as variables and it didn’t send properly. Can anyone help?

I’m not sure what to do. What sort of problem? Are you sure that the value going to the variable write is the correct one?

Greg McKaskle

The value going to the variable is indeed correct, but whenever I try to pass the data from Periodic Tasks (where I got it) to Teleop (where it needs to be); the wire probed always returns the value as 0. I’m not too sure how to get the data where it needs to go.

If you are talking about a global variable, you can also open the global VI and observe the value there. If you are using something else, please elaborate.

Greg McKaskle

Just in case you’re trying to add a wire out of Periodic Tasks and into Teleop: that won’t work. Periodic Tasks never terminates, so it will never provide an output value. To communicate between one vi and another you can use a global variable, or you can do fancier stuff with semaphores or notifiers or queues or etc.

That actually worked! the Periodic Tasks VI is receiving the information.

I’m not sure, but it does seem like the UDP Read is slowing down the rest of the code (we’re getting a whole lot of watchdog expirations and the Driver Station is acting pretty wonky, and it doesn’t appear to be updating the Global variable I’ve wired it to.

Also, the UDP Read Vi is still receiving information when the code isn’t running at all. WTF?