could not perform this operation

[Craig_]

I wish I could point you to what is causing the memory error. I've been looking over the code for a while now and there's not much I can conclude.

Putting time into a rewrite could make developing this program much easier (this is essentially what a refactor is). There are a lot of methods and examples available that I think will help a lot.

[tavwtby]

Iam going to try the executableon a different machine before I refractor. I have looked over this code and eliminated all things I thought would be causing this issue, and the problem still exists. It is possible that there is a problem with the laptop it is running on

[tavwtby]

Well I've tried the program on a different machine and same result. It also crashed my development machine which has 8GB of RAM. If I keep the program minimized and keep the active plots off, the program will run with consistant memory usage. This is bugging me that I can't fix this, if I have to run the program minimized it is pointless. I also noticed that the memory usage doesn't creep up it jumps almost expotentially til out of memory. I ran the Profile performance monitor and it showed that the collectors I am using are taking up a lot of blocks of memory, but like I said, I have used that style of coding before and no problems.I did however change the way I am calculating the CPM. Now I am using a tick count, subtracting it and dividing by 60000 inside a case structure which is true every time the pulse from the prox is made, this seems to be better and less overhead. but there is still that problem.

[Craig_]

Could you post the code again? I'm guessing that what you posted initially has been significantly changed.

You are probably running 32bit LabVIEW (which is good, by the way). Assuming that you have a 64 bit operating system LabVIEW will only be able to use 4GB of the available 8GB of memory. This should be enough though!

[tavwtby]

I hope this attaches, I had a crash and then it couldn't load block diagram. I am running the program as we speak on my development machine. It is using around 211Mb of private memory, and not increasing that much at all. This is with the program minimized and the plots not visible. When I tried to run it earlier with all plots visible and program open, it jumped over 2Gb and crashed in a matter of a half hour. I'm stumped

[tavwtby]

I stepped away for 10 minutes for lunch and came back to 1.9GB memory and climbing and crashing. It seems to happen instantly.

[Craig_]

Because it happens so instantly it could be something in your consumer loop slowing down execution and causing the queue to get really big. Try adding this snippet into your consumer loop so you can see how big the queue is at any time.

[tavwtby]

I did this snippet, and it very seldom shows 1 or 2 items in the queue. I'm not sure why it wouldn't have more items. I put this in the acquisition loop after the enqueue, and I put it in the top while before the dequeue, and the same result. I took away the shift register in the enqueue loop and so far it seems to be running good, I started off with less memory, and it hasn't increased any in an hour. And I have the plots visible with the program maximized. Hope this works, thanks for all your help by the way.

[Craig_]

Your DAQ assistant is enqueing elements into the queue (producer loop) and the consumer loop is the one dequeing elements. You want that consumer loop to run faster so that elements in the queue do not build up (think of the queue as a log of data that is waiting to be processed). The key here is that if something causes the consumer loop to slow down it won't be able to keep up with the data aquisition and the queue will get larger and larger from the backlog. 

The array shift registers can grow as well; adding array elements could cause the loop to take longer to execute at the same time as it would increase memory usage...

Removing the shift register in the enqueue loop should not change memory at all (it can only hold the queue reference).

If the memory skyrockets again, check the queue size indicators!

[tavwtby]

So your right, it crashed again, and the number of elements in the queue were almost 300,000. There were none for removal pending or insert. Should I be fllushing the queue after the enqueue loop instead of releasing the queue. I have a ton of other tests going on in the lab so I can't devote all my time to studying the ins and outs of what should be done and how it should be done correctly. I plan on taking another course, but for now I'm learning as I go. That being said, this test rig needs to be operational like a month ago. Is there any way I could zero the LVDT and the Torque before a test without using a sample compression and collector and then subtracting one from another. Thats a piece of code I had copied from another program that was written by someone else here years ago, and seems to have a lot of over head associated with it.