DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Right way to do it?

Hi,

 

I have DQMH module which has a Send Message request. The purpose of this request is that the requesting VI can send simple string messages to the GUI of the DQMH module. Other than this the module does nothing with the message, it simply broadcasts it so the GUI can capture the broadcast and display it on its front panel. 

 

This is where I'm somewhat concerned if I'm doing the right thing, because I can implement this only with a Roundtrip request, which looks like an overkill:

 

1984_0-1703058510918.png

 

I'm  not sure if this is a problem for others, but I've been in this many times that what I really need is a VI I can call outside of my module a directly broadcasts data.

 

Its possible that I do something what is conceptually wrong, so I'm wondering how others would solve a problem like this. Its also possible that this is the way. Another possiblity that there could be a 5th type of a request which is either a "Request+Broadcast" without a returning payload or a public broadcast.

 

Thanks.

0 Kudos
Message 1 of 6
(917 Views)

@1984 wrote:

I've been in this many times that what I really need is a VI I can call outside of my module a directly broadcasts data.


I'm not sure I understand why you need this functionality many times. I'm not saying that it's wrong, but it's surely not a standard use case, so maybe it's worth some additional consideration?

 

I can remember a single application where I needed to trigger a broadcast from outside the module (*), and I simply created a wrapper VI for the broadcast with public access scope 🤷‍

 

(*) Edit: And thinking about it some more, this was only to simulate a certain situation from the API tester.




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


Message 2 of 6
(903 Views)


I'm not sure I understand why you need this functionality many times. I'm not saying that it's wrong, but it's surely not a standard use case, so maybe it's worth some additional consideration?

 

Example: that you have two dqmh modules running in parallel. Both has a GUI (not the module main and not the API tester but separate GUI displayed to the user) and the GUIs need to exchange data. Is this a better example? Basically what I'm creating is a way for the GUIs to communicate with each other. As written above I can imagine that I'm doing something which I should not do (or do it differently), but this actually happend to me multiple times in the past ~12 months since I'm working with DQMH.

 

 

I can remember a single application where I needed to trigger a broadcast from outside the module (*), and I simply created a wrapper VI for the broadcast with public access scope 🤷‍

So just created a VI in the Public API which included the broadcast? That could work 🙂 Maybe a new virtual folder called Public broadcasts in my projects.

0 Kudos
Message 3 of 6
(881 Views)

Two different ways to approach this.

 

1. Create a Message Broker module that sits hierarchically at the top of the tree, where GUI 1 and GUI 2 are both dependencies.

 

If something occurred on GUI 1 (ie user pressed a button), broadcast this to the new message broker module.  The message broker module would then receive this event, and then call a request of GUI 2 to inform it of the update.  And Vice versa.

 

2. Or you have a hierarchy between the two GUI modules. 

 

ie GUI 1 is top, and GUI 2 is bottom, therefore GUI 2 is a dependency of GUI 1. 

If something happened on GUI 2, simply broadcast this to GUI 1.  If something happened on GUI 1, call a GUI 2 request to inform it of the change.

Christopher Farmer

Certified LabVIEW Architect and LabVIEW Champion
DQMH Trusted Advisor
https://wiredinsoftware.com.au

0 Kudos
Message 4 of 6
(839 Views)

1. Create a Message Broker module that sits hierarchically at the top of the tree, where GUI 1 and GUI 2 are both dependencies.

 

If something occurred on GUI 1 (ie user pressed a button), broadcast this to the new message broker module.  The message broker module would then receive this event, and then call a request of GUI 2 to inform it of the update.  And Vice versa.


Not sure if I got this right, but for me it seems that the first solution complicates the situation even more by introducing a third module. GUI1 can call the request of the broker module, but as GUI2 has no requests (as GUI1 and GUI2 are not DQMH modules), the broker module can only broadcast a message which has to be captured by GUI2. This doesnt seem to simplify anything as with less effort GUI1 can call the request of DQMH2 which broadcasts a message captured by GUI2. Plus the comments below for the second solution applicable for this one as well.

 

(If there is an extensive communication between modules/GUIs then sure a central broker could help a lot thats true, but for this exact situation that would be an overkill) 

 

For the second:


ie GUI 1 is top, and GUI 2 is bottom, therefore GUI 2 is a dependency of GUI 1. 

If something happened on GUI 2, simply broadcast this to GUI 1.  If something happened on GUI 1, call a GUI 2 request to inform it of the change.


I think that was the core of my question. I dont see how GUI2 can "simply broadcast" anything to GUI1 (or in fact to anybody). Broadcasts are private for the module so GUI2 can't call a broadcast of GUI2 directly. This is why I came up with that "brilliant" solution you see in the first comment. A request which simply broadcasts the argument(s) can be captured by a GUI.

 

 

0 Kudos
Message 5 of 6
(820 Views)

Sorry, I perhaps misunderstood your original post.  I assumed there was a 3rd module taking the request and then broadcasting to a GUI. With this in mind, the message broker idea is just the same thing flipped on its head.

 

For the other point, GUI1 can simply send a broadcast to GUI2, as GUI2 will have the GUI1 broadcasts registered 

Christopher Farmer

Certified LabVIEW Architect and LabVIEW Champion
DQMH Trusted Advisor
https://wiredinsoftware.com.au

0 Kudos
Message 6 of 6
(813 Views)