Logic <---> GUI, Communication over LOCAL TCP/IP

[DoctorAutomatic]

I've been using Labview since around 2014. It's definitely the language I'm most proficient in and Dev environment I'm most comfortable in. That said, I feel quite limited making exceptional GUIs. Any ideas that stray a bit from native labview control functionality are quite difficult/tedious or impossible to implement. 

I was thinking of splitting the logic and GUI to the point that a frontend/GUI could be implemented in another language. Local TCP seems like it could be a really flexible/useful way to do the logic-gui communication. 

I don't know what "gotchas" are out there so was wondering if others have gone the route of splitting their gui-logic like this. To be clear, I already try to split UI/logic, but so far both are still labview modules and communicate using uniquely labview methods (queues, notifiers, events, etc...). 

Thoughts?

[Bob_Schor]

I'm puzzled.  One of the strong points of LabVIEW (in my limited experience, having tried to make a GUI using Matlab), is how easily/logically it handles GUIs, wasting almost no time "waiting for User input" (thanks to the Event structure), and communicating very well with "working code" (through such things as the Queued Message Handler, Producer/Consumer, etc. 

LabVIEW Real-Time is sort of a GUI (on the Host, also handling some tasks such as saving data to disk) and DAQ and control on the RT Target, with communication typically via TCP/IP.  I've used Network Streams, both for Target/Host communication (one Stream Host -> Target, one Target -> Host) and for getting the data out of the Target (where it was collected) and sent to the Host (where it could be monitored and saved to disk).

LabVIEW logic makes writing the RT code straight-forward (just like any other DAQ task, but running on a Real-Time OS, with better timing and interrupt features, and (on some targets) the ability to do FPGA code.  What's not to like?

Bob Schor

[rolfk]

Bob

Some people like to create UI's that match the latest craze and will be obsolete next year already, but it's what they want and LabVIEW never was good in following these moods quickly as its development model was much slower and focused on other things than trying to mimic the latest UI crazyness of the 3 major platforms it was running on.

I personally never felt the need to put appearence above functionality when writing applications. Sure sometimes you wish a certain LabVIEW control had this extra functionality or feature and I have fougth wars sometimes trying to customize LabVIEW controls in just the right way to fit into this specific place.

That all said one can do amazing things in LabVIEW if one wants to and I have seen UIs that were not showing in any way that it was done in LabVIEW (but it was). But I never felt the inclination to spend much time trying to create something like that.

Will other Widget Toolkits solve that issue? Maybe but I have not a lot of hope. They all have their weaknesses but having to connect two different environments for visualization purposes is going to be a real challenge for sure. It's not only a lot of work but for serious data visualization with graphs almost certainly going to be a performance bottleneck too.

[wiebe@CARYA]

---

@DoctorAutomatic wrote:

 That said, I feel quite limited making exceptional GUIs.

---

What limits do you feel? Chances are there are solutions.

[Bob_Schor]

Rolf,

     I think (and I hope) that we're saying the same thing -- LabVIEW is ideally suited for this task, lacking any knowledge of the requirements for the "special" GUI (which are most likely to be "cosmetic" ...).

BS

[wiebe@CARYA]

---

@Bob_Schor wrote:

Rolf,

     I think (and I hope) that we're saying the same thing -- LabVIEW is ideally suited for this task, lacking any knowledge of the requirements for the "special" GUI (which are most likely to be "cosmetic" ...).

BS

---

Well, cosmetics can be important, critical even. Not for every application, but it happens.

In general LabVIEW is very well in doing what was intended by NI. LabVIEW is not so good when you want to go out of that intended area, even if it's just a tiny bit.

Working around limits of LabVIEW (not just GUI) can be a pain. Usually I do alright, but I'm still amazed by the cans of worms you have to open to get some simple things done. Like drawing a dashed line on the front panel...

Sadly, often the functionality is there, but simply not exposed (by design). So we have to live with the limits, or make it ourselves from scratch. That's not what programming should be about.

So I understand OPs frustration, but perhaps others have found ways around it.

[Yamaeda]

I don't know what kind of GUI you're looking for, but this one is only done with LV: https://www.addq.se/test-and-measurement/r-and-d/

The GUI itself is pretty well isolated from the rest by only reacting to Events and other processes send.

/Y

[Ben]

I had to develop a project that was sorta like what I think you are asking to do.

In my case it was an app running on a sbRIO that had to be controlled by an existing app (via TCP/IP) that talked to competing hardware. The app that ran on a PC was very mature and had oodles of functionality built in (undocking, advanced analysis, etc). In the early stages of development, I was running the OTHER control GUI on the same machine I was using for development in LV. That is very similar to what I read you proposing.

The challenge in that application was working out the interface details of the messaging and interpreting what the C# app was saying and converting the messages (difference in data structures) into a form I could use in LV.

What worked out to my benefit was the protocol was well documented (save a few errors in the documents that had gone unnoticed before I started working).

So if you are going to set off on that path, taking the time to document the messaging will help you out. If you just want to wing-it, that could work if you control both sides of the game and are willing to hack at until it behaves.

Another "gotcha" may be the port you use to talk between the two applications. TO cover tht named services may be of use.

My 2 cents,

Ben

[Terry_ALE]

See the UI Interest Group https://forums.ni.com/t5/UI-Interest-Group/ct-p/7019