buffer overflow

[sergueiK]

I have created executable file, tested it for several days on my laptop and send it to the customer together with hardware.

As soon as he received it he  faced buffer overflow problem.

Is it possible to eliminate this poblem?

When this error appeares the part of the program that does acceleration analysis still workes but signal generation stopped.

Unfortunately I do not have this hardware  so I have to modify the program wihou testing it.

What are the ways to avoid buffer overflow(one of them is probably just to use DAQmx configure input buffer but I do not know where to insert it and how configure it).

[TWGomez]

The code is a bit messy, and its a little hard to fully follow it, you may want to buy a style guide "The LabVIEW Style Book" by Blume is my personal favorite. You also should consider switching your design pattern to a queued state machine, or producer/consumer (w/ Events is my personal favorite there).

As for the overflow you modify the buffer before you initialize, so in the current case structure you are initializing (before the initialization), would be a good place to put it in its current architecture. Configuring it requires more info, mostly from your equipment manual.

Also coercion dots are a bad thing (I saw several), everytime you see one of those memory gets copied and causes slow downs in your execution, and ever so slightly possibly overruns in RAM (due to not enough memory).

Your loops have no wait time, and could suck up way more CPU processing time needed, which could mean one loop is using all the processor, and the other gets none. Also you need a data dependancy wire going into the second loop to ensure execution.

[RavensFan]

You definitely need to pay attention to how you arrange your wires.  In several places, they flow the wrong way and it makes inputs look like outputs and vice versa.

You have some features that would be eligible for the Rube Goldberg thread if it wasn't for the fact there are already numerous examples for it there already.

You don't need to feed a comparison function into a selector statement that just puts out a True or False, the original comparison already does that.  Instead of having separate true false case that just multiply a number with a constant, place the constants in the selector.

Message Edited by Ravens Fan on 04-07-2008 10:23 PM

[sergueiK]

Thanks a lot guys for your comments.

I agree that my coding is far from being ideal and expert like. I am doing LabView programming once a year and each time it is different hardware and i have to learn each time how to write the VI as i already forgot how I did it last time.

I always thought that the forum is the place where the people are helping each other. Some forums are for fun, I agree. But we do not want NI forum be alike a fun forum. When we post our problem we are looking for solutions and useful comments.

I could always ask NI support engineer for help but in that case when someone faces simiar problim he will not find the answer in a forum as it will not be posted here.

But can we try to go close to the point: is it possible to figure it out why  the code I have written creates Buffer Overflow error?

If some part of the VI is not clear for you ask me and i will try to explain it.

[sergueiK]

As for the overflow you modify the buffer before you initialize, so in the current case structure you are initializing (before the initialization), would be a good place to put it in its current architecture. Configuring it requires more info, mostly from your equipment manual.

I do not completely understand what changes should be done, may be you could show me an example?

Also coercion dots are a bad thing (I saw several), everytime you see one of those memory gets copied and causes slow downs in your execution, and ever so slightly possibly overruns in RAM (due to not enough memory).

I did not notice the before. What is the way to eliminate them?

Your loops have no wait time, and could suck up way more CPU processing time needed, which could mean one loop is using all the processor, and the other gets none.Also you need a data dependancy wire going into the second loop to ensure execution.

When i have tried to pass data from the bottom loop to the upper one the system reacted unexpectedly. It runs one of the loop and another one either did not work or worked with interruption. For this program the critical thing is consant signal generation and the sine should be as ideal as possible.

[TWGomez]

OK here is a PNG file for you. The data dependancy I was talking about is illustrated by the error in. It just ensures that the two loops start at roughly the same time. The ms wait function ensures that the loop does not suck up all of the processor (each loop that does not have an event structure or timed loop needs one) . The extra function in front of the initialize routine will set the buffer to the maximum size for the equipment.

[TWGomez]

Oh coercion dots appear when you perform calculations or inout items with different data types/representations, so make them the same data type/representation and the dots go away.

For example if you multiply an i16 and a i32 you have a coercion dot, so you would want to make them both i16 or both i32...

[RavensFan]

---

sergueiK wrote:

I always thought that the forum is the place where the people are helping each other. Some forums are for fun, I agree. But we do not want NI forum be alike a fun forum. When we post our problem we are looking for solutions and useful comments.

---

I should have dropped a smiley/winkie  in my post.  Even though the Rube Goldberg thread is for fun, it is also informative too and worth reading.  It is a list of examples of what not to do when coding.  It's always better to have cleaner, more efficient, and easier to read code.  It helps you while programming and others if they are trying to assist you.  So when you post code, you can probably expect to get a few "do this instead" type responses as well as ones directly related to your question.  It looks like TWGomez has already given a couple of useful suggestions as to how to fix the buffer overflow error.

[sergueiK]

No problem with the comments.

I have cleared it a bit so hope that it will be a bit easier to understand.

[RavensFan]

Here is what I see is happening.

You are using DAQ assistant in the 2nd loop to acquire 1000 samples at 1000 Hz  It is set for continuous samples.  So that will take a second.  Then the data is passed of to the other functions.  I don't know how long they would take to run, but they are pretty substantial.  (By the way, your write measurment file as no data going into it.)  If it takes longer than a second, then the DAQ functions which have been continuing, will have the buffer overwritten and you will get the error.

You could ignore the error, but that also means you've lost data which may or may not be important.

It is better to pass the data off into a queue.  Let another parallel loop do the number crunching and saving to file.  Search the labview help and the discussion forums for producer/consumer design architecture for examples.  With only the DAQ assistant in the loop, you will get all of the data.  The only risk would be if the queue would grow without bounds in the event that each chunk of data still takes longer than a second to process.

Putting a wait statement in the top loop as well will help.  Without a wait statement, a loop will run as fast as it possibly can.  Since you are mainly reading a local variable and some controls such as the stop button, you probably don't need to run instantaneously.  Even a small wait of a few milliseconds can help yield processor time to other loops.

In your top loop, you are recalculating the waveform and writing it to the analog output on every iteration.  It would be better to put that code in a case statement that only executes in the event the values change.  I believe with continuous samples, and if you allow that channel to regenerate its data, the analog output will run continuously without needing to update it every iteration.

Also, please move your front panel down and size it to fit closer to the front panel controls. For some reason your VI appears with the title bar off the top of the screen.

Message Edited by Ravens Fan on 04-08-2008 01:33 PM