ShaunR

Perfect for the OP if that suffices then.

Just download VIPM today and activate a 30day trial to try out VIPC files. Pretty sure it is a pro feature. You may be able to use VIPC files in the Community version but I'm sure you can't create them without the pro version. Maybe it's changed since I last looked though.

As an addendum... I did something very similar to you many moons ago. Maybe it will give you some ideas. Here is "Dispatcher". Should work fine for you as long as you don't select TLS. Just open the project and run the file Demo - Run ME.vi (then press Register and Subscribe buttons). It also does stuff like compression and blowfish encryption. It's a simple custom, home-grown, protocol that I wrote to explore high-speed data streaming before the more modern protocols were available. The Dispatcher, Publishers and Subscribers can run on any machine that has network access-they don't all have to be local to each other. There is an API that can be used to implement it in applications. It's not really a product so not much in the way of documentation, I'm afraid. Dispatcher.zip

Tough one for LabVIEW. It's a bit like RTSP - there's nothing until someone writes it. OpenSSL has QUIC support. M$ have .NET support and MsQuic. RabbitMQ is discussing whether they should or not. I will support it later this year (waiting for OpenSSL version 3.6). I have some LabVIEW prototypes that I've played with and it's damned fast with almost no overhead. It has in-built failover and multiplexed channels making it ideal for your use case. Your idea of streaming directly is a good one, though. You don't really need a higher protocol unless you can identify a particular problem you need to overcome. Websockets is another that would be a good start because you would be able to have an Apache/Nginx server for routing or even send the data directly to browsers. Hmmm. Yes. Considering where you are now I would recommend Websockets. They are probably the easiest and get you almost all the way to where you want to be and a good start for expansion later for streaming in other more efficient and scalable protocols like QUIC. I think there are a few LabVIEW Websocket implementations to choose from so you wouldn't have to write your own.

Not sure what a "wheel" means in this context. I've only ever seen it in context of A.I. python scripts. If you are just looking at toolkits installed with the JKI Package Manager then the full version can create super packages where you can create a list of toolkits to install. you could then walk from PC to PC with that package and install them with the package manager.

QUIC

Hey Person of Fancy If you want device drivers, DAQ, vision toolkit or 3rd party driver support then VM is the way to go. All versions of LabVIEW work fine (with caveats) in Virtual Box and VMware - just read up on NI's licencing requirements for VM's. This will be GB's of data each save and VM's run like slugs compared to your dev machine. Also the computer hardware will not be representative of the final target you will deploy to. So beware- here be dragons! When it comes to LabVIEW, I also have USB sticks with customer specific versions so that I can go on-site and seamlessly integrate into their teams. These are only applicable if device drivers et. al. are not a concern (e.g. UX, TCP, GPIB, Web Applications and stuff like that). Some want me to keep the USB while others want to keep the USB stick with IT - in the latter case, source control is their problem and for the former I just check in the entire USB stick. if you don't use a VM and have multiple LV versions, there are 2 issues you need to be aware of You can only have one NI-DAQ version across all LabVIEW versions (this is the main reason why you need VMs but there are others). If multiple versions are needed in different LabvIEW versions then VM's is the only way. Recompiling in a later version is a huge risk because back-saving is, anecdotally, about 90% reliable and can easily fail in convoluted cases. The best defence is to adopt a workflow that mitigates the chance and rely on source control when that fails or vice versa. Projects are relative paths so as long as you include all code under your project directory (and don't scatter it around different drives and non-hierarchical directories) you should avoid this most of the time. For those times you don't, revert from source control or back-save. Keep your project code separate from vi.lib!

Homework done help reqd_sr_1.vi

Homework done help reqd_sr_1.vi

Unlikely. You clearly have a lot more decoding layers than you have shown so far (is that a DrJPowell messenger vi rather than a network stream vi?). The probability is that your variant isn't what you think it is or your middle layers are modifying the variant (casting to strings and including a length, for example). Using the send in your example, write the example for receiver that I showed previously and test it can be received and decoded.

The variant in your image is a cluster, not a string.

When you send the message you encapsulate the message as a cluster of string and variant. You don't seem to unwrap the variant from the name/variant cluster in the receiver. What I expect to see is something like this in the receiver:

You didn't give the text, just an image of the text. You didn't give us the VI you were proposing. We've no idea what the cluster is that you have wired that must match the XML. Your XML has many, many problems. e.g. <string> <name>adresse</name> <val>fabio....</val> </string> That is not a string, it is cluster of "name" and "val". It cannot be converted into a LabVIEW string type if that is what you have wired to the the primitive. Generate the XML from your cluster that you have used with the unflatten then compare with what you have in your XML text.

I'm not sure that would be all that interesting (for you). Most of what I think is far more eloquently communicated by Alan Kay in his musings. e.g. "Computer Science isn't real science!"

When have you known me to have a weak opinion? If you have to have a consortium to manage it and spawn an entire industry in order to use some code then it has just become a means to justify an ends. Wizards and scripting are symptoms of excessive boiler-plate generation, lack of reusability and, even worse, trying to hide it. I'm not against frameworks, per say, and In that respect I would argue that DrJPowells solution is the best of the bunch although it uses the OpenG tools heavily so it is not usable to me. By the way. I don't have a personal framework as such. Services are communicated to and from with messages and all messages are strings. You don't need lots of framework for that-just a couple of VI's in a polymorphic. The Services themselves can be anything you like, as long as it works - choose your poison! They come up with this kind of "solution" every few years and then run with it until it the next thing. First it was State Machines, then QMH, then it was Actor Framework. Oh and what about that silver bullet of Systems Software that I can never remember the name of? It's all "One Ring" software. In current years it seems to be this special QMH with knobs on (and committees, working groups and special events that everyone can go to to pat each other on the back). The sales pitch is usually that "this" framework will mean interns churn out the code of 20 year experienced CLAD's. It never does, of course. It always ends up as bug ridden 10,000 VI monstrosities that take 10hrs to compile. They've been trying to replicate experienced programmers' outcomes with processes for over 50 years. It has been such a failure (the philosophy rather than any individual framework) they had to convince everyone that continuous updates were the answer. To paraphrase the words of a wittier person than I, "If the milk turns out to be sour, I ain't the kinda pussy to drink it."