Labview pauses

[m3nth]

Why aren't URL's automatically linked? Is it just me or is it the forum? I have to cut & paste every time if I want to navigate to a link someone posts. rrrrrrr.....

[pete king]

The suggestions regarding page faults and memory allocations seemed to be right on target. I simplified and modified my vi and the Labview page faults remained constant for long periods of time instead of constantly increasing. Oddly enough, the modification I made seems innocuous. In the attached file “DIO107.vi” which is simplicity in itself, I had originally modified the library function DIOread.vi to add a connection to its inner workings to provide it with a dummy array to fill with data. I renamed it SILCRead1.vi. In my program, I first check the state of the DIO buffer by reading zero scans to determine the backlog and if the backlog is greater than the number of scans I wish to read, I enter the case structure to read them.
Originally, I had wired the dummy array to the input of both the DIORead.vi’s, the one which reads zero scans and the one that reads the data. When I had both wired, I got thousands of page faults/second. When I wired only the vi that actually reads data, the page faults stopped (pretty much).

Unfortunately, last night’s test produced 5 DIO errors similar to the previous ones so the problem is still there. The only changes I made from previous tests are not providing the “zero read” DIORead.vi with the dummy array to fill and I also changed the size of the DIO buffer to 30 Mscans instead of 15 Mscans.
I watched task Monitor for over an hour last night and page faults did not increase at all during that time and I had no errors. In the morning, they had increased by 107,590. Virtual memory size had increased by 3,404 K and 5 errors had occured during the night.

The times between errors are not as regular as they were. Instead of a uniform 1hr, 3min, 20+/- second interval, I got the following: 1:43:43, 0:43:10, 1:28:47, 0:31:19, 7:19:11 between errors.

As you can see my test program is ridiculously simple with no writes to disk anymore. I wonder if I should re-install Win XP. I would love to go back to Win 98 which did not have all the bells and whistles to get in the way, but I now only have LV 7.1 and it won’t run on Win 98.

LabView was the dominate process running last night using the most memory and 10-40% of CPU time. I have watched task monitor during the times the system freezes but it shows nothing. It is as if it freezes too.

I have disabled as many Windows processes as I thought safe, to no avail. I will run it again tonight without the LAN cable attached.

Any more suggestions?
Thanks,
Pete King

[tst]

---

@m3nth wrote:
Why aren't URL's automatically linked? Is it just me or is it the forum? I have to cut & paste every time if I want to navigate to a link someone posts. rrrrrrr.....

---

It's you, it's the forum, it's you, it's the forum, it's you, it's the forum, it's you, it's the forum, it's you, it's the forum, it's you, it's the forum.

It's the forum.

[m3nth]

That is a pretty simple program.

Whether or not it goes to the root of the problem, I believe the reason you were seeing excessive page faults is that LabVIEW had to make a copy of the array for each VI that was being called. It has been well optimized for handling these types of problems (deallocating memory when it doesn't need it anymore), but since I don't know the exact details of it, there is still the possibility that it is making a copy of the array every time it enters the DIO Read routine inside your case structure.

To maintain an array of constant size in memory that can be filled every time I had an idea which might or might not work. Well... might or might not work would be in regards to your overall problem being fixed.

To avoid passing the initialized array to your DIO Read VI you could simply pass it the array size the very first time it runs. Inside DIO Read, you would essentially make it an LV2 style global, wrapping the code in a do or for loop wired for a single iteration with an unitialized shift register. Using the Functions > Advanced > Synchronization > First Call? wired to a case structure, the empty array would then be intialized on the first call and passed to the function. The initialized array would also be stored in the outgoing shift register of the one-iteration loop. On subsequent calls, the shift register would pass through the case structure since it was already initialized.

That would keep from making a copy of the data every time the routine is called but then (depending on how optimally LabVIEW handles this), it may be taken care of already anyway. If it has nothing to do with that, the problem may be something else we haven't considered.