cFP-2020 Locks up after 1-3 hours

[seanpatrick]

Has any one seen a problem like this? The communication was written with the wizard. I have only made minor mods to the code. Everything works fine but after a couple of hours I stop receiving data from the 2020. No warning or anything. When I try to view it in labview it tells me I have lost communication and is changing back to labview for windows. I was using a USB ethernet adaptor but just replaced that with a network card to see if that is part of the problem.

[Ben]

Hi seanpatrick,

You have described what sounds like you are running out of memory on the cFP. If it not a leak, you may be able to get away with imbedding the image.

The line

Targetmeminfo=True

in your LV ini will let you look at the memory usage.

I hope this helps,

Ben

[Ben]

Added info:

After you set the switch and re-start LV and then start you VI on the cFP,

Opearte >>> RT Engine Info

will show the memory usage.

The attached VI may also help.

Start it before you start you VI on the cFP.

Ben

[seanpatrick]

Hi Ben
The memory stayed at 14.5 meg for the entire time the VI was running. It was a good thought though it was where I was leaning when I came in this morning. I'm going to disconnect all of the wiring blocks and see if it gets better maybe there is some strange feed back in the system. If you have any other thoughts let me know.

Sean

[Ames]

Sean,

This really sounds like it has something to do with the code running embedded on the cFP as Ben mentioned. Another possibility besides the memory issue is not having long enough waits in a time critical loop. You could be starving out the normal priority process that communicates over Ethernet back to the host. I bet if you downloaded some very simple LabVIEW program you would find that it didn't crash after several hours. This would help eliminate the hardware from the situation.

There are other things you should look into other than just the wait. Are you using RT FIFOs? Publish VIs? Which version of NI FieldPoint? What priorities are your VIs?

Ames
Applications Engineering
National Instruments

[Ben]

Wow!

Please let me know what you find out in the end.

I am suprised that it is not memory.

Sorry for the distraction,

Ben

[Matthew_Williams]

When the unit locks up are there any lights lit on the controller? We had a cFP-2010 and backplane that would shutdown after 30 to 60 minutes running proven code. Was completely unresponsive and had no lights at all, just as if it was unplugged. Cycling power brought the unit right backup. Problem was specific to that controller and backplane combination.

I agree with Ben, though, certainly sounded like memory. Are you allocating memory in process, so that maybe even though there is plenty of memory there is not a large enough chunk available?

Matt

[Ben]

Adding to Matt and Ames...

Post your code for Ames to look at.

Did you try running the memory thing I sent and try disconnecting and re-connceting periodically?

If memory is not the cause you may want to try using the LEDS to give you an idea of what is happening inside your code.

Again, please share your findings.

Trying to help,

Ben

[seanpatrick]

Hi All,
I tried adding a longer "wait" in the time critical loop. Since the vi has been running for about 18hrs straight. I may have to optimize the code after this to speed things back up but this is looking promising. I see Ames�s posting is missing� ? Ben I have not tired anything else since I started with the longer wait in the loop. If this locks up again I will try just running your vi by itself and let you know what happens. If it locks up again I will clean up the host code and post everything. There is some special hardware on the host which generates errors if not found.

Sean

[Ben]

18 hours is 6 times better than when you started.

My VI is intended to run along side yours so you can see how memory usage changes with time.

Ben