Robot Drive Not Running Fast Enough - PLEASE HELP!

[Bradley Boxer]

Our code this year (written in LabVIEW) runs really slow. Extremely slow. I have taken out all the refnums in teleop and in periodic tasks, but this did not seem to help. This would normally not be a problem, but we have several (4) PID loops update in teleop (running on CAN Talon SRX's), and if they are not updated every ~120ms they will tell the motor to stop spinning. Right now, teleop runs every ~100-200ms (measured with "Elapsed Times.vi"). This is a huge problem when we are shooting and need our two wheel motors to spin at exact and fast speeds. Although at this point in the season we aren't adding much code, the problem seems to be getting worse. It also may be worth noting that we are using the LabVIEW 2016 Vision Example to find the goal coordinates, although it is disabled with a global variable when not in use.

Does anyone have any fixes/ideas/suggestions/tips as to how to speed up our code?

Here is the link to Team 303's LabVIEW Robot Code if it helps anyone. Feel free to redistribute if you so please.

https://drive.google.com/file/d/0B9k...ew?usp=sharing

Thanks so much,
Bradley Boxer
Team 303 Programming

[Alan Anderson]

I am unable to try out your code. You are using several Vis that are not included in your project or in the WPI library.

Are any error messages shown on the Driver Station message display? Catching and displaying errors slows down a LabVIEW program.

It looks like you are doing a lot of Talon SRX status checks in Teleop. Do those all need to take place every time a data packet arrives, or can you move some of the processing to Periodic Tasks?


Your Teleop is very busy and I'm finding it a little hard to follow without signposts. It all looks connected in a big collection of wires. Are there any functional groups that could be split out into individual SubVIs? That might clean up how the code looks and make it easier to understand.

[RyanN]

@Alan - You need to install the NavX library to have his code load properly.

Looking at Teleop... Oh my...

There is a lot going on here. Forgive me if I miss something. Generally, when your code starts getting really complex, it's a good idea to start creating SubVIs. It makes the code a lot easier to understand.

I'm not seeing anything that stands out. The only Wait blocks you have are in Periodic Tasks, which is good.

Are you trying to run this as built code or by pressing Run on Robot Main? I've experienced slow downs when running Robot Main if I have too many running LabVIEW windows open. This occurs because it has to sync all the values from the robot back to the front panel, and the issue gets worse if your are probing values as well. I can see how having just the Teleop window open might cause it to lag since there are so many Front Panel controls and indicators to update.

[Greg McKaskle]

I didn't try to run your code, but just looked at it.

Please run the code and give some indication of CPU usage from the DS chart. If your usage is high while the robot is disabled, your periodic tasks may be running too fast or doing too much.

If teleOp has high CPU usage when the panel is open, it is because you have lots of debug info shown and updated frequently. When you run without opening the panel, it should be far better, and will be better still when built and deployed.

Don't forget that you can also put the Support Code/Elapsed Times into your teleOp code to see how often it runs. Your log file will also how how many of your teleOp control packets are not being processed.

Please post some more data and I'll be happy to make a suggestion.
Greg McKaskle

[Bradley Boxer]

Thanks guys for your help.

I split Teleop into a few more subVIs and used the clean-up-diagram button, so it should be more readable now. I also took out most of the debug indicators and controls, and necessary Talon SRX get status', since we don't need them anymore. We were running the code from a build-deploy, and we got "Not running fast enough" errors a few times every second as of yesterday.

I will test again today and post logs when I get to our workshop.

If you want to look at the new code:
https://drive.google.com/file/d/0B9k...ew?usp=sharing
I added the navx libraries this time.

[The_Waffleing]

Originally Posted by Bradley Boxer

Our code this year (written in LabVIEW) runs really slow. Extremely slow. I have taken out all the refnums in teleop and in periodic tasks, but this did not seem to help. This would normally not be a problem, but we have several (4) PID loops update in teleop (running on CAN Talon SRX's), and if they are not updated every ~120ms they will tell the motor to stop spinning. Right now, teleop runs every ~100-200ms (measured with "Elapsed Times.vi"). This is a huge problem when we are shooting and need our two wheel motors to spin at exact and fast speeds. Although at this point in the season we aren't adding much code, the problem seems to be getting worse. It also may be worth noting that we are using the LabVIEW 2016 Vision Example to find the goal coordinates, although it is disabled with a global variable when not in use.

Does anyone have any fixes/ideas/suggestions/tips as to how to speed up our code?

Here is the link to Team 303's LabVIEW Robot Code if it helps anyone. Feel free to redistribute if you so please.

https://drive.google.com/file/d/0B9k...ew?usp=sharing

Thanks so much,
Bradley Boxer
Team 303 Programming

So one of things that you can do is remove all the get/set refnums in you're project and bundle them together like you have done but make it a type def. I'm currently busy with other things so I do apologize if I'm not going into very much detail, I'll sit down a write a proper response to your request however I will leave you with a link that another user had passed along to me when I was trying to optimize my code. Hope this helps!

http://frclabviewtutorials.com/teleop/

[Greg McKaskle]

I looked at your updated code, and still don't see anything that scary. Moving the code into subVIs helps readability, but won't affect performance.

So do you have CPU numbers? Do you have a log file? Do you have an elapsed time for TeleOp?

The only thing that looks like it may be excessive is the amount of stuff you have inside the 10ms periodic task. Doing NavX and CAN status and quite a few network tables may add a pretty hefty background load which would be present even during disabled mode. So if we see the logs, I can know roughly what that takes.

Greg McKaskle

[The_Waffleing]

Originally Posted by Greg McKaskle

I looked at your updated code, and still don't see anything that scary. Moving the code into subVIs helps readability, but won't affect performance.

So do you have CPU numbers? Do you have a log file? Do you have an elapsed time for TeleOp?

The only thing that looks like it may be excessive is the amount of stuff you have inside the 10ms periodic task. Doing NavX and CAN status and quite a few network tables may add a pretty hefty background load which would be present even during disabled mode. So if we see the logs, I can know roughly what that takes.

Greg McKaskle

This might be a ridiculous question to ask but would finding a way to move the majority of this stuff to a state machine be of any use when trying to make the code efficient? I feel like there's a few things that could probably go without the constant update that the Teleop.vi has. Do point out if I'm wrong in this case. Also Bradley, I've noticed that there are some unused values in your teleop code that can be attributing to the whole clutter issue that is evident in the project overall; I would assess whether or not you need those values anymore. Great job on your code however I've had fun puzzling your code out and have been able to glean a few concepts from this that are rather interesting and will keep a note on them for next robotics season. I'll continue to with my efforts and will point out anything that I see that might want to be addressed.

[RyanN]

Originally Posted by Bradley Boxer

Thanks guys for your help.

I split Teleop into a few more subVIs and used the clean-up-diagram button, so it should be more readable now. I also took out most of the debug indicators and controls, and necessary Talon SRX get status', since we don't need them anymore. We were running the code from a build-deploy, and we got "Not running fast enough" errors a few times every second as of yesterday.

I will test again today and post logs when I get to our workshop.

If you want to look at the new code:
https://drive.google.com/file/d/0B9k...ew?usp=sharing
I added the navx libraries this time.

I'm still not seeing anything that would ultimately cause the "Not running fast enough" errors. As The_Waffling said, you could replace that huge Refnum cluster to all the Joystick, Motor, Robot Drive, Solenoid, and Encoder Refnum_Get functions. If you're debugging, those controls will still get updated and that is quite a few front panel controls to update every 50ms. Keep in mind all of this is going over the network.

You should definitely check your CPU usage like Greg said. If you're running at 100%, that will likely cause you issues. You can easily check that using the Driver Station or you can Profile your program within LabVIEW while it's running on the target.

[Greg McKaskle]

The CPU and elapsed time of teleOp are hard numerical quantities that will help you diagnose if you have a problem, and what that problem likely is. It is like the doctor taking your temperature and blood pressure. If you don't measure these things, you may very well be trying to fix something that isn't broken or making something worse.

I glanced at your code and didn't see anything horrible. The next step is to measure. Without that, we quickly get into code poetry and opinions. I much prefer to stay on the engineering side of programming. So, please, when you have access to the log files or the robot, post the CPU usage for a couple robot modes. Look at or post some log files. And if you think you have an issue with teleOp, add the Elapsed times VI, run the code, start teleOp on the DS, and open the subVI to see what the elapsed time is.

Greg McKaskle

[The_Waffleing]

Originally Posted by Bradley Boxer

Our code this year (written in LabVIEW) runs really slow. Extremely slow. I have taken out all the refnums in teleop and in periodic tasks, but this did not seem to help. This would normally not be a problem, but we have several (4) PID loops update in teleop (running on CAN Talon SRX's), and if they are not updated every ~120ms they will tell the motor to stop spinning. Right now, teleop runs every ~100-200ms (measured with "Elapsed Times.vi"). This is a huge problem when we are shooting and need our two wheel motors to spin at exact and fast speeds. Although at this point in the season we aren't adding much code, the problem seems to be getting worse. It also may be worth noting that we are using the LabVIEW 2016 Vision Example to find the goal coordinates, although it is disabled with a global variable when not in use.

Does anyone have any fixes/ideas/suggestions/tips as to how to speed up our code?

Here is the link to Team 303's LabVIEW Robot Code if it helps anyone. Feel free to redistribute if you so please.

https://drive.google.com/file/d/0B9k...ew?usp=sharing

Thanks so much,
Bradley Boxer
Team 303 Programming

Okay so after doing a lot of clean up in the teleop in order to see what's going on, I noticed that there are some values that are being written in teleop to global variables but never read anywhere else. Is there any particular reason for doing that. another thing that you can do for your begin.vi is replacing the write global variable that you have going with a funcional global variable (FGV) since the only place your are needing all that information is in autonomous. Like everyone else has said though check your CPU usage and try to locate any logs that might be pertinent to this issue. The logs will answer several questions.

[aeastet]

I am working on a major upgrade to your code. Even if you choose not to use it you should look through it and try to learn from it. Do you have a place for me to put the code when I am done?

[b1nary]

we had an issue similar with our robot, trogdor. our autonomous wouldn't work one time because it was an issue with our talons. not with the coding itself, which everyone believed it to be, but the hardware.

[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

[Bradley Boxer]

Originally Posted by aeastet

I am working on a major upgrade to your code. Even if you choose not to use it you should look through it and try to learn from it. Do you have a place for me to put the code when I am done?

If you message me your email, I can add you to a google drive folder that our team has been using to transport and store code. Thank you!

Originally Posted by The_Waffleing

Is there any particular reason for doing that. another thing that you can do for your begin.vi is replacing the write global variable that you have going with a funcional global variable (FGV) since the only place your are needing all that information is in autonomous.

I don't quite understand how a functional global variable would help in this situation. We are only writing the variable once (in begin.vi), so why would the data need to be feed into a loop/shift register? Thanks for your help.