What’s the best way to test code or check if its good? I don’t have any extra electronics besides whats on the robot and I’m a rookie so I have no clue whether or not the programming is good. Any help is great! THANKS! :]
Test Project.zip (228 KB)
Test Project.zip (228 KB)
The best way to test/debug code is to get your robot on a table, set on blocks, and play with your code. Now that your robot is in a bag, you’ll have to approach things differently. Write code you think will work, and have other people review it. Talk to them; bounce your logic off of them, what you can reasonably expect each VI to do, what you want to do and so on. In explaining everything to someone, you might find errors within your code.
The next best thing to a robot is a cRIO with a Digital Module and a Digital Sidecar along with one speed controller. You can move the single controller around and test most of your code on it.
Thanks for the info! 
Where’s the best place to post my code so that others can “tear it apart” and get their view. This IS my first year coding and I’m definitely not sure what the heck I’m doing! 
Thanks again!
-Team 3417
Generally, here. Take specific snippits and ask specific questions. You’ll get a reply.
Being that I pretty much don’t know code, I kinda wanna just send the entire thing and have someone check out the Begin.vi, Teleop.vi, and the finish.vi to see if there correct on what I’m intending.
I took a look at the code zipped above, and I think you have overlooked something important: Drivetrain.
I see that you have defined two joysticks, three motors (CannonTop, CannonBottom, and Accumulation), and one solenoid. I see no drivetrain references. Without this, you aren’t going to be moving much.
I also have some comments regarding your solenoid operation in Teleop which I’m putting in your other thread, since that is already being discussed there.
I’m not quite sure what to make of your accumulator setup. Are you trying to create a toggle?
Haha, the wheels are the hardest parts so I was waiting for it to be last.
The wheels are easy. They’re already in the code when you create a project. If you’re using two motors and single-joystick “arcade” control, you only need to tell it which PWM outputs your motors are on. If you’re using four motors, you can either use PWM y-cables or change the Open Two Motor with an Open Four Motor in the Begin vi. If you want to use two-joystick “tank” control, just open a second joystick and replace the Arcade Drive with Tank Drive in the Teleop vi.
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.
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.
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 (6.98 KB)
Logic Simulator.vi (6.98 KB)
Logic Simulator.vi (6.98 KB)
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.
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.
Cool, that’s news to me! So his accumulation code will work perfectly fine as is.