Program overloading the cRIO?
 

Hey all,
Well, I'm the new designated rookie programmer on my team, 2893, and had to learn Labview pretty much from scratch with no other programming experience, so I'd say only 75% the time I have an idea what I'm actually doing, heh. Anyways, I was wondering what were the possibilities of overloading the cRIO with a Teleop VI? We did a last minute program test in essence, a week before the robot shipped, and the double joystick program I made (with fallbacks allowing each to assume control of the robot, due to our controller failure paranoia), and it didn't work. Error report on the Driver Station reported that the loop was executing too slowly, or something, and was starving the loop. The programmer beforehand inspected my program and came up with 3 options means of why the program failed :
1: I left a case structure blank with nothing to do to the motors in the drive portion of Teleop.
2: I put all my multipliers in the case structures, and according to him doing that loads up the VI more. Also, he's saying that putting multipliers as outside of case structures as possible and instead having the structures feed the multipliers info is a better option (I had tons of little individual multipliers in each case structure doing the same operation, but with different constants).
3: I had wayyyy too many case structures, probably due to the fact that I was linking controllers up to control the robot independently when one fails.

What do you guys think? We haven't tested the program yet, and I'm making changes to fix 1 and 2, but 3 we've no clue whether it would be easy to overload the cRIO in that way.

Re: Program overloading the cRIO?
 

1) is what's causing the problem, and it's lucky the safetyconfig ("drive loop running too slow")caught it or you'd have a runaway robot.

The robot drive vi expects to get called every 100 milliseconds. If it does not, it shuts down the drive train until it gets called again. See, the problem is that calling the robot drive vi doesn't make the robot go forward for something like half a second and then stop, and then you call it again and it goes forward another half second. No, the vi instead just sets the speed and then has the motors run until it sets another speed.

Now, if you want to have a case structure that will have the robot keep going in the direction it was until the case structure becomes true again, what you have could work. However, it's better to use a feedback node (which keep their value from loop to loop) to just use the last value you sent the vi. So you'd have the value that's going to the robot drive vi go into the back of the arrow and then the output goes into a case structure that either tells the robot drive vi to do what the joystick is saying or do what it was doing last.

However, what you probably want to do is stop the motors if the case structure is true. If that is what you want, put the case structure around the values going to the drive vi, but not the actual vi, just the values. Then have it so that when the structure is false, it gives a value of zero.

Re: Program overloading the cRIO?
 

Post your code, we can help more.

Re: Program overloading the cRIO?
 

The "loop executing too slowly" message can be misleading. Most of the time, it really means "not calling Tank/Arcade/Mecanum Drive often enough". If you have a case where nothing commands the drive motors for a while, the motor safety watchpup will trigger.

Re: Program overloading the cRIO?
 

As mentioned, the "loop" the message is referring to is a repetitive task and not necessarily a For or While loop. If you need to investigate further, the Getting Started window for LV contains a Troubleshooting tutorial. Midway through the tutorial, it discusses the Safety VIs and how to measure more accurately how long different loops are taking. If you follow the tutorial and place the Elapsed Time VI into your teleop and perhaps into other periodic or vision loops, it will give you a better idea of how the code on the robot is actually running.

If you post the code, I'm sure you'll get more detailed advice.

Greg McKaskle

Re: Program overloading the cRIO?
 

Alright, I'll go and get the code on a USB stick today in our meeting and post it up. I'm assuming just the Teleop VI is sufficient?

Re: Program overloading the cRIO?
 

I would post at a minimum Autonomous Independent, Begin, Teleop and Periodic Tasks.

Re: Program overloading the cRIO?
 

*facepalms* forgot to get the code last night. Well, we're meeting Saturday as well...gonna have to remember that time. The code managed to successfully execute on the cRIO though, after the tweak so that the motors are always getting orders; bare cRIO was hooked up though with only the sidecar and nothing else (no jags, not even a breakout board).

Re: Program overloading the cRIO?
 

Uhh...I'm guessing I should be using Megaupload or some other file-hosting service to put up code, right? Or is there a built in upload option here?

Re: Program overloading the cRIO?
 

zip the code and just add it to your post as an attachment.

Re: Program overloading the cRIO?
 

Here's Begin and Teleop

Re: Program overloading the cRIO?
 

DIO 4 is Opened twice as "A UP" and "IR3" so those aren't likely to work.

Can't see why or how you modified the library code in DavidsWPIRobotDriveMotors.

Having your outputs from one case statement leave through an outer case statement, then come back in before it feeds the next case statement is not good...
That can lead to a lockup condition.
Any particular reason for not keeping it within the outer Case structure?

It looks like you are misusing feed forward nodes.
Why did you put them in there at all?

It's traditional to have inputs come from the left rather than from the right of the block diagram.

Re: Program overloading the cRIO?
 

Eheh, that program's been tweaked over and and over again, didn't follow standard input left - output right format because I haven't had time to really organize it the way I'd like it to.

The motor drive program was something our head programmer modified up a bit, I've no real clue of what modifications was made. I think it was just made so that all 4 wheels could independently be configured, or something like that. Don't have the VI on me at the moment though *facepalms again*

So, with the outputs, you're referring to having the multipliers outside of the main drive case structure...right? Wasn't too sure whether I should've done that or not either, been without some supervision lately in programming and I never asked about it now that I think of it.

Eh....what's a feed forward node :confused: ....Not too familiar with LabView quite yet, I just learned simple wire connecting basics, VI locations, constant/indicator creation, and variable creation from the head, and figured out everything myself.

Re: Program overloading the cRIO?
 

The way the LabVIEW data flow works is that nothing inside a programming structure (like a Case Statement or a While loop) will get executed until All the data inputs are present and accounted for.

By having outputs leave the Case statement and immediately come back in, the Case statement will wait for those inputs before starting...

Of course, the outputs won't occur before the Case statement executes either...

So the Case statement gets locked up waiting for itself to complete before it starts...


It's that thingy with the big arrow.
Normally, it is used to remember what a value was the last time it was executed. That way you can compare the last value with the current value.

Re: Program overloading the cRIO?
 

Patched up the code, what'd you guys think...?

Tried to keep outputs in the same case structure this time, though I'm not sure whether the amount of case structures in it is too much.