LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

for loop iterator jumps from 0 to random number?

Solved!
Go to solution

Hello everyone,

 

I have a for loop with a auto-indexed tunnle coming off of it.  The for loop is set to run 240 times (4x / sec.), then the array when passed from the loop is averaged and data is played with from there on out.

 

It works great except for the first run which is throwing off data further down the line.  It will run anywhere from 20ish seconds to 50ish seconds.

 

If I put an indicator on the index it will jump from 0 to some number between 7 and 160 at random as soon as the program begins.  From there on out, after the first iteration it triggers every minute.  However the time stamps on all of the data are not on the minute, eg. 1:00, 2:00, 3:00, etc.  They are at some other interval, eg: 1:16, 2:16, 3:16 etc.

 

Why is it doing this?

 

My guess is that the array being output has some sort of memory of the previous runs, and is filling the first n slots with stored data and starting  the iterator up at the next avaialble index and continues on from there.

 

Is there a way to reset the data stored in the tunnle?  I'm not using a shift-register.

 

If I change to a shift register and try to pass the data to the summing function from the output shift-register, there is an error on the output and gives me a bad connection.

If I change to a shift register adn try to pass the data to the summing function from the input shift-register, it will work but continues to count from the arbitrary point.

If I change to a shift register and try to intitialize the array by connecting a constant of 0 to it, it still continues to count from the arbitrary point.

 

Any help would be greatly appreciated.

 

Thanks.

0 Kudos
Message 1 of 10
(4,044 Views)

Would it be possible for you to upload your code or an image just so we can get a good picture of what you are working with?

 

In terms of memory of previous runs, if you set the aray to automatically index at 0 then that is where the data should be being stored.

 

How are you doing your timing, using timestamp matching or with clock ticks?

 

What is the erro that is produced when you use a shift register? I would recommend shift registers for storing data but it depends on your context.

0 Kudos
Message 2 of 10
(4,027 Views)

Are you talking about an application running on a real time target?

If not, loop time is never deterministic, and jitter of 1s or higher is very possible on non-real time systems....

 

Also, your description doesn't give me an impression about "what your issue is" therefore, please attach your code.

 

thanks,

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 3 of 10
(3,992 Views)

Thanks for the help thus far!

We've been probing this all morning and to no avail, so here is the VI.

 

The problem arises when the loop reaches 240 and then resets.  When we're using the shift-register (which we got to work) instead of counting from 0 - 239 it now will not execute from 0 - 110(ish) and then resume, while when it was autoindexing it would only do this on the first iteration.

 

We're stumped.

 

Thanks!

Download All
0 Kudos
Message 4 of 10
(3,947 Views)

Is it possible that the computer is continuing to receive and buffer serial data while your code isn't running, so that as soon as you start the LabVIEW VI it gets flooded with serial data which it procceses as fast as possible? While I would expect that configuring the serial port would clear anything in the buffer, I don't know if that's actually the case. You could try checking for bytes at the serial port immediately after configuring the serial port and before the while loop, and if there is any data flush or read it before the while loop starts.

 

Also, why do you say it's configured to run 4 times per second? There's no timing structure in your code, so your code is running as fast as possible limited only by the serial communication.

Message 5 of 10
(3,925 Views)

Ok, 

1st off, There is no form of timing in the loop so your data is just being pulled down as fast as it can, which may generate some very odd/missed readings from the visa. I would recommend a 100ms timing delay in the for loop.

 

2ndly, I would also recommend using the VISA bytes to be read  VI instead of just guessing at the 50 bytes to be read. 

 

If you add in the timing then the loop count looks like it should just run from 0-239 consistently. Let us know how it goes once youve done that.

0 Kudos
Message 6 of 10
(3,924 Views)
Solution
Accepted by topic author IAmWhil

What is the format of the data being sent?  Does it use line feed as the termination character? Does it send continuously?

 

If it is using line feed for termination, then your configuration is correct (although the byte count = 50 may not be best). You should not use Bytes at Port when termination characters are enabled. With termination characters the VISA read sets the timing to match the data being received.

 

With the default settings of Configure it will take approximately 50 ms to receive 50 characters. If the messages are shorter than 50 characters, the delay will be less. Two examples: 1. Device sends continuously and the date set never has a line feed character. Read will return 50 characters approximately every 50 ms. 2. Message consists of 8 data characters plus line feed. The device pauses between messages and sends 4 messages per second. Read will return 8 characters 4 times per second.

 

My guess is that your device sends continuously and that something else in the program allows some data to build up occasionally so that when this VI starts a batch of messages are in the buffer and get processed fast enough that you do not see the loop counter increment.

 

Lynn

Message 7 of 10
(3,911 Views)

Additionally, because your loop is running 20 times a second or more, your Loop Counter indicator will be updating faster than it can be displayed. This is probably why it appears to jump to random numbers.

 

MC

0 Kudos
Message 8 of 10
(3,877 Views)

Thanks for the help!

 

So the solutions that we got working:

We were able to change everything over to a shift register and initialize it to zero and have it work with the back end of the program.  Minor.

 

The major problem was it pulled data as fast as it could and that was tossing in the odd errors.  As soon as it jumped out of the loop to process the array the buffer would then fill, that's where we were getting the ~100 ms lag.  Once the loop started it tried to do something with the data, which made it appear the program was locking up for those 100 ms.

 

We fixed these two issues by putting a time delay into the loop itself, and we then put a clear visa buffer outside of the for loop.  That way when the loop started everytime there would be no sludgefen of buffered data to mess things up and the timing in the loop would let us run it for a designated amount of time.

 

As for the termination character the online CO2 analyzer tosses some random number of ! points (its 20 years old), anywhere from 1 to 6 which breaks the data into chunks.  We're simply removing those, and the last 5 digits of the data are what we're looking for.

 

Thank you all so much!  Project status: back on line!

0 Kudos
Message 9 of 10
(3,812 Views)

@IAmWhil wrote:

We were able to change everything over to a shift register and initialize it to zero and have it work with the back end of the program.  Minor.


Glad to hear you got it working. No idea what your final code looks like so this quick comment is based on the images you posted before. If you're using a For loop and you want an array output with one element per loop iteration in order, use an auto-indexing tunnel, and not a shift register. It's better style and might be more efficient.

0 Kudos
Message 10 of 10
(3,788 Views)