LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Improving loop speed with Timed Loop

Hey Everybody,
 
I've got a little bit of an issue that I'm trying to work out:
 
I have a timed loop comprised of 2 sequences.  The first sequence measures the current position, compares that position to a position-velocity graph imported from excel, and then compares that commanded velocity to the current velocity to come up with a duty cycle to drive the motor at.  The second sequence adjusts the duty cycle appropriately.
 
Ideally, I'd like this to run as fast as possible within the 1Khz clock available (e.g 1ms dt -> 1khz loop speed would be great!).
 
However, when I run this, I find that the dt is actually around 65ms.  (I adjusted up to 70ms, because I use the dt to infer velocity as the change in position/time, and wanted to give myself a margin of error).
 
Is it possible to drastically speed this loop up?  Are there any array allocations that I could do to make this run faster?
 
I really appreciate any input you guys might have!
Thanks!
.jim
--
Jim S
GRA/Colorado School of Mines
Download All
0 Kudos
Message 1 of 6
(3,424 Views)
We can start with a few basic things and see how much they improve performance.

Here are my first thoughts:

  1. Why are there two frames in the Timed Loop? This really isn't necessary for anything. The main reason for using frames in a Timed Loop is to control the timing or priority of specific frames, which isn't happening here.  First, I would get rid of the frames.  You currently seem to be using the frame just so you can set a local variable then read it in the next frame. This leads me to point two:
  2. Avoid local variables. Use the data in the wire as much as possible, rather than using local variables. This will help performance, and avoids potential race conditions, which is where two parallel processes overwrite one local variable with conflicting data. For instance, with the Duty Cycle control, you set its value, then read it in the next frame. Simply wire that value through and delete those local variables. That control seems like it should really be an indicator, because the value is only set programmatically,  not by by users. And you never need a local variable for it. Wherever possible, use a wire value directly, or use a feedback node or shift register to save a value from one iteration to the next. These are both much faster and more efficient memory-wise than locals.
Here's a quick mockup of some changes you could make. I make no guarantee that this does exactly what you want, so don't hook it up to the motor without taking a very close look! 🙂 But it does demonstrate these ideas to an extent.

These two ideas might not get you down to 1ms periods, but they're a step in the right direction.
Jarrod S.
National Instruments
0 Kudos
Message 2 of 6
(3,407 Views)
I think the main processing time is not in this vi.
It is in your sub vi's
0 Kudos
Message 3 of 6
(3,390 Views)

Hi Jim,

I have been looking into your question and I have a few suggestions. I agree with Pnt that I think the main processing time is not in this VI but in a subVI. What we need to determine is which of the subVIs is taking up the most processing time. After that subVI is located, then we need to see how we can modify it to run faster. Just like the changes that Jarrod S. made with the main VI, there could be some changes we could try to implement with the subVIs as well. I hope this helps!

 

National Instruments
Applications Engineer
0 Kudos
Message 4 of 6
(3,362 Views)
Jarrod,
 
Thanks for the suggestions.  I wasn't able to open up the .vi you posted because I have 8.2, but I made the suggested changes and was able to shave off some time by kicking out the local variables.  I agree that the first frame in the loop isn't really necessary.  I did remove that, but it didn't seem to make a whole lot of difference. 
 
Thanks!
.jim
--
Jim S
GRA/Colorado School of Mines
0 Kudos
Message 5 of 6
(3,360 Views)

Pnt and CarlaU,

That is a good suggestion.  I already have subvi's where I handle separate portions, so I am going through those to try to evaluate what is hogging up all the time.

Thanks!

.jim

--
Jim S
GRA/Colorado School of Mines
0 Kudos
Message 6 of 6
(3,357 Views)