[aeastet]

Hi Bradley,

Did you get a chance to look a the code I put together? Do you have questions?

Greg,

I do appreciate that sometimes code does not have to be rewritten if it works no matter if it uses good programming styles or not. It was not my intention when I started, to rewrite the code for this team. The more I dug into the code the more problems I saw. It seemed easier to fix the problems and make the code easier to read then to try to keep scrolling back and forth to understand the code. As I made things easier I found mistakes that I would not have found if I just let the code alone. They were calling a joystick that was never established in the begin file. They were call for a solenoid valve that was never established in the begin file. They were enabling and disabling some motor controllers in teleop. This is part of the reason the code was running slower than expected. Even if I did not change how the teleop timing was working the code is easier to read and easier to edit. I try to teach LabVIEW programming classes every summer to local teams in my area.

I also thought it would be a good opportunity to show them how to use proper programming techniques. This will help them write better more efficient, easier to maintain code in the future. I think LabVIEW gets a bad wrap around this forum because people feel that it does not work well. Part of the problem is that people are not using it to the best of its' abilities. LabVIEW is easy to use. That is a strength and a weakness. People think that they have figured out how to use LabVIEW just because they get something to work. I do not work for National Instruments but I have over 16 year of programming experience with LabVIEW and I try to help people see how easy and efficient it can be if done with good programming standards.

That is why I published our code every year and why I took the time to help these guys out.

Tim