Program overloading the cRIO?

[Mark McLeod]

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

[ablahblah]

Here's Begin and Teleop

[Mark McLeod]

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.

[ablahblah]

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 ....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.

[Mark McLeod]

Originally Posted by ablahblah

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.

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...

Originally Posted by ablahblah

Eh....what's a feed forward node

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.

[ablahblah]

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.

[Mark McLeod]

Looks better.

To check how long this takes to execute, you can use the Elapsed Times.vi located under Support Code in the Project Explorer window.
Just drag and drop a copy anywhere in your Teleop, double-click to open its' front panel, then use Run in Robot Main.vi to try it out on the cRIO. Watch the Elapsed Times front panel to see how long Teleop is taking. You don't want it to be longer than 100ms, in fact less than 20ms is best.

You might have an issue with your checks for x+y /= 0
Joysticks at rest don't always equal 0. There can be a trace non-zero value, way too small to move the motors, but the cases depending on exactly zero might never be active for that reason.
Depends on the game controller though, so it might not be an issue.

Did you consider making a single button on each joystick a toggle?
Last joystick to push the button gets all control.
Stick with what makes the most sense to you though.

P.S.
I'm pretty sure that you'll find that your Teleop is too slow.
You can isolate and identify the slowest parts by using the Diagram Disable Structure to gradually comment out groups of statements to see what causes the slow down.

[ablahblah]

Ran too slow on site, and had no time to test and remake code. Eventually I just dictated that the odds of a joystick failing are so slim that the redundancies were pointless, and I stuck in the backup non-redundancy program that i made the night before. Works the way we want it to now, I thought redundancies weren't too worth it in the beginning anyways. Ty for the support nevertheless though, certainly another pebble in the pile of programming knowledge that I've been building up!