cFP slows over time

[TreyB_NI]

The reason why I'm asking for the software versions is double check that they are up to date and compatible.  If they are, then I would like to attempt to reproduce your issue, and I may find something in the process that could fix it or at least provide a work around.

Trey B
Applications Engineering
National Instruments

[Jo-Jo]

It seems centerbolt was correct.  I rewrote the VI which communicated with the cFP channels, set the loop to 400ms, ran it over night, and it worked great.  I am attaching the rewritten code for reference.  I still don't think this was a problem with how I wrote the code exactly.  It seems that if the cFP was fast enough to execute the code fifty times, then it should've been able to execute it at the same speed indefinitely, unless its memory was being consumed, which, according to the system manager, wasn't the case.  If anyone can explain why I can't call the channels individually, I would like to hear why.  The way the code is written now, I think you may agree, is a little strange.  My first version was, I think, more intuitive.  Also, here is the software versions I'm using:

FieldPoint Drivers: 5.2.0
LV Real-Time: 8.2
Hardware RT version: 8.2

~Benjamin

[Wayne.C]

Benjamin,

Way to stick with it!  Test proves that you can affect problem by reducing # of FP Writes.  That would seem to indicate that the large # of FP Writes is part if not all of the problem.  I don't know why that would be.    Perhaps NI has some insight into what is happening in the background when a FP Write is executed.

There still remains a slim chance that something else is also affecting this.  It could be that reducing the # of FP Writes bought you enough time to make things work but that you still have a performance issue in another part of your design.  You may want to consider ruling out the large clustered variable being a contributor.  Are you using a lot of variables in your application?  

[Jo-Jo]

I'm using loads of variable, hence the huge cluster.  I'm not sure if you can tell from the code, but this application utilizes most of an eight slot backplane.  The strange thing is that it works fine at first, then slows later, which seems like it must be a memory leak, but I can't find one, the memory is always about two thirds empty.  Also, I'm told that bundling and unbundling things doesn't create copies, or other potential memory issues, although I haven't ruled out the possiblilty that the code is operating marginally now.  The symptoms are just so strange, that I have to assume that there is something going on in the cFP hardware or firmware that I don't have access to, or something about the cFP write functions that I don't know.  I did, after all, strip out all the code except for that one cFP comm, and it didn't work, and then I put everything back in, except for the cFP write functions, and then it worked fine, so I have to assume that it is those writes.

[Wayne.C]

My money is on the variables being part of the problem.  If you are using a lot of variables, that will definitely affect performance.

I took the NI Real-Time class a while back.  Bottom line is that while global variables are easy to program, they are not the ideal method for transfering large amounts of data. 

Here a couple of links to info on this subject.

http://zone.ni.com/devzone/cda/tut/p/id/5317

http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/using_local_and_global/

[Ching_F.]

Hello BenjaminS,

Though calling the FieldPoint Read or FieldPoint Write functions once for each channel should take more time than using the All Channel Tag to call the functions once for all channels, it should not increase the amount of time it takes to execute each loop iteration.

While looking through your code, I found that you were using an invalid tag.  If you have an invalid/blank FieldPoint I/O tag being fed into a FieldPoint Read or FieldPoint Write from a FieldPoint I/O control (front panel item), each loop iteration will take longer to execute.  This was reported to R&D (4BTBEVX6) for further investigation.