01-19-2010 05:45 AM
Hi Oliver,
mostly a freeze comes from to much memory usage. Therefor the date has to be stored in another location and this slows down the system.
When you increase the sample rate you have mor samples in your array, so if you use the build array fuction you're allocating more memory. This is why I was asking for the replace array subset fuction and the code.
You can avoid this behavior if you initialize every array you're using in the acquisition loop or if you're writing your data to file instead of storing them in an array.
Kind regards
Carsten
01-19-2010 06:25 AM
Hello Erin,
we need to have a frequency of 20MHz, that was the reason why we got the 6534. We tested the card and up to 25MHz it is working stable. So we know that there is still space.
Meanwhile we changed the complete system, the sensor unit, computer card, 6534, everything. And we got the same results.
We have six systems running in the same configuration at other customers and they are running perfectly. That was the reason why we thought that it is a EMC problem which comes over the clock line into the computer.
To be absolutely sure that it we have some more safetey, we will change over to a PCIe system and a 6536 card. But generally this cannot be the solution.
We have to know why this happens to know what to do if the same problem occurr at the six running systems
Oliver
01-19-2010 06:34 AM
Hi Carsten
You
can avoid this behavior if you initialize every array you're using in
the acquisition loop or if you're writing your data to file instead of
storing them in an array.
> mostly a freeze comes from to much memory usage.
The computer can freeze if I use to much memory? I didn't know that.
> When you increase the sample rate you have mor samples in your array,
Why do I have more samples? At the Dig_Block_In Function I define the number of samples I want to get. Independent of the frequency. Isn't that correct?
> ...write to a file...
It is not possible to write to a file because i have to make 3 measurements a second. Writing to a file and reread it is to slow.
Greetings
Oliver
01-19-2010 07:59 AM
Hi Oliver,
yes indeed, if you're using more then the set system memory a swap file will be created to store all the data. This operation slows a system down can can cause a freeze.
If you are increasing the sample rate I thought that you're also increasing the number of samples to read. Or does your acquisition loop run faster now?
If your acquisition loop runs faster now is your array still big enough? Can you track the array position you're writing to? Is it still in range? I did some testing and found out that writing to larger indizes then allocated will cause CVI to write the data anywhere in the memory. This could be also a reason for the freeze.
Kind regards
Carsten
01-19-2010 08:32 AM
Hello Carsten
> yes indeed, if you're using more then the set system memory a swap file will be created to store all the data.
Correct. To avoid that we have 4GB of RAM in the computer and increased the tempfile from windows.
We have a performance check in the software which normally shows us if there is a problem with the performance. Until now we didn't find a problem
> This operation slows a system down can can cause a freeze.
OK, I didn't know that. It is a good point to check
> If you are increasing the sample rate I thought that you're also increasing the number of samples to read. Or does your
> acquisition loop run faster now?
Normally at the start up of the software we measure the conditions and calculate how many samples we need. Afterwards this is not changed any more. So normally the frequency is 20MHz, and the number of samples is constant.
> I did some testing and found out that writing to larger indizes then allocated will cause CVI to write the data anywhere in
> the memory. This could be also a reason for the freeze.
Correct. We have a function which checks the number of samples taken and if the number is not bigger than the array. Generally the application is running in that way all ober the day, except the two times when it is freezing.
In our opinion the application is generally ok but there is an exception which causes the problem.For this reason we though it can only be the 6534. During our tests we found out that the card has a tolerance in the sample frequency up to 25MHz (what is very good), but from a point above the computer freezes.
regards
Oliver
01-20-2010 07:51 AM
Hi Oliver,
which controller and which chassis do you use (at the customer's and in your test environment) ? Are there any other boards in the chassis?
If I got it right your customer gets the freeze twice a day when running the system at 20 MHz. You're getting the error when running the system >25 MHz?
Kind regards
Carsten
01-20-2010 08:01 AM
Hi Carsten,
> which controller and which chassis do you use (at the customer's and in your test environment) ?
The controller is from EKF named Boogie, a Dual Core Pentium with 2.5GHz, 4GBRam
The box and the backplane are from Hartmann
> Are there any other boards in the chassis?
No it is only the CPU and the NI 6534
> If I got it right your customer gets the freeze twice a day when running the system at 20 MHz.
Correct, the application runs contuniously at 20MHz
> You're getting the error when running the system >25 MHz?
during our tests the card ran properly up to 25MHz. When we increased the frequency up to 32MHz the computer freezed.
In the moment we are preparing a test to change the pulse wide of the clock signal to see how the system reacts. We think that there is somewhere a jitter in the signal which can cause the problems
Regards
Oliver
01-20-2010 09:59 AM
01-21-2010 07:31 AM
Hi Carsten,
unfortunately we found out that the pulse wide jitter is not the problem. We are still searching but what we know now is that depending on the signal which we input in the 6534 we can freeze the complete computer.
We are still searching the reason....
Greetings
Oliver
01-21-2010 10:18 AM
Hello Oliver,
in one of your previous posts you wrote:
We have six systems running in the same configuration at other customers and they are running perfectly. That was the reason why we thought that it is a EMC problem which comes over the clock line into the computer.
Does this mean you are using a external clock Signal?
If so can you take a look at the Signal using a "Oszi"?
Mabee there is a lot of noise on this line causing the board to see some extra edges.
Regards
Moritz