RT - Event Record Display

[bbean]

I have to provide a list of events that have occurred during execution of my run-time application to the user. The user will access the RT app via Remote Front Panels. The events are described by a timestamp and a string. And don't occur that frequently (once a minute) For example:

10:30:04 - TEMP ALARM - ZONE 1 - TEMPC = 30

10:31:04 - POSITION MOVE - 33 mm

etc

etc

I'm trying to determine the best method to store and display the data in LV RT. Here are the options I've thought of:

Datatype / Storage Method / Display Method

1) string / FIFO string buffer of 100 lines LV2 global / string indicator on FP (limited to 100 lines) (I know there really isn't a front panel in LV RT)

2) Cluster of timestamp & string / 100 element queue / array of datatype on front panel

3) string / event file / string indicator on FP (limited to 100 lines)

If I use 1 and (a string indicator), I'm worried about it sucking up CPU resources and memory to limit the size of the string to 100 lines.

For option 3, I thought I would read the last 100 lines into the string indicator on the FP everytime a new event occurred (it has to be written to the file anyway).

Any suggestions?

[LAVA 1.0 Content]

QUOTE (bbean @ Jun 18 2008, 03:28 PM)

I have to provide a list of events that have occurred during execution of my run-time application to the user. The user will access the RT app via Remote Front Panels. The events are described by a timestamp and a string. And don't occur that frequently (once a minute) For example:

10:30:04 - TEMP ALARM - ZONE 1 - TEMPC = 30

10:31:04 - POSITION MOVE - 33 mm

etc

etc

I'm trying to determine the best method to store and display the data in LV RT. Here are the options I've thought of:

Datatype / Storage Method / Display Method

1) string / FIFO string buffer of 100 lines LV2 global / string indicator on FP (limited to 100 lines) (I know there really isn't a front panel in LV RT)

2) Cluster of timestamp & string / 100 element queue / array of datatype on front panel

3) string / event file / string indicator on FP (limited to 100 lines)

If I use 1 and (a string indicator), I'm worried about it sucking up CPU resources and memory to limit the size of the string to 100 lines.

For option 3, I thought I would read the last 100 lines into the string indicator on the FP everytime a new event occurred (it has to be written to the file anyway).

Any suggestions?

I and my customers have been burned by strings in RT apps running of FP units.

Try to avoid strings completely. If you have code that always returns the same string, concider using an enum to display those strings.

I have used LV2's set-up as round-robin buffers to do what you are attempting.

AS you are developing watch your memory usage over extended periods of time. THe run out of memory issue will sneak up on you if you don't.

Ben

[bbean]

QUOTE (neB @ Jun 18 2008, 04:04 PM)

I and my customers have been burned by strings in RT apps running of FP units.

Try to avoid strings completely. If you have code that always returns the same string, concider using an enum to display those strings.

I have used LV2's set-up as round-robin buffers to do what you are attempting.

AS you are developing watch your memory usage over extended periods of time. THe run out of memory issue will sneak up on you if you don't.

Ben

Thanks Ben. Good to know about your experience with strings. I'm using cRIO. Not sure if that makes a difference one way or another.

What has your experience been with Remote Front Panels (RFPs)?

I guess I'm trying to avoid making a custom client application to communicate with the cRIO app. I'd like to keep the architecture simple if possible. And since RFPs handle all the dirty work of connection management and display, I thought it be easiest to use them. But the event log (and data log) presents a memory / keeping it Real...Time issue.

I guess another option would be to do a LV client app with a RFP on the front panel of the diagram for the user to change setpoints/monitor current analog values and additional charts, graphs, strings to display RT unfriendly data. These indicators would then be populated, by reading the log / data files on the cRIO filesystem via FTP.

[Neville D]

You could use shared variables to write info to a Host PC, and then display any kind of history you want.

You could also use shared variables to write values to controls on the remote RT application.

there are a number of such examples on the NI site zone.ni.com.

Neville.

[bbean]

QUOTE (Neville D @ Jun 18 2008, 06:26 PM)

You could use shared variables to write info to a Host PC, and then display any kind of history you want.

You could also use shared variables to write values to controls on the remote RT application.

there are a number of such examples on the NI site zone.ni.com.

Neville.

I guess I'm lazy and would like to avoid writing a client LV app if we could use a web browser. Don't know if I'm trying to fit a round peg into a square hole, but wanted to get feedback from others. Wouldn't I have some of the same issues with memory/buffer allocations using a shared variable string? I realize they would help with "keeping it real time" because they have a lower priority.

thanks

[LAVA 1.0 Content]

QUOTE (bbean @ Jun 19 2008, 07:27 AM)

I guess I'm lazy and would like to avoid writing a client LV app if we could use a web browser. Don't know if I'm trying to fit a round peg into a square hole, but wanted to get feedback from others. Wouldn't I have some of the same issues with memory/buffer allocations using a shared variable string? I realize they would help with "keeping it real time" because they have a lower priority.

thanks

THe built-in web-page support is still a "Risk factor" in my apps. My customers that have implemented very simple pages for monitoring have reported success. The very complicated GUI's should not be assumed to work without effort or resources.

The methods mentioned by Neville (maybe not shared variables, I don't they are ready for prime time yet) are approaches that I would turn to if I wanted to be comforatble with the success, since I can control all of those factors.

So include some experimenting with your intended GUI early in your development. You don't want to have to re-write your app after you find that opening the web-page kills your app.

Just trying to help,

Ben

[Yair]

I'm not sure how the RT memory manager works when allocating strings, but I would suggest having a constant size for all strings and then replacing inside the string. You can do this by initializing the string to N null chars and then using replace substring. If you want to save time on writing a circular buffer, you can use this one.

[bbean]

QUOTE (Yen @ Jun 19 2008, 02:38 PM)

I'm not sure how the RT memory manager works when allocating strings, but I would suggest having a constant size for all strings and then replacing inside the string. You can do this by initializing the string to N null chars and then using replace substring. If you want to save time on writing a circular buffer, you can use this one.

Thanks for the link. I guess thats what I was wondering, are strings just like arrays in terms of replacing vs building in LV RT. In other words can you preallocate them to a fixed length and then use the replace substring like you said to avoid memory allocation everytime you update.

QUOTE (neB @ Jun 19 2008, 09:03 AM)

THe built-in web-page support is still a "Risk factor" in my apps. My customers that have implemented very simple pages for monitoring have reported success. The very complicated GUI's should not be assumed to work without effort or resources.

The methods mentioned by Neville (maybe not shared variables, I don't they are ready for prime time yet) are approaches that I would turn to if I wanted to be comforatble with the success, since I can control all of those factors.

So include some experimenting with your intended GUI early in your development. You don't want to have to re-write your app after you find that opening the web-page kills your app.

Just trying to help,

Ben

Thanks for the tips. I'm also looking at this reference app from the ni website for architecture ideas:

http://zone.ni.com/devzone/cda/epd/p/id/5336#0requirements