How do you handle your status string updates?

[GregFreeman]

I have an application which has a status string to keep the user informed as things happen. I originally did this as a functional global which held a reference to the the string indicator, and then I could update that indicator globally by placing it across my application.

But, in refactoring the code I was thinking maybe I should have these updates as a separate process that handles incoming messages (say, messages of the class status update) instead and displays them in a string. Then I can move this from application to application. 

I was looking to see if anyone has other methods for handling these kind of updates, and if so, what you've found to be best practices for this?

[Charles_CLA]

Most of my front panels make heavy use of .Net controls so I usually use a .Net StatusStrip and pass the reference to it to the VI's that want to update. I realize the .Net updates require more time but that's usually not an issue.

[Jed394]

I've been wondering this myself.   I'm doing something similar.  In your example, out of curiousity ff you pass this reference into a FG, does calling that FG within a fast data processing for/while loop force that entire data processing loop to run in the UI thread?  Or does only the FG run in the UI thread plus any front panel UI components?  

For a totally seperate process have you looked at the SYSLOG library offered by NI examples?  You could do a simular implementation but change out the UDP messaging components to any data sharing method you want.   

[GregFreeman]

---

@Jed394 wrote:

I've been wondering this myself.   I'm doing something similar.  In your example, out of curiousity ff you pass this reference into a FG, does calling that FG within a fast data processing for/while loop force that entire data processing loop to run in the UI thread?  Or does only the FG run in the UI thread plus any front panel UI components?  

---

I *think* only the subVI with the property nodes runs in the UI thread but I'm not sure. Either way, it wouldn't matter and you won't want to use this method in a time critical or fast thread. This is because the time to update via property node will greatly slow your loop down; the next iteration won't execute until this functional global is done and writing to property nodes is slow.

If you really want to use this method within a fast loop, you should somehow batch the messages then write many messages at one time rather than writing one at a time, so you aren't making multiple calls to the VI/property node. In the case of a fast loop, I'd almost always suggest queueing up the messages

[Norbert_B]

For small applications, a strict binding or a FGV like you suggest, Greg, are a very suitable manner of updating status information on the UI.

But startig with mid-size going to large applications, this might introduce unwanted coupling between modules. Hence, you have to split up the UI completely from "action tasks". This will result in more complex architectures. The latest (and greatest) of those is currently considered to be the Actor Framework (OOD/OOP).

There is an example which might be interesting for you posted in this community page discussing similar questions like yours. Maybe this could be the next step to elevate your LV knowledge.

Norbert

[Mark_Yedinak]

We have defined a messaging protocol that is essentially a pulish/subscribe architecture. Our lower level code simply generates messages. That code doesn't care if anyone is listening or not. It just generates them. In the of our messaging system we have a message broker which any part of our system can register with to receive messages. When messages are sent from lower level code the message broker receives them. It looks through it's registration tables and then forwards the message to the specified listening queue. Using this method we can handle the sam message in different ways as well as broadcast a message to multiple listeners. For instance, the raw data read from some source would generate a message containing the data that was just read. We could have two listeners registered with the message broker and they will both receive the "RX Data" message. One task may display this on the UI while the other writes it to a file. Our registration is dynamic so processes can come and go as needed.

This approach does take some up front work but once done it is easy to use. It is similar to the active framework in concept but it is a bit more generalized since we can send and recveive messages over the network and from applications not written in LabVIEW.

[GregFreeman]

---

@Mark_Yedinak wrote:

This approach does take some up front work but once done it is easy to use. It is similar to the active framework in concept but it is a bit more generalized since we can send and recveive messages over the network and from applications not written in LabVIEW.

---

This is similar to what I have been developing. While I don't directly subscribe in the sense I believe are talking about (which sounds a bit more like JAMA, but I haven't completely dug into that so I may be wrong), every one of my processes has a reference to a message mediator queue. Anything they do, they forward the message to the mediator. I then handle the application specific processing of the messages there (but I don't have a registration table like you suggest. Maybe I will dig into that as my next step). Does this sound somewhat similar?

Norbert, thanks for the suggestion. I have dug through that before, but I will dig through it again to refresh my mind on the concepts.

[Mark_Yedinak]

---

@for(imstuck) wrote:

---

@Mark_Yedinak wrote:

This approach does take some up front work but once done it is easy to use. It is similar to the active framework in concept but it is a bit more generalized since we can send and recveive messages over the network and from applications not written in LabVIEW.

---

This is similar to what I have been developing. While I don't directly subscribe in the sense I believe are talking about (which sounds a bit more like JAMA, but I haven't completely dug into that so I may be wrong), every one of my processes has a reference to a message mediator queue. Anything they do, they forward the message to the mediator. I then handle the application specific processing of the messages there (but I don't have a registration table like you suggest. Maybe I will dig into that as my next step). Does this sound somewhat similar?

Norbert, thanks for the suggestion. I have dug through that before, but I will dig through it again to refresh my mind on the concepts.

---

This sounds similar. In our case all of our messaging stuff are LVOOP classes. Anything generating a message does not need anything passed to it. At startup the system creates the message broker (we call it our route server) and initializes our message class. the message class is what is used to actually generate and send a message. Internally anything generating a message simply calls our PostMessage method. The class has all of the information for how to reach the route server.

When the route server is started it is given a route table object. This table is our message registration. Using the route table parts of the can register to receive messages. In addition we have message handling classes which are generally used for the message processing. Though it is not necessary to use one of these objects to receive messages. The route information consists of a queue name and an IP address if remote messaging is being used. The registration (route table) is one of the things that makes messaging system very powerful. Our approach is very similar to JAMA but it is actually a bit more flexible. I am pretty sure we developed ours in parallel with JAMA. Our system also supports a method to customize message names since we can have multiple onjects of the same type. We provide the ability to add a prefix to an objects name which further allows us to refine the message routing.

[User002]

Perhaps use a listbox to show a scrollable history of actions, events and errors, etc.

Check out this LVOOP logger implementation with various plugins, among them a listbox writer.

https://decibel.ni.com/content/docs/DOC-24594

Br,

/Roger

[Yamaeda]

You could insert a sub-vi as status panel which only listens to a user event, which you can send from anywhere.

A even simpler solution is a sub-vi with only a string control as input. No runnable code at all. Place the sub-vi whenever you want to update the control.

/Y