Robot Drive Not Running Fast Enough - PLEASE HELP!

[Bradley Boxer]

Originally Posted by aeastet

Ok here is my first round. I have done a lot so I am not going to tell you everything should work on the first try. I am still working on autonomous and I will update that as soon as possible. I have a lot of it done already. I am also trying to make the code do what I think you are trying to get it to do. I am available for questions.

https://www.dropbox.com/home/2016CompRobotProject

Good Luck,

Tim

That link doesn't seem to work for me. Can you make it a sharing link instead of just a copied url? Thanks again.

[aeastet]

Try this one:

https://www.dropbox.com/sh/d12jln54w...k9WlFBo7a?dl=0

[aeastet]

I edited a lot of things in your code. I added functional globals or action engines as I call them. I reorganized the timed tasks to make the dashboard updates less often. I then added the action engines to get the data that you collect and store it for use everywhere else in your code. I updated the teleop vi. I think there is still more we can do there but I wanted to get this into your hands now so you can start to see and try understanding what I did.

I started working on the auto mode. I got through a lot of it. I am trying to do my best to understand what you were doing.

Again let me know if there is anything else I can do to help you understand what I did.

Tim

[Greg McKaskle]

This thread seems to be trending into a "alternative ways to write the same code" thread. But the original post was about performance. Nobody is talking about performance.

LV is a language. There are infinite ways to write something. There are tradeoffs to each of those solutions. Rewriting code to be different without measuring and addressing the goals -- in this case, performance improvement -- is not good engineering.

When I loaded the code several days ago, it was broken and I didn't have much time to spend on this. Has someone, anyone, run this code to make basic measurements? Without this data, everyone is making recommendations on hunches or past experiences. This doesn't need to be theoretical work.

Greg McKaskle

[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

[Greg McKaskle]

I appreciate your willingness to help teams, and I don't doubt your abilities to write good LV code.

I was making the observation that this thread, like a good number of others, seemed to divert from the original question. More importantly, it is key to make measurements for topics like this one, and I didn't see any discussion, still don't see discussion of code performance -- other than adjectives such as faster.

Case in point, functional globals, or action engines if you want, can be quite a bit slower than a simple global, or they can be faster for some access patterns. They are a great technique to learn, but not necessarily for performance, and not necessarily required when a simple global is good enough.

Please don't let my comments dissuade you from helping teams with their programming. And a summer training course is a very ambitious project. Thanks for doing it, and good luck. Let me know if I can help in some way.

Greg McKaskle