Tips, Tricks, and Tactics for Programming

So after reading post after post about common issues and problems, I’ve decided to make a little “helper” thread on common problems, and how to fix them.

First and foremost, we’ll talk about basics. POWER

To ensure any and ALL code will work, we need to have the correct power, wiring, and distribution of said power.

P: "Motors won’t work when we try to run our code, but default code works just fine"

A: 9 times out of 10, your DS (that’s Digital Sidecar) will not be powered fully. The DS will recieve power via cable from the cRIO. This will only be 5V however. Take note of your DS, there will be three indicator LEDs. 5V, 6V, and BAT. If you have 5V and no other, chances are, your DS isn’t wired into the PD board (Power Distribution). To do this: Run wires from a 20A slot on the PD board, and connect it to the DS via WAGO connector.
***If this doesn’t work, check your cable. Issues with the flat cable have risen, and the round cable I have found works well. Also check and make sure you have a secure connection. 1/16th of an inch unplugged can cause issues. Next would resort to checking/changing the DS as necessary, as metal shavings can get inside the chassis and blow out parts on the DS.

P: "Error -44061 …Left and Right cannot run fast enough…"

A: This is a safety config problem that occurs when action/reaction takes too long and the safety config cuts the motors out. To solve this, basically, go to your Begin.VI and to the right of the drive code, and wire in a SafetyConfig <Found under WPI Robotics Library > Robot Drive > Advanced> and set it to disabled. The Pros of LabVIEW will also recommend debugging, which I haven’t figured out myself :wink:

P: "Waiting for cRIO to respond."

A: To quote Alan Anderson, “If you haven’t installed the second LabVIEW update, then you might be suffering from SmartDashboard Paralysis.” This update is crucial to successful code deployment, and the download for the update can be found here.

This is just a tip to allow faster code deploying.
-Close your SmartDashboard while trying to deploy new/edited code. The Dashboard could be using up a large amount of CPU, causing LabVIEW to run slow.

Now for some hardware.

Make sure that ALL wires are clean; meaning no tears, improper crimps, cut wires, poor splicing, and so on.

If the code is bugging up and you’re using the FLAT cable running from the cRIO to the DS, try switching back to the rounded cable. Odds are, you may fix said problem.

00.00 Voltage reading on the Dashboard:
To fix this reading, find your Analog Breakout and attach it to the top of SLOT 1 (NI 9201 I believe it is), and wire it into a 20A output on the PD Board. Huzzah! Voltage reading!

Check your batteries and wire connections frequently. You wouldn’t want any arcing due to loose wires and/or connection issues.

And as always, observe proper safety etiquette. Wear safety glasses; NEVER work with electric components if the robot is on and running; report any and all injuries, the same goes with faulty equipment.

The point of this thread is to allow others to read and learn. I know I have. If you have other tips, tricks, and tactics, please feel free to post them here. Every day you learn something new, and this thread aims to help everyone somehow. Good luck to all at competitions world wide, and remember, safety FIRST.

Nicely done.

To address the debugging topic:

If you want to know how often a piece of code is running, there is a folder in the Robot project called Support Code, and it contains a VI called Elapsed Times. If you place that in your teleop or in a loop or other code that is run repeatedly, this VI will note how often it was called from various locations. You may want to pass in a better call name if you are calling it more than once from a VI.

When your app is running, you can open the panel to Elapsed Times and it will show the times between calls. This is not going to fix anything, but may help you understand which things are lagging and by how much.

Sometimes the code is always late, but other times it coincides with some logic like toggling a joystick button. If you follow the logic, you’ll often find a wait statement. Delays in teleop cause the robot to ignore joystick input. The safety VIs will tell you about this and cut the motors. They can be disabled, but the ignored joystick will remain. Code sequences that take more than 20 or 40ms should be moved out of teleop. Replace the code with a trigger and put the response code into Periodic tasks.

Greg McKaskle