While executing my application, the compact FieldPoint will freeze and break communication with the touch panel. I looked at the error logs for the cFP by right clicking on the target in MAX and selecting view error log and I found this
LabVIEW error log:
#Date: TUE, DEC 22, 2009 07:05:40 AM
12/22/09 09:27:32.948 AM
source/mgcore/MemoryManager.cpp(143) : DWarnInternal: Memory error 2 in DSSetHSzClr
$Id: //labview/branches/Orion/dev/source/mgcore/MemoryManager.cpp#27 $
12/22/09 09:27:32.952 AM
source/exec/CleanupProc.cpp(267) : DWarn: can't realloc cleanup tbl
I'm not sure what this message means. Anyone have any ideas what this message means and how to find the issue in the code?
What appears to be happening is that you are experiencing CPP errors with you RT application. If you run your application directly from the VI (press the run button), do you get the same errors?
Additionally, which controller are you using? It looks like you are using the cFP-22XX series, but I was wondering the specific model number.
Try referring to this KnowledgeBase article for some suggestions:
It appears that I have a memory leak in my code. As I execute my code, I can see the memory usage climbing using the Distributed System Manager. Once the usage reaches 91% then the system "freezes". I did read that the memory allocated for subVIs is not deallocated until the top-level Vi finishes running or the entire application stops. So I added Request Deallocation function in each of the subVIs.
I'm attaching a zip of my code so hopefully someone can point out what might the issue or give me more guidance on how to find the memory leak. The code is intended to run a test stand that performs life cycling testing so I've set up a state machine for initializing the system, executing the testing, and then a wait state to see if the operator wants to perform more testing or stop. The testing state consists of 5 state machines that turn valves on or off for a certain amount of time.
I am using a cFP2200 with 2 cFP-DIO-550 and 2 cFP-AI-100.
Thank you in advance for any input.
Your design contains a subvi titled "System ID.vi" in which you open a refnum to your .iak file. You seem to use it every time you read or write an IO. The problem is that you never close the refnums. I'm guessing your vi just keeps opening new refnums until the memory is full. Normally you would only use one FP Open.vi for each .iak file.
Is there a reason you are using refnums instead of the FieldPoint IO Point In?
If I use the FieldPoint IO Point In, will I be able to use this code on a different cFP on the network? That is why I was using the refnum - so that I could point to a different .iak file for whichever system I was on but use the same code.
So you have multiple identical teststands that you want to run with the same code?
End of day here and it's been snowing all day long so I need to get going. I'll look at your code a bit more tomorrow and do a little research to see if I can come up with a better way to do this without the memory leak. Hopefully some of the other forum users will weigh in with there thoughts as well.
Thanks for the input on the issue. I am going to try adding FP Close after each instance where I use the SystemID.vi. I'll let you know if that helps. Also, if it is determined that I can use the FieldPoint I/O point function and still use the same software on multiple stands, I can change the code to that.
Wayne.C - by adding the FP Close function, I have stopped the memory leak. You were correct that it was the multiple opening of the RefNum to the .iak file. However, the system is executing slow......for example if I want the valve ON for 2 secs and OFF for 2 secs and I run 1 of the 5 banks, I have approximately 2 - 3 secs ON and 3 secs OFF. When I run all 5 banks, 4 secs ON and 7 secs OFF.
Is there a way that I can open the RefNum to .iak file once and then use a global variable or some other type of variable to use it in each instance of executing a cFP command? I'm also thinking of switching to the FieldPoint I/O Point In to see if that improves the timing.