Could FieldPoint be too slow to run a VI?

[Lost And Found]

Hello,

I'm using FieldPoint to control a traffic control system, with 24 outputs (to a total of 8 traffic lights). The control system is a fuzzy logic controller (which came with the PID Toolkit).

Merely using the FieldPoint as a directly controlled output unit from a laptop presents no problem, the program executes properly and just pumps out the appropriate output to the FieldPoint AO and DO blocks (1 of each).

However, when I try to load the VI into the FieldPoint unit (in this case, by selecting the execution target to be the FieldPoint unit), the program executes very very very slowly.

Even worse, when I try to build an application out of the VI and load it to the start-up folder of the FieldPoint unit, the program doesn't seem to execute at all. Also, once the FieldPoint unit is rebooted, it becomes very difficult to contact the FieldPoint unit through the LAN connection. Connection can be established, but keeps getting broken off.

I've tried to read through the application notes for hints on what could be the problem, and I've come to the conclusion that it might be a memory-allocation problem. Somewhere (I can't find the article right now) I found a bunch of rules for running a RT program on FieldPoint which I think apply, such as not using property nodes which are really slow and not using the 'Build Array' since this creates a new array for every iteration of my loop.

This would require a total reprogramming of my VI, which I'm rather hesitant to do, so firstly I'd like to ask whether it is possible that the attached VI would be too large or memory-inefficient for the cFP-2020. Please note the fuzzy logic sub-VI, however, that sub-VI functions fine on its own.

If, as I suspect, this program is just too large and inefficient, please give suggestions on what I could do to remedy that. Thanks.

[TiTou]

Wow... the diagram is quite huge ! I understand why you don't fell like rewritting the whole application

First I have to say I've never used FieldPoint with RT, and I don't often use LabVIEW RT so I won't be able to answer all your questions. Sorry about it !

Second, I suggest you should always try not to exceed the size of the screen for the diagram.

Third, have you thought about doing, for each firelight, an array or a cluster instead of having so many booleans ?
I realize that means re-writting almost everything... but would be a lot clearer.

Fourth, to deacrese the number of property nodes, you could find some tricks ; for instance, instead of hiding every firelight manual control, put then in tab-control. Having two tabs, one empty, the second with all the control, and the button, just control the tab the operator can see.
This is just an idea... Be inspired !

[Lost And Found]

Thank you, Titou.

For the 2nd point, I'm afraid that's rather out of my control, since the requirements of the project (and, more specifically, the requirements given by my lecturer) seem, to me, to require such a large diagram.

For the 4th point, that's an interesting way of hiding controls that I hadn't thought of before. Thanks!

For the 3rd point, I did initially use a group of arrays, but abandoned that idea because it seemed I was always extracting a few values from the array and changing a few. In my VI, on the right side, that large case structure is actually a type of sequence structure controlled by the number of iterations of the while loop. The inputs to the structure include the values of each traffic light, the output from the structure are all the values of the traffic lights, which would mean that every iteration of the while loop would require unbundling and rebundling or extraction and changing of array values. While this would possibly make things clearer, I'd like to know whether it would positively or negatively affect the processing and/or memory requirements of the VI, since that's my major concern now.

Thanks again.

[TiTou]

Hi,
I've talked about it to some "RT enabled" friends, it seems clear the computing capacities the cFP2020 will not allow to run as it does from a PC (even a laptop).
The number of variables, 24 in your application, is quite low.
So if you need your soft to be able to run at an acceptable speed when running from the cFP, you have to work on the soft architecture. The tricky part of RT programing is sharing the ressource between the different tasks ; when you want the cFP to communicate with a PC while controlling the firelights, the communication should not alternate the process...
Just like you, you are supposed to be able to work with the same efficiency with or without your boss behind you 😉

Be inspired !

[Laura F.]

Hello Lost and Found,

I want to note a few other things about your VI.  I notice that you are using an Express VI (Elapsed Time) in your VI.  You should stay away from using Express VIs with Fieldpoint because they are memory intensive.  You can use the Tick Count function to perform the same measurement. 

Instead of using property nodes to keep your boolean control at the same value in certain cases, you could use shift registers.  Or, if you prefer you could setup functional global variables. 

Hopefully some of our suggestions will help you get this VI running!

Laura

[bob_miller]

Titou needs a bigger screen I am also guilty of vi's that extend beyond the screen size. I found yours nicely organized even if expansive.

The comments about property nodes are valid. I use as lot of property nodes in my RT programs, but mostly in the initialization routines, not in the critical stuff, where I use lots of shift registers and "global Vi's".

Without diving deeply into your architecture, I see a lot of array'ed functionality. While highly parallel is touted as a LabVIEW feature, remember you really only have one CPU which is flitting between the paths. An all of these require simultaneous memory allocation. For this reason I suspect that wrapping some of this functionality up in a loop (reusing the intermediate data structures) so the sequencing of the tasks is less chaotic could help  a lot.

Another hint: I don't try to export the front panel to the PC at all! Instead I pack up the key control and status and pass it to a separate front panel VI running on the PC. This is probably too involved for a class assignment, but it lets me build a front panel VI as glorious as I want without bogging doen the '2020. It also lets me connect the front panel via phone dialup half a planet away!

Here's the top level of the RT program I'm currently playing with to run a water plant. The block diagram is virtually as big and a lot more cluttered than the one you posted. I keep a messy desk, too   It runs great on a cFP2020, and there is a lot of functionality buried in all those sub-vi's you can't see -- file I/O, big data structures, the works. By the way, you can see the (server) interface to the front panel VI at the bottom of the VI.

hope this helps a bit. I make no claims to being a professional wireworker, but I'm pretty adept at architecting for computational efficiency. I thought about the computational cost of every scrap of main-loop functionality before I implemented it.

Bob

[Lost And Found]

Thanks Titou, Laura F., and bob_miller.

I just re-wrote the VI twice, once for testing and one more on-going development of a final embedded program. I have not yet found the time to replace the Elapsed Time Express VI, but should be doing it soon.

All the property nodes have been replaced with variables, and the arrangement drastically redone in order to reduce the necessary number, while I've been reading up on arrays and memory allocations in the LabVIEW section of this forum, especially the usage of shift registers.

Was interesting to read bob_miller's suggestion about a seperate front panel, because for my testing I actually did away with almost all the front-panel elements, am planning to use a DataSocket server to achieve interconnection between my embedded controlling VI and my PC-based user-input front panel. About it being too involved for a class assignment, probably not, since using DataSocket it isn't really too much work. I've taken a look at your VI, though, bob_miller, and you're using TCP/IP level communication, which I don't understand in depth =). I'm pretty sure DataSocket should provide an acceptable substitute, though it probably would consume much more resources and bandwidth.

Major conclusion so far, removing all the property nodes and tightening up on the data handling and memory allocation seems to have allowed my program to run on the cFP with acceptable speed. However, the testing VI did not have any DataSocket connections, so I'm just going to have to put them in to finalize everything. Right now, however, it seems that the problems have been resolved, mostly. Thanks a lot to everyone!