What's the best way to test?

[DominickC]

In your zipped code, you've wired the throttle to your ball accumulator.

From what I've learned through the various errors I've stumbled upon, when the throttle is fully rotated forward (towards the +), it's interpreted as a -1. When it's fully rotated downward (towards the -), it's interpreted as a 1. There's no marking or physical click for 0.

So, depending on the physical setup of your ball collection system, setting the throttle to full forward might turn your collection motor in the opposite direction you want it to go.

If you want to stick with the throttle, just negate the output of the axis. This tool is under Programming>>Operations.

I've coded our collection motor to intake a ball (set the ball collection motor to -1) when button 2 is pressed and held down. The ball is spit out (collection motor to 1) when button 3 is pressed and held down. This might be better for your application.

[RyanN]

Like everyone else said, drivetrain shouldn't be hard at all. It's all done for you really, you just have to place the VIs in there.

The Accumulation code makes sense, but won't work they way you think it will. You've created a rising edge (on button press) code trigger with the feedback node and the greater than > block. What this means is that the code will execute exactly one time when you press it down, and won't execute it again until you release and press that button again. Good job from this point.

Inside the case structure you have a T/F from another feedback node. So you'll press it once, and the motor will stop (from value 0), and then you press it again, it will go full 'forward' (from value 1) once the NOT block inverts your boolean F to T. So here's another good job from me.

The problem is that you are not constantly feeding the motor with a value. For safety purposes, motors are not allowed to continue their set value unless it is fed a value every so many milliseconds (I think it's like every 100ms). If you look at the given autonomous code, you'll see that they use a while loop instead of the simpler sequence structure. This is why this is done.

You can simply add another feedback node, with the motor control value in it, then add the motor to the outside of the case structure, as shown in the picture attached.



Here's how I would do it, because case structures clutter up the work area, plus it hides half of the code that can execute.

[RyanN]

Originally Posted by RyanN

Like everyone else said, drivetrain shouldn't be hard at all. It's all done for you really, you just have to place the VIs in there.

The Accumulation code makes sense, but won't work they way you think it will. You've created a rising edge (on button press) code trigger with the feedback node and the greater than > block. What this means is that the code will execute exactly one time when you press it down, and won't execute it again until you release and press that button again. Good job from this point.

Inside the case structure you have a T/F from another feedback node. So you'll press it once, and the motor will stop (from value 0), and then you press it again, it will go full 'forward' (from value 1) once the NOT block inverts your boolean F to T. So here's another good job from me.

The problem is that you are not constantly feeding the motor with a value. For safety purposes, motors are not allowed to continue their set value unless it is fed a value every so many milliseconds (I think it's like every 100ms). If you look at the given autonomous code, you'll see that they use a while loop instead of the simpler sequence structure. This is why this is done.

You can simply add another feedback node, with the motor control value in it, then add the motor to the outside of the case structure, as shown in the picture attached.

Attachment 12130

Here's how I would do it, because case structures clutter up the work area, plus it hides half of the code that can execute.

Attachment 12131

In the Disabled.vi, you still have code for the Left and Right Motors... you may want to keep that there and name your drive that, or rename it later. This will cause errors to pop up if you disable your robot, since the reference doesn't exist.

You should also add all of the other motors to Disabled.vi, and set their value to 0 to prevent watchdog problems from coming up.

Compressor:
I don't see any compressor code, but I see that you are using pneumatics. In order to legally use pneumatics, you need to have the electronics and programming to charge up your storage tanks before the match, regardless of whether or not you have a compressor on your robot.

Periodic Tasks.vi:
Reference to "Left and Right Motors" and "Joystick 1" here. Delete the while loops while you're at if you you don't plan on using them. Also, your compressor code should go in Periodic Tasks.

Also, regarding your original question. If you don't have the hardware in front of you to try your code on, you can always test logic off the robot using just a plain old VI, implementing your logic, and having inputs and outputs.

Logic Simulator.vi

[Alan Anderson]

Originally Posted by RyanN

The problem is that you are not constantly feeding the motor with a value. For safety purposes, motors are not allowed to continue their set value unless it is fed a value every so many milliseconds (I think it's like every 100ms).

By default, only the Drive motors have the safeties enabled. Unless you have explicitly activated the motor safety for other motors, it is perfectly reasonable to set them once and expect them to continue as commanded indefinitely.

[DominickC]

Originally Posted by RyanN

The Accumulation code makes sense, but won't work they way you think it will. You've created a rising edge (on button press) code trigger with the feedback node and the greater than > block. What this means is that the code will execute exactly one time when you press it down, and won't execute it again until you release and press that button again. Good job from this point.

Inside the case structure you have a T/F from another feedback node. So you'll press it once, and the motor will stop (from value 0), and then you press it again, it will go full 'forward' (from value 1) once the NOT block inverts your boolean F to T. So here's another good job from me.

The problem is that you are not constantly feeding the motor with a value. For safety purposes, motors are not allowed to continue their set value unless it is fed a value every so many milliseconds (I think it's like every 100ms). If you look at the given autonomous code, you'll see that they use a while loop instead of the simpler sequence structure. This is why this is done.

You can simply add another feedback node, with the motor control value in it, then add the motor to the outside of the case structure, as shown in the picture attached.

Attachment 12130

Here's how I would do it, because case structures clutter up the work area, plus it hides half of the code that can execute.

Attachment 12131

Ignore my shoddy explanation, here's a picture of the code I'm trying to describe.

[RyanN]

Originally Posted by DominickC

Ignore my shoddy explanation, here's a picture of the code I'm trying to describe.

The way his code is written is like a pushbutton switch. You press it once, and the motor turns on, you press it again, and the motor turns off. He has the right logic. Your code will work, but it requires an extra button, and it requires the driver to hold the button down to keep the motors running.

Originally Posted by Alan Anderson

By default, only the Drive motors have the safeties enabled. Unless you have explicitly activated the motor safety for other motors, it is perfectly reasonable to set them once and expect them to continue as commanded indefinitely.

Cool, that's news to me! So his accumulation code will work perfectly fine as is.