LabVIEW Page Faults Increase about 500/second

[Wiredup]

Anywere from 1 to 4 times/second depending upon the data.

[RavensFan]

You may want to consider using a waveform graph.  You would have to do your own array management by adding the new elements to the array on every iteration.  But with careful manipulation of the array you could initialize it to the size of your history, fill the elements using replace array subset, and once it fills up, do similar operations to shift the elements in the array and place the new elements at the end.  This should make is so that you have only one or two copies of the array in memory.  I think the waveform chart keeps adding elements, and even though the history is limited, it will constantly search for new memory space as the array grows.

[Wiredup]

Ouch...I didn't know that about the waveform chart. I just assumed... 

Anyway, I'll give it a try and post the results.

[rolfk]

---

@Wiredup wrote:

I've become way too familiar with the subtlties of callbacks in LabVIEW   with this project.

The callbacks are occuring from 1 to 10 times/second. There's 10 or so callback functions registered. The callback functions reside in an App-builder-generated DLL structured to match the C prototype of the caller's expectations. In some of these callback functions, there's a pointer passed to the callback. This pointer is used, along with length information, with the LV Runtime Engine function "MoveBlock" to copy the data at the pointer to LabVIEW-controlled memory space. The function is then closed, and the data is used from the copied location (now just a 'wire').

In the above, the pointer and known length are used to copy an array from the callback to a 'wire'. This array is flattened, tagged with the event type that generated the array, and flattened again to include in a LabVIEW User Event. The LVRT MoveBlock is marked as re-entrant (as is the callback DLL).

I'm guessing there's many ways this process could mess with Windows memory management...I just don't see how it could be made better to prevent the perpetual increase in Page Faults. Even though the PF's are not bad unto themselves, The quantity of PF's generated every second may be an indication of a bigger problem?

---

The way this looks I feel a bit itchy. A callback getting passed a memory pointer has to get the information from that memory pointer during its call duration. The caller of that callback is free to do with that pointer whatever it wants including deallocationg it, once the callback has returned. The way your diagram looks you have a DLL function that returns you the pointer that your callback function received. But at the time that DLL function returns the pointer, the callback function has most probably already returned control to its caller and the memory pointer is most likely reused for the next data or maybe just deallocated.

You do want to allocate a LabVIEW data buffer (array handle) in the callback instead and copy the info from the pointer in there and then pass that buffer to your LabVIEW diagram.

Rolf Kalbermatter

[Wiredup]

Rolf,

Thank you for the post. Is it wasn't for your prior posts over the years, I'm not sure I would have ever made it as far as I have in callbacks!

The code snippet above actually is located within the callback function itself (within a DLL). So long as processing focus remains in this callback, the caller-supplied pointer is safe. Once the copy is made (MoveBlock), the callback function can exit and the caller can do as he wishes with the pointer and associated block of memory.

Sorry for the confusion...please let me know if it still feels itchy.

[Wiredup]

Re-writing the vi to use an XY Graph instead of a Waveform chart had no impact on the 500 PF/Sec rate. Just reading the graph value and writing it back again (with no processing at all) causes the page faulting.  In fact, the only way to prevent the vi from generating 500 PF/Second (or more) is to slide the XY graph off of the screen so it is not displayed. Do this, and page faults stop. Slide the graph back, and page faults start up again. Same behavior occurs with or without smooth updates enabled and with or without Auto-Adjust Scales enabled.

This is (ancient) LV 7.1...no longer supported by NI...time to update?