Hello!
We have been using our robot normally in the last few days, but after integrating the automous mode to the code we have been experiancing a response delay during teleop mode. This delay disapears if i remove the automous mode and i am usong labview. Any tips on what could be causing it?
The Charts tab traces what code runs when. It may be helpful to review to see that Auto actually stops when the period is over. If you zoom in it will also show if you are skipping processing teleop packets and shows CPU usage, communication loss and latency to see if that is involved.
If you don’t make progress with this extra data, please post an image or the log file.
It may also be useful to use the Support Code folder in the project. It contains a timing VI that you can crop into various loops. When running, you can open the panel of the VI to see the period of the instrumented loops.
Greg McKaskle
Hello, Thank you for your quick reply! Before bagging our robot i was able to run some tests and there is some packet loss as well as the following error on the driver station:
ERROR <Code> -44061 occurred at “Left and Right Motors” in the VI path: Robot Main.vi
<time>03:01:28 02/19/2014
FRC: The loop that contains RobotDrive is not running fast enough. This error can occur if the loop contains too much code, or if one or more other loops are starving the RobotDrive loop.
Also, after redeploying the code without the autonomous mode the delay reamaied, so it was not really the one causing it. I understand that some loops on my code might be starving it, but i cant really find any.
Im attaching my code and the last log file if it might help.
have you inverted the motors by switching motor leads? If you’re using jags and switch the motor leads to invert direction it starves the RD loop. What language are you using?
The software (and the Robot Drive loop) doesn’t know anything about inverting motor leads, and inverting motor leads will not affect the software.
You say that… yet it has happened to us. We switched the leads to invert the motor direction and that was what was hurting the robot drive loop because it stopped glitching out once we rewired everything correctly
I looked through the charts, and the CPU is almost always pegged. During Teleop and during Disabled. That means that expensive code is probably in Periodic. That doesn’t really make sense with the code I’m looking at. You only attached the dsLog file and not the dsEvent file, so what I don’t know is how many errors were being thrown.
I don’t have a cRIO at home, but luckily, your project uses simulation. I ran your code and I’m seeing that your periodic code is failing to open a solenoid and Motor refnum, but is then setting those anyway, and possibly at a pretty fast speed. Those sets are obviously failing, which would cause your robot to not operate properly, but even worse, the errors bog down the CPU so that your teleOp code has issues.
I think you will be able to find the issues pretty easily. It is most likely that the names in Begin and Periodic no longer match, or it is possible that some of the I/O was closed somewhere in the program. It may be easiest to open Periodic and set it to highlight. Turn on the light bulb at that top of the window. This slows it way down, and then you can see immediately when the error is sent to the DS Diagnostic tab.
Boa Sorte.
And if you fail to find the issues, let me know and I can help identify which of the refnums are causing problems.
Greg McKaskle
I see Two DIO 3’s are defined in Begin.
It looks like the problem is with Periodic Tasks sucking up all your CPU.
It’s probably because one or more of your 20ms loops takes more than 20ms to execute regularly.
I suspect Engatiha e atira, because the bad DIOs get checked there every 20ms.
Greg has provided a nice tool that you’ll find in your project window under Support Code called Elapsed Time.
You can drag & drop an instance of that into each of your loops (and feed it a unique name so you can tell which one it is) to see how fast they run in the Debug front panel of Elapsed Time.
Any of your loops that regularly take much (the loops will always be a few ms slower than the time you set) longer than the 20ms or whatever delay you gave them, will occupy your CPU 100%, because they never get a rest.
Hello, i have added the elapsed times vi to the periodic tasks loop and discovered that they were running at around 80-100ms, while the delay time on them was only 25-40ms. So i increased these delays to 100ms and most part of the errors stopped, but i was not able to locate the refnum errors that greg mentioned, how can i locate and fix them?
thank you so much for your help guys!
You have two different devices called “Garra”
One is a solenoid and the other is a motor.
That’s going to be causing trouble and driving up the loop time on one of your Periodic Task loops.
After you get rid of the DIO and Solenoid/Motor errors, go back and look at the loop times again.
They should drop back to a more normal range.
P.S.
See you again at the Long Island Regional!
Thank you so much! I was able to run some tests on our test robot and everything is running smoothly! The loops on periodic tasks are running at about 60ms. It is amazing how simple it was to solve such a problem!
Thank you so much again for your help! You guys are awesome!
See you at SPBLI regional!
Oh, OH!
Code alert.
So you’re saying that I can’t use the same name for two different refnums, even if they are different types?
For some reason I assumed that since I need to use specific instances of the put and get refnums for different devices, the name pool for these different devices were unique… but sounds like not !!! Dumb me!!! I also called both the motor and solenoid for the Collector “Collector”.
Yes, I’m doing this and yet they “appear” to work… I may be getting mass errors… but the devices do work… How is that possible?
Phil.
The electrons don’t care what color the insulation surrounding the wire is. Inside a brushed DC motor the electric “pathing” is identical, both “forward” and “backward”. Wiring the motor in reverse is not harmful, and has no impact on the performance, as CIMs are designed to go CW (Red-Black/Black-Red) just as efficiently as CCW (Red-Red/Black-Black), but it is bad practice to use the former.
If the leads going into the Jags were wired in reverse, the magic blue smoke monster gods were not frowning on you, which is surprising, because they are not a cheerful bunch.
Perhaps by rewiring the robot you fixed a problem you did not know you were having (like a lose sidecar or D-Link wire)
You’re right. They shouldn’t conflict.
The named refnum repositories are unique per i/O type. If you really do have a Collector that is a motor and another as a solenoid, that will not produce code errors. Communications errors with the rest of the team, perhaps. But it was designed to support what you are doing.
If you ask for the RobotDrive named Collector, that will produce an error because you didn’t store a refnum of that type with that name.
Greg McKaskle