Labview-using timers to control motors

[stem2015preiman]

We are using Labview and are trying to do an autonomous program using timers with four wheel tank drive but if we use timers there is a time delay between the start of each side.

[Alan Anderson]

Without knowing what you're doing, it's hard to tell what is going on. Can you post a picture of your code? That would be a big help in getting you some useful advice.

Just a wild guess -- are you connecting your motor drive functions in series? That'll require each one to finish before the next one can start. Instead, connect them in parallel after the timer function so they all run at the same time. I don't know FTC well enough to have any idea whether what I'm saying makes sense for what you need.

[Sconrad]

Like Alan said, more info would be appreciated.

First thing to keep in mind: Autonomous is in a loop. If you want the code to pause at the end of each iteration (although I don't know why you would want to do that) just place the wait (Programming >> Timer) vi and set the time to wait in ms. If you want to case the code to wait for a time in between tasks, I would suggest using a flat sequence structure. Do one task (i.e. Set Motor Speed) and the put a wait vi in that frame and tell it to wait as long as you wish to continue performing that task. Note: do not use loops, it can push your compile time upward of a half-hour due to Labview having a problem with nested loops.

Hope this helps!

[Greg McKaskle]

If you have a VI that you can send to me that shows nested loops causing a 30 minute or even a 30 second compile of a single VI, please send it. In 20 years of using and writing LV, I've never seen this.

Greg McKaskle

[Sconrad]

Originally Posted by Greg McKaskle

If you have a VI that you can send to me that shows nested loops causing a 30 minute or even a 30 second compile of a single VI, please send it. In 20 years of using and writing LV, I've never seen this.

Greg McKaskle

I can't say I have any vis with nested loops because our team has avoided programming with them for the past several years due to a noticeable improvement in compile when they stopped using them. After doing some research(post-posting the previous post, say that five times fast ), it seems that this could have been a result of a trigger happy watchdog who wasn't being fed. I was not personally on the team, so I am spurting out secondhand information and it is possible that whatever was causing our problems has been fixed in more recent versions of LabView. I apologize if I am spreading false info on these forums and I realize I should have put a qualifier on that statement. However, our team has never had much of a problem avoiding nested loops, thanks to the ingeniousness of the folks at NI who added in a flat-sequence structure . Labview is my personal language of choice for frc regardless of whether or not nested loops are an issue because of its easy-to-learn interface and built-in tools and help.

[Alan Anderson]

Originally Posted by Sconrad

...I am spurting out secondhand information...

I think your information has probably been mangled in the retelling at some point. Much of what you've been saying has obvious errors in terminology, so it's possible that when you say "nested loops" or "compile time" you don't mean the same thing most of us understand by those words. It seems likely to me that your team's programmers were talking about long-running loops in the Teleop VI causing control lag or watchdog errors, and you simply misunderstood.

[Greg McKaskle]

I looked on snopes and it agrees, nested loops in LV do not contribute to long compile times --totally a legend . Glad to have this one behind us.

Greg McKaskle

[Al Skierkiewicz]

Alan and Greg,
The poster appears to be talking from an FTC standpoint.

[Greg McKaskle]

FTC usage was definitely not something I'd picked up on, yet you would still need lots and lots of nesting to impact the compile time. I am happy to look into VIs that show otherwise.

Greg McKaskle