Go to Post If mecanum wheels are the answer, I have found that I have asked myself the wrong question. - jwfoss [more]
Home
Go Back   Chief Delphi > Technical > Programming > NI LabVIEW
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
 
 
Thread Tools Rate Thread Display Modes
Prev Previous Post   Next Post Next
  #8   Spotlight this post!  
Unread 27-02-2012, 16:42
PAR_WIG1350's Avatar
PAR_WIG1350 PAR_WIG1350 is offline
Registered User
AKA: Alan Wells
FRC #1350 (Rambots)
Team Role: Alumni
 
Join Date: Dec 2009
Rookie Year: 2009
Location: Rhode Island
Posts: 1,188
PAR_WIG1350 has a reputation beyond reputePAR_WIG1350 has a reputation beyond reputePAR_WIG1350 has a reputation beyond reputePAR_WIG1350 has a reputation beyond reputePAR_WIG1350 has a reputation beyond reputePAR_WIG1350 has a reputation beyond reputePAR_WIG1350 has a reputation beyond reputePAR_WIG1350 has a reputation beyond reputePAR_WIG1350 has a reputation beyond reputePAR_WIG1350 has a reputation beyond reputePAR_WIG1350 has a reputation beyond repute
Re: Robot Twitch

Quote:
Originally Posted by Chris Hibner View Post
We had a similar issue where the robot twitched every now and then (sitting still - type A) and there seemed to be a time delay from all of the operator inputs to when the robot would start moving.

We put ElapsedTimes.vi into the PeriodTasks loops and in Teleop. We found out that our fast loop and teleop were taking about 250 ms to complete!

At first, we couldn't figure out what the problem was. Our code was bigger than previous years, but we didn't think by THAT much. We don't use sub-loops. We had no idea what could be blocking the code and taking up so much time.

Then we figured it out - we had an analog input that was configured for an incorrect channel. That caused an error, which for some reason bogs down the entire system. We allocated it to the right channel and voila, our loop times bacame exactly what they should be. I've since confirmed this behavior with a missing solenoid card. It seems that any misallocation causes the system to slow to a near crawl.

So, there are 2 things to take from this:

1) Coming out of Begin.vi, check your error output (assuming you have all of the errors from the Open blocks going into a "MergeErrors" vi). Make sure you have no errors. If so, fix them - it just might solve your problem.

2) Greg: can NI do anything about this? It seems like bad failure mode that if a piece of hardware becomes dislodged or someone fat-fingers a channel number, it causes all of the code to become blocked for 200+ ms. Please don't take this as me being a big complainer - I think NI has done a fantastic job and much kudos to all of you for always being helpful.

(BTW: when it happened to us, we had two analog devices allocated to the same channel (copy and paste - forgot to change the channel #). I noticed it again when we were doing some code development on a second cRIO: our code uses solenoids but the second cRIO did not have a solenoid card installed.)
Assuming we don't use solenoids in the code, would not having the 24volt DIO module (the solenoid module) in the cRIO cause this issue?
__________________
Reply With Quote
 


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 11:16.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi