ShaunR

Many of us aren't fans of QMH. I'm somewhat ambivalent about them but a couple of points I will make from your description. 1. Future proofing is marketing speak. Adding complexity for something that is not required and just a guess as to future requirements is unproductive, will bite you and adds nothing except complexity. Design your system for the requirements now and iteratively innovate when necessary to encompass new requirements. Experienced engineers will recognise patterns in solutions and code in a way that they know will be easy to modify in the future but the key point there is easy to modify, not seamlessly integrate. 2.If you are going to have multiple consumers of your messages/data then queue based message handling is probably the wrong solution. You will get tied in knots re-transmitting messages/data since queues are a many to one topology and you are trying to create a one to many or many to many architecture. An event based architecture is much more suited to this but you will find very little in the way of formal examples or templates outside of user interfaces. 3. You can have more than one architecture within your program! I see this all the time with even knowledgeable engineers. They choose a magic bullet framework, shoehorn all their code into it and it becomes a mess that only the developer can ever understand and is riddled with bugs. Modular code can have frameworks or architectures at the module or abstraction level and you can mix and match dependant on module requirements (QMH, State Machines, Producer Consumer etc). You can then choose one or more architectures to sew all the modules together to form a cohesive program with defined areas of responsibility that can be debugged in isolation. When new to designing software systems I would suggest the following axiom when using LabVIEW. Design the system top down (from the UI usually) but create the modules/code bottom up. A natural partitioning of code reuse arises from bottom up that is different from the partitioning of responsibilities that top down produces. It is reconciliation of these two partitioning views that yields robust and modular code. So. Enough sermonising Here are some insightful write-ups you may find useful NI QMH Template QMH's Hidden Secret Some Context

Correct.

If you want a queue. Use a queue primitive. The queue that is used for events is an opaque implementation detail that is part of how Events are realised internally within LabVIEW. If you want a more accurate timestamp, pass it as a parameter. In some of my event systems and even some TCPIP implementations I have a "send" time. You can hook the event with a viewer and logger if you want to analyse your messaging and compare sent and received times. Forget that events have a queue and even forget that they happen to have order on any particular event stack. Certainly don't rely on it - you'll live longer and with more hair.

There are two modes of operation that users typically want. A single application which deals the same data to multiple clients. This is fine for read only interfaces but for bidirectional you have to decide who has control for sending data to it. One client to rule them all otherwise you get config whack-a-mole.. It is the preferred option for resource reasons. An instance for each client which allows each client to control their instance. Each client sees something different and if making them all see the same thing is required, you have to handle it in the software itself (centralised data store) . This is extremely resource intensive and can bring your server to it's knees with enough clients. There are lots of similar projects around the web . With this one, you create plug-in data sources that interface to your back-end. I prefer that model otherwise they would have to define a propriety protocol and dictate comms methods. This way they leave it up to you, which I prefer. There are examples and fairly easy to implement.

Yes. If you use the Variant To Flattened String instead you will see the type info on the separate terminal. That won't get rid of the length byte that is prepended to strings though. You will have to process the flattened string and remove that manually.

Sort of the wrong question. It's like saying can my TV pick up satellite? Well. Yes, if you have the right receiver. Can you build browser interfaces to LabVIEW with menus, cursors and sub panel mimic screens with these tool-kits? Many of them, yes. Getting UI information out of LabVIEW into a browser is trivial. Getting the user control requests back in to affect LabVIEW is far more complicated and requires a protocol your specific LabVIEW implementation understands. Is there a wrapper solution that you flip a switch and it is in your web browser? Yes. It's called Remote Panels. I think people see these technologies fundamentally differently to me. I see it as a way to "fix" what NI refuse to do. Maybe I have to address the general need rather than just my own and my customers' for this technology. I see developers being able to view/gather information and configure disparate systems in beautifully designed browser interfaces with streaming real-time data from multiple sensors (internet of things) Interfaces like this but with LabVIEW driving it. Customisable dashboard style interfaces to LabVIEW and interactive templated reporting - all with LabVIEW back ends. You can do this with these toolkits. Most LabVIEW developers, however, just seem to want their crappy LabVIEW panels in a browser frame . That is like being given a house and using it as a shed.

I think it is a good idea to do so. This is detracting from ThomasGutzlers software solution which is an ongoing development and that is getting lost in the general debate.

That just boils down to "I don't know how to do it and I won't pay someone to do it". When you realise that it is just messaging for control and UI updates you end up at a point where you can use any user interface in any language and two main possibilities come out when web browsers are concerned - REST and Websocket Then you start pressurising the IT departments' web developers to stop playing Doom and do something useful . Hooovahhs list is proffered as all products being equivalent. They are not. They just have the common denominator of being able to display a LabVIEW UI in a web browser and demo as such for LabVIEW developers. If your current client server/relies on NI Server remote functions. You are locked in, I'm afraid. If you use messaging, you can create headless, back end services with rich browser interfaces to serve multiple users.

I presume you are using custom scales so you don't have to calculate inside your code? A quick win over the classic read-then-write for DAQ is to pipeline. If that isn't good enough you may need hardware timed, clocked and routed signals and that will be dependant on the hardware you are using.

If you're giving away free advertising I expect at least a mention

I'm feeling a bit left out

That sounds more like a virtual function declaration than a callback. LabVIEW supports those less than callbacks . A fully encapsulating C/C++ wrapper for the DLL exposing an initialiser to give a filename is probably the only option here. It sounds like the DLL isn't an API but more like just a compartmentalised piece of code that needs a lot of scaffolding to make anything useful even before you get to interfacing to LabVIEW.

Easiest way. Create a buffer (U8 array) when you initialise the DLL event reference. (pass in an already initlaised array of bytes using the Initialise Array.vi). In the callback function; dereference the data and memcopy to the buffer you allocated at init. Then PostLVUserEvent the array. No mutexes required because memcopy is atomic and LabVIEW has its own managed memory copy. You can read the array directly out of the terminal of event structure. There is no way to get out of requiring a C/C++ DLL to do this mediation for you, by the way - LabVIEW cannot create C/C++ callbacks If you can find a .NET version then you can have a VI callback function IF they properly advertise the event, though.

You can't create C/C++ callbacks directly in LabVIEW but you can create a DLL or wrap an existing DLL that registers for the callback and generates a LabVIEW event.

I was meaning using the control label like the following so it uses the same semantics as the event primitives.. The only reason I had a text control with the name in the text was because the VIM wouldn't transfer the label name inside it's macro so I couldn't read it. Otherwise I would have done so. You can do this with Xnodes though I think. Hint: Use messages "UI>MOTION>SET POSITION>x,%.3f", "UI>MOTION>SET POSITION>y,%.3f", "UI>MOTION>SET POSITION>z,%.3f" and have one "MOTION" service instead of having 3 actors.

Name: VIM HAL Demo Submitter: ShaunR Submitted: 25 Sep 2015 Category: *Uncertified* LabVIEW Version: 2009License Type: MIT This is an experimental demo to investigate VIMs (vi macros). It was a bit of fun to see if VIMs could be used to encapsulate events in LabVIEW which was a bugbear of mine for quite some time. You can see the entire thread here. VIMs are a NI experimental technology similar to Xnodes but less mature. The purpose of this release is to clarify the previously unstated licence since other forum topics are building on the original demo so they need a permissive licence (MIT). This release serves as an unambiguous statement to that effect. There are a few differences from the original which I have decided to call version 0.1 but they are minor. Note: This may or may not work for you out of the box. If it doesn't then please do not post. The purpose is to clarify the licence for others to build upon; not to provide a working example. The VIM technology is itself experimental and unsupported by NI so most issues you will encounter will be due to this and It is unlikely there will be another version posted here. Click here to download this file

Sounds good. I'm not really suprised you are having these difficulties. When you consider others talking about identifying which features are available in which LabVIEW versions, you know backwards compatibility is broken..So far, no-one has revealed what the common sets are, preferring to play with the latest and greatest. With your multiple axis motion controller; I disagree. In the service model you would just have a Motion Controller Service and send it X, Y and Z commands or more likely "TABLE>MOVE>PRESET1" or similar. There should be no reason why you cannot have multiple versions of the same type unless I'm missing something. Only the name string is important and that is derived from the constant label (this is how queues work after all).. The constant's name should dictate the event name, not the data type Even if you do name them the same it is basically a no-op for whichever call gets there second. The events are global so two events with different data-types that have the same name is not desirable or needed and would have so many caveats as to make them unusable, IMO. So I'm not really sure what issue you are trying to solve by adding the terminal back in. That just seems to be the motto for Xnodes A good improvement on the last one, though. Before, It had the same problems as the VIM and then some. It worked out of the box this time for me so thats great.

I think you are probably looking at it slightly awkwardly. You went for compartmentalised solution according to some best practice ideology and then found it got awkward for concurrent processes. You want it to be easy to manage and scalable, and the way you did it was exactly that, but the downside was creating bottlenecks for your asynchronous processes. You have the SOUND.vi problem whereby I needed to be able to play arbitrary asynchronous WAV files simultaneously when a single sound could be 10s of seconds. If the SOUND.vi could only process one message at a time that was useful but I wanted a more generic solution. Sol. I made SOUND.vi a service controller.Other processes ask it to "PLAY"a particular file. It then launches a sub process for that file and returns immediately having no more involvement in the data transfer. How could this work with, say, TDMS? You have the FILE service. You send it a message like FILE>STREAM>TDMS>myfile[.tdms]. The FILE service launches a listener that is registered for "myfile" messages. You tell the DAQ service to launch an acquisition - DAQ>STREAM>AI1>myfile. or similar And that's it! The DAQ pumps out messages with the label "myfile" and the listener(s) consume them. Of course the corollary is you can use "FILE>STREAM>TEXT", "FILE>STREAM>BIN" etc, even at the same time .and you still have your FILE>WRITE and FILE>READ which you don;t really have to launch as sub processes. You've started a producer and consumer and connected their messaging pipes. You can do that as many times as you like and let them trundle on in the background. Your other "plugins" just need to send the right messages and listen in on the conversation (also register for myfile).

I have something that I use quite a bit for many things but I don't think I have anything as sophisticated as you would be requiring. It's like a trackable "completeness" application-how complete a project is. It checks descriptions are filled out, whether VIs are orphans, re-entrant and lots of other things for keeping a track of a projects progress and making sure certain standards are met. You can compare previous project scans and do diffs of the changes in issues. It has plugins that can access its database so you can extend its features pretty much indefinitely-I've been abusing it recently by adding scripting functions to set VI names, making them re-entrant, and other bits and pieces which it shouldn't really be able to do for a passive analyzer.. It doesn't do testing as such but it supports plugins so you could create a plug in or two to populate its database with results or attach another database to do cross DB queries. It also allows in-place SQL queries so you could also define views of your test data combined with all the other VI information. There is already a plugin for requirements coverage ala Requirement Gateway. Its one of those tools you always use but would be a nightmare to productionse and could cause havoc in the wrong hands.There is an image on LavaG somewhere

I was trying to decide how I would describe the difference between an API and a Service succinctly and couldn't really come up with anything. API stands for Application Programming Interface but I tend to use it to describe groupings of individual methods and properties-a collection of useful functions that achieve no specific behaviour in and of themselves - "a PI". Therefore, my distinguishing proposal would be state and behaviour but Applications tend to be stateful and have all sorts of complicated behaviours so I'm scuppered by the nomenclature there.

Well. Seeing as your multicast address starts with 235, I would say probably not. However, I avoid Linux whenever possible so I cannot help much further than saying what the net address is for because it will depend on how you set up the network cards and firewalls in all the layers (including Windows).

The net address is for the address of your network card and usually only used if you have multiple cards installed in the system so you can bind to a particular card. You have quite a stack of network virtualisation there.You'll probably have to set up routing to forward UDP multicast packets from your router.

I get the feeling we are talking at cross purposes. All file reading and writing must go through the OS (unless you have a special kernel driver) so I don't really know what you are getting at.

I'm saying let them write it as a service and co-opt it for your reuse libraries/services if it looks interesting and useful If a facility doesn't exist, someone has to write it. Software doesn't spontaneously come into being because you want it. Well. Not unless you are the CEO. So look at my FILE vi again. It opens a file and sends the contents to whoever requests it. The FILE.vi does not care about the file itself, it's structure or what the bytes mean but it does require it to be a "normal" file with the open and close. The FILE.vi can read a lot of files for most scenarios (config, INI, binary, log files etc) but it cannot currently read TDMS files because they need a different procedure to access them and TDMS aren't required for this demo.. Can I add it to the FILE.vi? Sure I can. I can put the code in the FILE.vi then other modules just use the message FILE>READ>TDMS>filename. Do I want to? Maybe, if I think open/read/close of a TDMS is useful. I could also create a STREAM service that may have a state machine (see the TELEMETRY.vi for a producer consumer state machine) and allowing other module writers to access that via it's API. (STREAM>WRITE>TDMS>filename etc) Now I have another service in my application toolkit that I can add to TELEMETRY, FILE, DB, SOUND etc to make any other applications. Maybe I do both You will notice that either way. The other modules/services only care about the message, not the code that actually does the work or where that code is (It could be on another computer!) and I can partition the software within my application as I see fit without interference from other modules/services. I can also add more APIs and more commands to a single API without changing backward compatibility (within reason) Saying all that. Maybe your use case requires a different architecture. There is no one size fits all no matter how much framework developers would like theirs to be.