FIRST Robotics Competition Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

FRC LabVIEW/cRIO specifications/stats

I've got a couple technical questions that I've searched around a little bit for but can't find. Hopefully someone can answer them:

(our team uses LabVIEW)

1. How much memory does a typical FRC program take up on the cRIO? We probably don't need to worry about running out of space, but it would be nice to know. Could you find out by just looking at the properties of a built LabVIEW project? I see in the cRIO-FRC Operating Instructions manual that it has 128 MB of "nonvolatile memory" (flash?) (with 64 MB system memory). If you think of that as 1/4 of a gigabyte, that's pretty good storage space.

2. How does the code iterate on the cRIO? I believe it repeats/communicates with the driver station 20x per second? In the Robot Main.vi it looks like it gets the robot mode and runs whatever mode applies (teleop, auton, etc). If nothing new/already gotten/nothing has come in from the driver station, it does nothing. This makes it seem like it might finish before the driver station sends more "instructions." I assume because of how LabVIEW does data flow that if something comes in from the driver station before the cRIO is done running, say teleop, it will keep running until it's done and then "read" the driver station info. Right? Or will it get cut off?

3. The cRIO has an FPGA, which I know is like a fancy processor. Is the cRIO set up to just automatically use it for general processing? Or do we have to tell it "You work on this," like I've heard you can do with normal processors?

4. Is closing references (with Close VI) really just a programming formality? In all the examples I've seen, there's conflicting problems with it. For example: if you close them after teleop, how are they going to be opened again for the next time teleop gets executed? And in previous years when teleop was basically a big While Loop, you were supposed to close them after exiting the while loop. But the loop is like the "master loop," it's never going to close. So what's the point?

Thanks so much!

0 Kudos
Message 1 of 14
(11,924 Views)

Hi LabVIEWEnthusiast,

1. I don't know off the top of my head what the number is but you can always go to NI Measurement & Automation Explorer and expand the Remote Systems category on the left. If you click on your cRIO and then select the System Settings tab at the bottom of the window, you'll see how much disc space is currently being used on your cRIO.

2. The number of times the code iterates will depend on what's in it. The loop in RobotMain.vi is your main loop. During each iteration of the loop, we communicate with the driver station to determine what mode we're in and update any values coming from or going to the driver station. Then we go to the case structure we'll execute whichever mode (teleop, auto, etc) we're currently in. Then, we move onto the next iteration of the loop where we check with the driver station and then execute the code for the appropriate mode we're in. Even if no new values are received from the driver station, we still exectute the code of whichever mode we're in. Now lets say, for whatever reason, you've placed a 2 second wait inside your Teleop VI. Each time we iterate through the while loop and we're in Teleop mode, it'll take 2 seconds plus the time it takes to execute the rest of the code in Teleop.vi before it goes onto the next interation of the while loop.

3. This is going to be a very high level response, so please let me know if you want something a little bit more specific. You can look at the cRIO as having two parts: the FPGA and the Real Time OS. The FPGA is mostly responsible for reading data from and writing data to the I/O modules in the cRIO and we have written the code for this. We have hidden this code from you and the students. Everything you program is deployed to the Real Time OS on the cRIO and you do not affect the FPGA at all.

4. In general, closing references is good programming practice. Every reference is additional memory that is allocated. When you close a reference, you're freeing that memory for other parts of your program to use. If you don't close your references, you end up with a memory leak because every time you run your VI, more memory is allocated when you open a reference. If you look at RobotMain.vi, you'll notice three sections: Begin, Teleop/Auto, Finish. In Begin is where you open your references. In Teleop/Auto, you use those reference to communicate with various parts of your code. In Finish, you close all your refences because you're no longer using them. This follows the good programming practice of Open, Read/Write, Close.

The examples do make this concept a little confusing. This is because the examples were created to run on their own and you had to break them up to incorporate them into the main robot code. Lets say you wanted to use the Simple Digital Input Example in your robot code. You would place the DIO Input Open VI in Begin VI. DIO Input Get Value would go in Teleop. Finally, DIO Input Close would go in Finish.

I hope my answers helped.

~Olivia

Message 2 of 14
(4,763 Views)

Yes, thank you Olivia, your answers definitely helped. Here's some questions I still have:

2. Is there a way to officially clock how fast the code is iterating, or would you just put some counter code in the Robot Main vi and have it tell you how many times per second it's running at?

4. Yes, I see where you're getting at. But the Finish VI never gets used in typical use. It only gets run if you press the control on the front panel of the Main VI. And that can only happen when you're running in debug mode. Plus, when you turn off the robot by cutting power, it by gets rid of those refrences because it's not powered anymore.

0 Kudos
Message 3 of 14
(4,763 Views)

2. There's a couple of tools available for you. The first is a benchmarking example found in Help»Find Examples»Toolkits and Modueles»Real-Time»Benchmarking»Benchmark Project. lvproj. You can modify this project to monitor how long it takes to run a certain chunk of code.

Another way to also monitor how long it takes to a VI is by using the Performance and Memory tool. It's found under Tools»Profile»Performance and Memory. Within this tool check the Timing statistics box and start the tool. Run Robot Main in debug mode. When that's done, stop the profile tool and you'll see how long each VI took to run.

4. Actully, the Finish VI also runs when Get Competition Mode VI in Robot Main gets a message from the Driver Station that says it's in the Finish mode. So whenever you're done a practice round or you disable a mode from the Driver Station, the Finish mode is selected and communicated to Robot Main.

You're right that by turning off the robot, you remove the memory you've allocated for the references. However, if you were working on the robot and continuously running the code over and over again to test, you'll be allowing the memory leak to build up. We also want to instill good general programming practices to the students. Yes, you can get away with not closing your references on the FRC robot but if the students go on to work on other projects in the future, leaving references open may cause crashes in their applications.

