Encoder v.s. Steering

[QCEliteTeam648]

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.

[Chris Hibner]

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.

[kamocat]

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?

[Joe Ross]

One thing to remember is that you should only write to the motor in one place, or else you risk sending conflicting values.

The descriptions that Chris asked for and a copy of the code are what is needed to fully debug this problem.

[QCEliteTeam648]

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'll post pictures of the code in here shortly.

[kamocat]

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:

1. Archive (aka zip) the folder that contains this project. Hopefully it is in its own folder.
2. 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.

[Chris Hibner]

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.

[Mark McLeod]

Just to eliminate the possibility of an electrical issue...

You're changing only the code download?
You're Not detaching the encoder wiring when you test without them?

[QCEliteTeam648]

Ok the code is attatched.

@Chris: The encoders have their own module so no they aren't sharing with the motors. That was one of the previous fixes we did.

@Mark: Yes only the code is being changed. Once we remove the code the encoders aren't being read and everything acts normal.

[Joe Ross]

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.

[Mark McLeod]

Just at first glance...

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.

[QCEliteTeam648]

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.

[Ether]

Originally Posted by Mark McLeod

Just at first glance...

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.

Remember this thread?
http://www.chiefdelphi.com/forums/sh...94&postcount=6

I nominate this for the FAQ. This seems to be a recurring misunderstanding among users of the FRC LabVIEW Framework.


~

[kamocat]

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?

[QCEliteTeam648]

@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.