How does this program look?

[frankthelyon]

I'm wondering if this teleop program looks like it will run. I am a rookie programmer on my team, and because of snow days I am having to teach myself. I have prior programming experience, but am new to Labview. This teleop program is supposed to activate a "shooter" motor to 50% power when button 1 is pressed. Thanks you.

[Dusk Star]

Assuming that the "false" condition has a constant with value zero, than yes. Though this will set the motor immediately back to 0 when you release the trigger.

[Joe Ross]

That will set the motor to run at 100%. Set Output takes a value from -1 (full speed reverse) to 1 (full speed forward). Since 50 is larger then 1, it will be full speed.

One good practice is to make your programs flow from right to left. I would put your Set Output to the right of your case statement, so that it is easier to read.

[RyanN]

Good start, but I do see an issue, and I have four additional suggestions.

The 50, which I assume you want to be 50%, is incorrect.

You can see that the Set Output module wants a floating point value, but you passed it an integer value.

The Set Output values range from -1 to +1, for -100% output to 100% output. Right click on the number, go to the Representation menu, and select Double.

The number should now turn orange, like the wire going to the Set Output block. Next step is to change the 50 to a 0.5, for a 50% value. Just as you would represent in math, 50% is 0.50/1.00, right?

Here's the suggestions:
1) Don't use a case structure for this. If you go into the comparison menu, you should find a 'Select' block, which will let you pass a value, based on a boolean T/F input. It's a more space efficient, and easier to read way to select values based on a T/F input.

2) Keep your data-flow going in one direction. Just as you read a sentence from left to right, your data-flow should also go from left to right.

3) Connect the error lines. They can prevent unwanted behavior if an error does occur.

4) Avoid coercion dots. See the red dot on the case structure box where your wires go from blue to orange? That means there's a coercion happening, which sucks away some CPU and memory to convert your values. Always try sticking with the same data type throughout your data-flow. If it's necessary, you can convert the data types using any of the Conversion blocks under:

Numeric->Conversion
or
Mathematics->Numeric->Conversion

Here's what your program should look like at the end.

[Aren Siekmeier]

Originally Posted by Joe Ross

One good practice is to make your programs flow from right to left. I would put your Set Output to the right of your case statement, so that it is easier to read.

Particularly since it looks like that wire is going into a terminal on the right side of the Set Output VI.

Overall, the concept is sound, and that will compile and run (you can also tell by looking at the run arrow in the upper left - if it is broken, you have a compile problem, if it's white, it will compile). However, as pointed out, you want an input in the range -1 to 1 (that's why it's coercing your integer, that's what the red dot means). And make sure you are setting it to zero in the false. To simplify things, I would check out the select block on the comparison pallete. This will take a boolean input (your button) and choose one of two outputs as its output based on the boolean. The case structure is better suited to more radically altering the flow of code conditionally. And just to keep things clean, you won't need the axes unbundled on the second joystick if you aren't using them.

Edit: I got ninja'd ^

Also, I'm pretty sure the select block has less overhead than the case structure, if that's a concern at all.

[frankthelyon]

Does this look better?

[RoboMaster]

Originally Posted by Joe Ross

One good practice is to make your programs flow from right to left. I would put your Set Output to the right of your case statement, so that it is easier to read.

That is the power of dataflow programming. If you program it neatly, you can easily see what is going on.

Typically, inputs are wired in on the left, and outputs come out of the right. So the "flow" of the program will go from left to right, following the necessarily incremental transfer of data through the wires. It's a powerful thing to use, since you can "see" how the program works, instead of reading it, like a text based programming language. (Although, in their defense, if you get good at a text based programming language you can also easily see what's going on. Graphical languages are easier for beginners)

[frankthelyon]

Is this good for a begin.vi? PWM 3/4 are cim motors powering a shooter mechanism. Thanks for the help.

[RoboMaster]

The begin vi looks great.

Just make sure that your shooter motors are inverted correctly, based on how they are running your mechanism. See how the real drive motors have constants going to them which inverts them accordingly? You might have to adjust your shooter motors that way too, I don't know.

EDIT: yeah depending on what you really want to have happen, your control VIs should be the same for the different motors: drive vs. motor.

[Joe Ross]

In your begin, your shooter is a RobotDrive, but in Teleop, it is a MotorControl. They should be the same if you want it to work. I recommend that everything other then your drive train be MotorControl.

In telop, the Shooter Get reference is right to left, but everything else looks good.

In the toolbar of the block diagram, you can press the broom icon, and it will attempt to automatically clean up your diagram.

[frankthelyon]

Hello, thank you guys for all of the help so far. I talked to the design team today, and we switched to a pnuematic solenoid "kicking mechanism." Would this case structure work?

[RyanN]

Originally Posted by frankthelyon

Hello, thank you guys for all of the help so far. I talked to the design team today, and we switched to a pnuematic solenoid "kicking mechanism." Would this case structure work?

That won't work. You need to turn the other solenoid off before you turn the new one on.

Get rid of that case structure, and use a 'Not' logic block under the Boolean menu to keep the values negated (opposite).

I don't have my PC with the FRC code on right now, so you'll have to just understand this:



Here's where to find the 'Not' block:



And please, for the sake of reading your code, clean it up a bit before asking for help. There's even a tool for it! Select (marque) the code you want to clean up, then press Ctrl + U. Magic!

[frankthelyon]

Thanks for the advice. Does this look better?

[RyanN]

Much better! That should work!

One small thing, and not an issue at all really. The Joystick Get retirns both Button and Axis values, so you don't need the Joystick Get Axis. You can Un-Bundle from the Joystick Get on the axis output. It'll lower some overhead in your program.