FieldPoint Family

cancel
Showing results for 
Search instead for 
Did you mean: 

Labview RT program on cFP-2020 stops responding

I am running a facilities management VI in LabView RT 7.1 that basically just monitors and displays input values for 8 modules on a backplane with a cFP-2020.  The primary purpose of the program is for doctors to connect remotely and view the status of their equipment.  The program also logs all data into cFP flash memory.  When I reboot the cFP, the program runs smoothly for about one or two hours (this time varies) and then stops responding or responds very poorly, ie. I can no longer connect remotely to the VI.  Sometimes after this initial time period I cannot connect remotely with a web browser but can connect remotely from my computer in LabView, but the values update slowly or not at all, even though it says the program is running.  Also, I have noticed that when the VI stops responding, in MAX I see the name of my remote target change from the name I gave the cFP to the static IP assigned to the cFP.  I am at a loss to what could be causing this.  Any help would be much appreciated.  Thank you.
0 Kudos
Message 1 of 7
(4,603 Views)
It sounds like you might be running out of memory.  Check out this thread for a monitoring tool:

http://forums.ni.com/ni/board/message?board.id=110&message.id=1606

(thanks Ben!).  Also take a look at:

http://zone.ni.com/devzone/conceptd.nsf/webmain/732CEC772AA4FBE586256A37005541D3?opendocument

Pay particular attention to arrays; statically allocate them at the beginning then replace elements as required.  Don't
build/insert/remove in a loop.

Hope this helps.  Are you required to meet 21CFR11?

Matt
Message 2 of 7
(4,580 Views)

I'm not sure, but it's possible this is caused by memory problems. For example, if you're building an array over time, eventually the array will be so big that you will have no more memory left for anything else.

Do you have nodes like Build Array, Insert Into Array and Concatenate Strings in your code?

Can you post the code?

___________________
Try to take over the world!
0 Kudos
Message 3 of 7
(4,578 Views)
Ok, thanks a lot guys, I will took a look at the advice you gave me, however, I am an undergrad with no formal Labview training, I just kind of learned as I went last summer when I started this project, so I'm not familiar with a lot of the terminology you are using.  I will post my VI with this message so you can take a look and see if you can locate the problematic points (just so you know, I realize that in many parts of the code I have inserted a constant rather than reading the actual value, that is because some sensors are not yet installed and this was my way of avoiding constantly having alarms and whatnot).  I wasn't sure if I needed to attach any sub VI's that I created, but I went ahead and attached a sample of the two important sub VI's that I used to be safe.  In the mean time I will try my best to try the advice and programs you gave me.  Thanks again.
0 Kudos
Message 4 of 7
(4,577 Views)

A quick look doesn't reveal any clear cause of the source, but I would strongly suggest that you clean your code up. This will make it easier to read, debug and maintain the code. You seem to be doing the same thing many times. Why not make it a subVI and call it in a for loop with the appropiate parameters?

One thing I saw which might be the cause of this is your writing to the disk. If the disk becomes full, I suppose it could be possible that your constant deleting and writing could be causing trouble. That depends on how often you're writing. Another point about that - why are you using a shift register to pass the boolean to the next iteration? Why not just wire it into the case structure?

To learn more about LabVIEW, I suggest you try searching this site and google for LabVIEW tutorials. Here and here are a couple you can start with. You can also contact your local NI office and join one of their courses.
In addition, I suggest you read the LabVIEW style guide and the LabVIEW user manual (Help>>Search the LabVIEW Bookshelf).

___________________
Try to take over the world!
0 Kudos
Message 5 of 7
(4,572 Views)
Yes, I realize my code is probably hard to read for someone else, and I apologize, I just haven't gotten around to cleaning it up yet.  I ran the memory program that was suggested and didn't see any increase in memory while my VI was running.  I attached a screenshot of the memory VI after it had run for a while.  The program writes to each spreadsheet file every minute.  The way the VI is setup right now, there should always be a minumum of 5 MB free on flash because if there is less than that it deletes the oldest spreadsheet files.  It doesn't seem like writing/deleting once a minute should cause a problem, should it?

Also, I am set to recieve warning emails when something is out of range.  I recieved an email every half hour all of last night and through this morning, so the program was obviously still running for a long period of time, however I could not access the front panel remotely this morning.  Does this provide a clue to what might be going on? 

Finally, I looked through my code and found I do have "build array" inside a while loop.  Originally I had used the Fieldpoint express VI for each channel on each module, but that made my program huge and I was unable to download it to the cFP.  NI suggested replacing them with "FP read" like I did.  Let me know what you think.  Thanks.
0 Kudos
Message 6 of 7
(4,569 Views)
 

Hello ESengbus,

The LEDs on the cFP-2020 Network Controller are a very good resource for diagnosing problems with network communication.  Appendix A of the cFP-2020 User Manual has a section on troubleshooting using the Status LED on the Network Module.  Generally, this LED should be solid and any series of blinks indicates a problem.  Is your Status LED blinking?  The Link Act LED blinks when the cFP-20xx receives data from or transmits data via Ethernet.  Does this LED continue blinking even when you are unable to communicate with the module?

As always, make sure you are using the latest version of FieldPoint software, which can be found here.

Finally, judging from the shear size of your embedded program, I really think that running out of memory might be the real problem here.  When you download the program to the cFP-2020, you should see a statistic about the amount of free memory available on the controller.  Are you approaching the limit shown there?  Also, you are downloading your program into the internal memory of your cFP-2020.  Are you also logging your data to this memory or are you logging the data instead to a removable Compact Flash card?  The cFP-2020 takes a Type I or II Compact Flash card of up to 512 MB.  To read or write to this card, you need to point your File I/O VIs to the D drive on the controller (see the cFP-20xx User Manual for more information).  Can you increase the performance or delay the failure by increasing the minimum amount of memory to maintain before overwriting data?

The last thing you might want to try is to reformat the internal memory and reinstall all software on your cFP-2020.  This can be done through Measurement & Automation Explorer by right clicking on your module under 'Remote Systems' and selecting 'Format Disk'.  Warning! - This will erase all software and data onboard the controller.  You will need to reinstall LabVIEW Real-Time and FieldPoint.

Give these suggestions a try and let us know if you can narrow down the problem.

Regards,
Travis Gorkin
Applications Engineering
National Instruments
www.ni.com/support

0 Kudos
Message 7 of 7
(4,545 Views)