0 Kudos
Message 4 of 14
(4,763 Views)

2. Wow, these sound great! Thanks, I'll try them out.

4. If the finish mode gets run at those times and you're expected to close refrences then, how do they get opened back up if say, you enable your robot?

You do have a very good point with running code over and over again. Are you saying when you load new code or restart the code without turning off, it doesn't clear the memory? Are there other vis that can tell you the current memory usage of the cRIO?

0 Kudos
Message 5 of 14
(4,763 Views)

Yes, if you don't turn off the cRIO and restart the code, the memory allocated from the previous run does not clear. The Performance and Memory tool that I mentioned above can also shows the amount of memory used when you run a VI so you can use this to track the memory usage.

0 Kudos
Message 6 of 14
(4,763 Views)

O54E wrote:


4. Actully, the Finish VI also runs when Get Competition Mode VI in Robot Main gets a message from the Driver Station that says it's in the Finish mode. So whenever you're done a practice round or you disable a mode from the Driver Station, the Finish mode is selected and communicated to Robot Main.

You're right that by turning off the robot, you remove the memory you've allocated for the references. However, if you were working on the robot and continuously running the code over and over again to test, you'll be allowing the memory leak to build up. We also want to instill good general programming practices to the students. Yes, you can get away with not closing your references on the FRC robot but if the students go on to work on other projects in the future, leaving references open may cause crashes in their applications.

While I don't have access to the driver station code, I'm fairly certain it doesn't get put in finish whenever you disable. I also don't think it puts it in finish after the practice mode is over. Looking at the Get Competition Mode VI, I don't see how finish can get set from driver station. It looks like only Telop/Autonomous and Enabled/Disabled modes can get set. Finish only looks like it gets called based on the finish input, which is the button on the robot main front panel.

One interesting thing about the architecture of the cRIO for FRC is that debugging is done out of RAM. Thus, if you want to be able to debug you need to keep the program under 64mb. This is shown when downloading the program.

Our 2009 code was pretty complex (and called a lot of libraries) and it was around 55mb. However, several things were optimized with last year's labview, so it was smaller when recompiled with last year's labview. Our 2010 code was much less complex, and a lot smaller.

0 Kudos
Message 7 of 14
(4,763 Views)

sciencewhiz wrote:

While I don't have access to the driver station code, I'm fairly certain it doesn't get put in finish whenever you disable. I also don't think it puts it in finish after the practice mode is over. Looking at the Get Competition Mode VI, I don't see how finish can get set from driver station. It looks like only Telop/Autonomous and Enabled/Disabled modes can get set. Finish only looks like it gets called based on the finish input, which is the button on the robot main front panel.


Finish does get called whenever you disable. If you look inside Get Competition Mode.vi (this is the VI that the Finish button is directly wired to), you'll see that we call a VI called CommDataCache.vi and this is what we call a functional global variable. This VI is called in other VIs and can hold data such that when it's called in other VIs it will have this data readily available to be used in other parts of code. Think of it as a more complex global variable.

CommDataCache.vi is also called in in the Driver Station's Start Communication VI which is running in parallell with the main loop in Robot Main. Within the Start Communication VI, we are checking the state of the game from the Driver Station to determine what mode we're in. If the Driver Station reaches the end of a match/is disabled/etc., it calls CommDataCache.vi and updates it with the data that says we're in the Finish Mode. CommDataCache.vi is then called again within Get Competition Mode.vi which then reads that we're in the Finish Mode and passes this information to the rest of the code.

0 Kudos
Message 8 of 14
(4,763 Views)

So if the Finish.vi is called when you disable, and you close all your refrences there, what happends when you're at home and you disable and enable your robot repeatedly during testing? Your code won't work once you enable it again and the refrences are all closed. This is what I don't get about closing refrences in the Finish.vi.

Maybe that's something we need to explore as beta test teams...

0 Kudos
Message 9 of 14
(4,763 Views)

O54E wrote:

Finish does get called whenever you disable. If you look inside Get Competition Mode.vi (this is the VI that the Finish button is directly wired to), you'll see that we call a VI called CommDataCache.vi and this is what we call a functional global variable. This VI is called in other VIs and can hold data such that when it's called in other VIs it will have this data readily available to be used in other parts of code. Think of it as a more complex global variable.

CommDataCache.vi is also called in in the Driver Station's Start Communication VI which is running in parallell with the main loop in Robot Main. Within the Start Communication VI, we are checking the state of the game from the Driver Station to determine what mode we're in. If the Driver Station reaches the end of a match/is disabled/etc., it calls CommDataCache.vi and updates it with the data that says we're in the Finish Mode. CommDataCache.vi is then called again within Get Competition Mode.vi which then reads that we're in the Finish Mode and passes this information to the rest of the code.

I can't seem to post a picture, so bear with my explanation. CommDataCache is called only once in the Get Competition Mode vi. The only data that is wired is the Raw Control Byte. It takes the 2 bits from it, and decodes it into autonomous/telop and enabled/disabled. With only 2 bits being decoded, there isn't space for a 5th state, finish. Perhaps there is another bit in the Raw Control Byte or something else in CommDataCache that is finish, but I can't see any possible way for it to be decoded in the Get Competition Mode vi as it is currently written.

Let me give another reason why finish can't be currently called from the driver station. We did not close any references in finish. Therefore, if finish was called, nothing was closed. I do know many people who did close references in finish. So, if finish was called from the driver station, they would have closed refrences. In my case, if begin was later called, I would have got a lot of errors about references already opened, which I did not. If begin was not later called, the teams that closed references robot's would have stopped working. Neither thing hapened. The only logical explanation is tha the driver station is not causing finish to be called.

0 Kudos
Message 10 of 14
(4,763 Views)