I’ve recently tried to program an encoder into our robot program. Being new to Labview, I’ve had a lot of issues but have been able to solve them all up until now. What’s happening is I’ve finally got readings from the encoder but now our steering goes crazy everytime we enable the program. Before it was the opposite with the steering working but not the encoder. I’ve tried changing the program in multiple ways to get both to work at the same time but I’ve had no luck. Right now I have my encoder program in Periodic Tasks under the 100milsec time loop. Steering is in Teleop in it’s own vi. We can go forwards and backwards with our joystick. I can take pictures of my code and display them here if needed. I just want to get both the encoder and the steering working together.
Any help with this would be fantastic as I’m running out of ideas. Thanks.
Please be a little more specific with “going crazy”. Try and describe exactly what your steering does. Also, please describe what you are trying to accomplish with the encoders (i.e. how is your software using them to modify your steering?) Lastly, please desribe what kind of drive system you have. All of that will help get into the ballpark of where your problem might be.
If by “going crazy” you mean steering is overreacting, then that has to do with your scaling.
How are you using the encoders? PID speed control? Position control?
Have you tuned your PID?
We want to use the encoders as speed control and to see if the wheels are going the same speed. Right now we have no encoders attatched to the wheels, only code to read the encoder when we turn manually turn it with our fingers. We have four wheels set up with each pair being conected by a chain for crab steer. Now normally each pair of wheels is perfectly lined up with the other pair but when we add our encoder code they start turning randomly and become unaligned. Turning the wheel at the driver station has no effect on the wheels. When we remove the code everything returns back to normal. This is confusing because our encoder code is not hooked up at all to anything. It’s just sitting in Periodic Tasks reading the distance and rate of the encoder.
I see, so the encoders are currently only passive at this moment, and should have no effect on the drive.
Please upload the entire code.
Here’s an easy way to do that:
Archive (aka zip) the folder that contains this project. Hopefully it is in its own folder.
Upload the zip file
Not only does this remove the hassle of uploading every individual file, but it also gives you a 5MB limit as opposed to 500kb.
Without seeing the code, I’ll throw out some irresponsible speculation.
Since the code is just passive, it sounds like there might be an issue with channel assignment. I would check to be sure that you’re not trying to use the same channel for the motors and the encoders. Also check to see that your digital I/Os are configured properly. If you open the front panels for the encoder “get” blocks and the motor “set” blocks, you should be able to see if you’re set up and sending the right commands.
The problem is the while loop inside the encoder vi in periodic tasks which is itself a while loop. This never returns and never yields, causing problems.
In Periodic Tasks Your Encoder Example should not be within the 100ms loop, because it enforces it’s own infinite loop it would prevent anything else you might put in that loop from ever running more than once.
Just drag it outside the loop and that’s good enough.
In Encoder2.vi the infinite there needs to be throttled down. Right now it’s sucking up all your CPU time running just as fast as it possibly can.
Just add a 100ms wait in there just like that used in the Periodic Tasks 100ms loop.
For DIO In.vi you don’t have the correct input constant for DIO 9 or DIO 10.
See the tiny red dot where the wire connects?
Delete both of those and use Create->Constant to get the correct enum.
K I’ll try it. I have to wait until Tuesday though since that is when our team meets. Tell me if there are any other problems you see. Also thanks so far for answering.
QCEliteTeam648,
This is complex code. At the moment I can understand subsections and groups of functions, but I don’t understand “the big picture”.
The issue with encoders is almost certainly an interaction between software components that, by themselves, function correctly. While it does have something to do with your code to test the encoders, there are other parts of the code that are contributing to the issue. These sorts of problems are notoriously hard to troubleshoot and diagnose. The difficulty is amplified by hard-to-read code (especially large block diagrams).
I think the best way we can help you is by providing suggestions for ALL of your code in a process termed peer review. Suggestions are usually given in three categories: efficiency, cleanliness, and documentation.
Would you like to open up the entire project to peer review?
@Kamocat: I would like to. The easier it gets for others to read, learn and understand it the better because this is going to have to be taught to new programmers that we have in the future.
I’ll start with your “bit switch”.
This could be more efficient and easier to read by bundling the boolean values into an array and using the function “boolean array to number” (found in the boolean pallette):
What would make it better still is to use the refnum registry (as opposed to allocating and deallocating the channels each time), and to put the whole thing in a subVI:
Also notice the use of the FOR loop and the string array constant make the code smaller and cleaner. If nothing is wired to the N terminal on a FOR loop but you wire an array to it, it will execute for every element in that array.
I added a comment for why the values are inverted. To someone not familiar with the digital sidecar, this would not be obvious.
Here’s a simple change:
You know you “OperationMode” input for selecting between Autonomous and Teleop?
You could reduce coding errors by changing that to an enumerated variable. (With enumerated variables, the options are selected from a menu instead of being typed in)
For an example of an enumerated variable, look at the “DerivedRobotState” control in Teleop.vi
You could do the same with your “kickposition” input.
Make sure they are typedefs when you save them, and not regular controls. (As typedefs, when you change the functional properties of the control file, all instances of that control are changed accordingly. That means if you add a new option to the enumerated variable, that option will exist in all instances of it as soon as you save the file.)
Thank you!! Our encoder and steering are now working together. Also thank you Kamocat for your suggestions. I’m working on the bit switch as I type but I am a bit confused on the second post. Since I’m new to Labview and programming in general I don’t know what you mean by an enumerated value or typedefs.
Note that the control must be in a .ctl file to become a typedef. There’s two different ways to do that.
Create a new control by going to file menu and selecting “New…”. The following dialog will pop up. Select “control” and click OK.
OR
From an existing control, right click on the control, hover over the “advanced” item on the right-click menu, and select “customize”.
This will still create a new control, but it will be the control you selected (though you can always delete it and place down something else).
K I’ll see if I can do that. Sorry for not posting in a while. Our team has been busy with parades. Just posting to let you know that I am still here and reading replies/suggestions.
