GUI for a DQMH module?

[1984]

Hi there,

I continue my journey with the DQMH pattern and I've already created fair amount modules, mostly for instrument (eg: relay boards, power supplies, cylinders etc). Not sure if that matters but I'm fairly happy with them 🙂

The next challenge though is that on the GUI of our application we need to provide an interface for the user to test the instruments. The different instruments will be listed in a listbox and once the user clicked on a line a panel for the given instrument will be loaded to a subpanel. First I thought that I could load the main VI of my module to a subpanel, but well... that doesnt seem to be a good idea as it doesnt have buttons and indicators to show to the user.

The automatically generated test panel could be another option but its just a simple VI I should keep launching and stopping it over and over again. (or just run it async, but thats not something I'd prefer to do). Not to mention that the test panel may have features, I dont like to show to the user, or maybe a given instrument should have different test panels. Overall my impression is that the generated test panel is an awesome tool to debug my module, but its not for showing to the end user.

Another idea was to create another DQMH module surving as a GUI test panel for the DQMH module. I'm not sure if its genious or dumb, but something suggests me that its rather the latter. Its tempting cause it would be easy to create, but having a traditional DQMH module and a GUI one for the same instrument doesnt sound right.

So now as you have some clue about what I'm supposed to write I'm wondering what would be your approach?

Thanks.

[Ozfarmboy]

At Wired-in, we've used all of those approaches in different projects.

Probably our most common case is the instrument module GUI is the Main.vi of the module. 

In our systems, we've often got the need to run an automated chain of events, but sometimes we want to manually drive the instruments.

When it's in auto mode, we lock the front panel (ie disable all controls) of the instrument module's GUI, so that the user can't interrupt the auto sequence.

When not in auto mode, the user can use to the instrument module's GUI to drive the instrument manually.

This video gives you an insight into this approach - showing an example of a real DQMH module and how we created it: (82) 8 Reasons for encapsulating your next device driver inside a DQMH(r) Module Session 2 (#VIWeek)...

We don't always do it this way.  Sometimes we have another GUI like you suggested.  Sometimes we share the testers as separate diag tools if they need to talk to the instrument directly.  This just worked well for us last week where the main application wasn't running, but when they ran the tester (built as an exe), there was more information and we could work out the issue.

[Dhakkan]

Disclosure: I don't have a commercial deployment of DQMH-based solution (yet), but the framework interests me a lot.

You both already alluded to the train of thought - my approach is, if the intent of the GUIs - (manual mode, test VI, diagnostic tool) and the end-user's needs do not match 100% all the way into the foreseeable future, then I provide a separate GUI for the end users. This provides a comfortable separation of purpose and makes it easier to respond positively to end-user change requests.

Ideally, the end-user GUI itself would be indirectly communicating with instrument modules via a 'Controller' module. The GUI module's logic would be limited to managing the GUI elements' state in harmony with the 'system state'; and communicating user-initiated requests to the controller. This controller module would be managing the system state, thereby holding the crux of the application's business logic.

This approach has names in the software engineering space, the particulars of which confuse the heck out of me (MVC, MVVM, MVP, etc.). However, it's a generally recommended paradigm to keep the GUI module logic (View) as lean as possible, and separate from the application business logic (Model).

[joerg.hampel]

Before I met DQMH and fell in love at first sight, I developed and used a proprietary framework which by design and implementation did not offer any way to show the front panel of a module (a library of functions). It separated strictly between modules and views.

I always found that strict separation to be limiting - or rather, I disliked the extra effort needed to create and maintain a separate UI for generic reuse modules. 

With DQMH, I find it quite handy that a module offers all the scaffolding needed to make good use of the UI, right out of the box. For generic reuse modules, that UI will always look the same anyhow. And, as mentioned here before, for any project-specific needs, it's straight-forward to just create a specific module on top of those generic ones.

[1984]

Finally I had some time to check out the video you have linked, good job explaining your ideas. I believe the problem (or rather dilemma) I tried explained is visible here: https://youtu.be/Q8Tte_rntNU?t=2951

Your Tester Meters API looks good from the GUI standpoint but if its displayed in this way in your app then the user get access to the default API buttons (eg: create module, stop module etc) which could cause issues.

In my mind the application takes care of the initialization of the DQMH modules at startup (invisible to the user) and the user will be able to interact with the test panel without being able to for example close the communication, or stopping the module. 

Looking forward to hear your thoughts.

[Ozfarmboy]

---

Your Tester Meters API looks good from the GUI standpoint but if its displayed in this way in your app then the user get access to the default API buttons (eg: create module, stop module etc) which could cause issues.

---

Yes.  It wouldn't take much effort to create a mode in your tester, that when running as part of a runtime application, the user's access is limited to only certain requests, and not all.

---

[1984]

I was thinking about this a bit more and I dont think that the situation is this easy. The API tester generated by DQMH could be significantly different than the GUI I'd like to show to the end user.

My thoughts only:

1. The API tester:
   • is for testing the core functionality of the module
   • from the look and feel perspective it doesnt have to be very sophisticated
   • and as far as see it really should not have too much of an extra code besides what is automatically generated.
2. The GUI of the module we'd like to display to the end user:
   • feel and look is important
   • could have lots of extra codes as its not only a interface to the DQMH module but also could realize more complex functionality than the API tester (eg you have a module to work with databases then the GUI itself is probably a specialized implementation of the module working with the database of the end user)
   • parts of the code from the API tester are removed (eg. most likely we dont want the user to start a new instance of a cloneable module)

Its seems that I can't save my the time to really create a GUI based on the API tester. Would be nice to automate though that if I create a new request then add it not to the API tester but to the GUI as well, cause deleting an feature is hell lot more easier than adding it manually.

[joerg.hampel]

---

@1984 wrote:

Would be nice to automate though that if I create a new request then add it not to the API tester but to the GUI as well, cause deleting an feature is hell lot more easier than adding it manually.

---

Why don't you jump over to the feature requests section and post this idea?

[1984]

I dont know if this one would be a useful / reasonable request or if its one of the useless / dumb ones. You have a lot more experience in DQMH so let me know if you think it makes sense. 

No offense if you'd put it to the second category 🙂 (really).

[joerg.hampel]

It sounds generic enough to put it to the kudos test:

"optionally, add a button and event case to the main.vi for a new request, to be able to trigger the same MHL case from the module's UI."

I would vote for it 🙂