ShaunR

Aha! So properties are MQTT-V5 only. V3.1.1 has those fixed fields and doesn't have a variable integer at all. That explains the fixed fields and fixed sized integers I moaned about - backwards compatibility. I'm ambivalent if I can forgive them for that as it's a noble trade-off but they could have handled it much better than they have.

It was obviously grown like a furry mold. The way they have designed it means that the user has to know so much about the protocol and what properties to bind to what messages. I'm having a hard time burying the complexity for the user. I wouldn't be surprised if a lot of the LabVIEW solutions out there are only partial implementations and ignore properties completely.

What a crappy, poorly thought-out protocol. You have a variable length integer (up to 4 bytes) but lets also have some fixed sized integer types less than 4 bytes for the giggles. You have an error byte...sometimes...with command/response contextual meanings. You have properties, that may or may not be there, but only for some commands and responses. You have command specific, fixed, fields before the properties for some commands/responses. Some commands ack, except when they don't. Half the state is in the client and the other half is in the server. A significant number of the "features" are to get around the previous bullet point.

Works for me.

You can create an icon on-the-fly using CreateIconIndirect. I have never found the need but, in theory, you could convert an image into the bitmap masks required for an icon. You could then use the WM_SetIcon as previously.

Yup. I don't go that route at all. The number of "HAL's" that I've seen that make a simple piece of software rigid and a nightmare to maintain. I go with a simple route of wrapping a non SCPI device driver with a with a SCPI compliant "controller". The "controller" is the stub I spoke about previously when no device is available - which then mutates into an SCPI driver when the device arrives (if it needs one). Then the application has a standard interface (string message) to all devices and only has to worry about what messages to send to which devices-you can even script multiple messages from text files! Much easier to change a string than a class hierarchy and, if you add a device, you don't need all the boiler-plate programming that classes require-just new strings.

Termination characters, for a start. I would echo what Rolf is saying. With SCPI you can get some of the way there as it standardises instrument behaviours - but even then it' has limitations. IMO, the most expedient way to develop when you don't have the hardware is to use stubs rather than simulators. Design top-down and use stubs where you would have a driver to give you a value and an error that you can can use to develop and test the rest of the software. When you get the hardware, you can use the stubs as an interface to a driver to massage whatever it gives into a form your software is expecting. You will, to all intents and purposes, be designing a proprietary interface for your particular software that you glue drivers underneath as and when you get your hands on them.

Have you got a load of spaces before the test.bat string? This works fine.

Start is an extension. Remove "start" or enable cmd extensions (/e:on). I'm guessing you think the "/x" is enabling extensions. It's not. There is no "/x".

That's probably a good idea and we can get an moderator to move the previous posts over.

Oh wow. I thought it was just buggy and overwriting my other images. I always used the file import because of that.

As this has popped up again and someone may find it useful. Here are some comparative benchmarks between LabVIEW and OpenSSL hashes (sorted fastest to slowest).

The System Button has the mouse over images. You can't "import parts", only the images for the states. That includes if you simply want to change the mouseover colour (copy the image, paste it into an image editor, change the colour, then import it back again). The mouseover also only works while the VI is running.

You have to program all that yourself.

OK. Decision made - reinvent the wheel The final nail in the coffin of using something like Paho MQTT was DLL distribution and integration with current features.

Me neither. What exactly are "the LabVIEW suite of offerings"? (Please don't tell me BridgeVIEW or whatever they are calling it now )

Well. They are not really equivalent. System Link is, first and foremost, a configuration and asset management tool. Buggy? Maybe (I haven't looked recently) but that could be addressed. WATS is specifically a data analytics tool. WATS has more in common with Diadem than System Link.

We shall see. The "Fat Lady" hasn't sung yet and Emerson shareholders seem more than a little unhappy about the takeover. I'm still bullish on this failing despite Dr T's intervention. The more I look at it, the more this seems like taking out the competition as opposed to diversifying and entering new markets. I think System Link was probably the trigger for this as it could, in the future, take Emersons offerings head-on and provide a far more superior top-to-bottom solution given NI's driver, LabVIEW and Test Stand support.

Actually you can sort of do this already but it's not native. Websockets made this possible. All it requires is to be able to map a web page to a front panel and come up with a protocol. It is surprisingly easy as long as you don't use panes. It would seem to be a nice feature to just lay down LV controls and for them to be replicated remotely, but then it'd just look like a LV front panel in a browser - you might as well send an image. You need to be able to customise the HTML and the LabVIEW IDE would make an awful HTML editor. It's far better to make the HTML (or get a web-dev to do it) and tell LabVIEW what controls were pressed - effectively separating LabVIEW from the FP the user interacts with. But I was thinking more of VI server being the interface for LabVIEW as a back-end, function server so that in addition to the above, it could also act as binding for other languages (RPC). They did something similar with their webserver where you could call functions but it was a hideous solution requiring deployment of the NI Webserver and Silverlight etc. You could map a web page address to a VI to call. VI server has much finer granularity than just user VI's and, IMO, should have been the starting point.

Their logical conclusion would be that it's not a big market and we can't support it. You can say goodbye to LabVIEW, IMO. This is a fantasy. Python is well known for being poor at multithreading, if you can call it multithreading. I understand that you are just trying to find a new place for LabVIEW but getting Python to support a data-flow paradigm is probably a bit too much. We have a number of programming languages and paradigms at our disposal so why try to shoe-horn everything into Python? Use the right tool for the task. I don't use LabVIEW when writing webserver code. IMO, LabVIEW's biggest weakness is the UI. Python isn't a good improvement on that and vice-versa. LabVIEW would also be a very expensive and cumbersome development tool just for planning and maintining python applications. Perhaps a more realistic solution would be to improve the LabVIEW VI server so that it could interface with other languages directly using TCP - make it more like an RPC interface. That may scratch your Python fetish itch.

I think the C compiler was (or was based on) on the Watcom compiler. Well. Callbacks are a poor-man's event. The C/C++ industry has always had problems with fitting event driven programming into their straight-jacket. They are being forced to nowadays with Service Oriented Programming and all they have is callbacks as an answer-leaving the programmer to figure out threading and asynchronous operation. It's why I prefer Object Pascal (Delphi, Lazarus et.al.) over C/C++

I always felt they could have had a tighter integration between LabVIEW and CVI. It could have solved our lack of being able to use C callbacks for a start. A CVI node like the Formula node could have been quite useful too.

Maybe. Although he's getting on a bit and has an interest in Alzheimer's. Could also be looking at passing an inheritance where a cash drop like this would be great. Difficult to understand he'd be happy about his life's work being swallowed by another corporation just for a few decimal points of his billions in cash. Interesting he talks about "stakeholders" instead of shareholders but it does not bode well for NI. The plot thickens!

I like your solution. I've always used moveblock with strlen which, although it seems faster, is far less intuitive. On a different note. Try not to use those utility functions at all. They all run in the Root loop! I may use them for prototyping but always replace them in production code.

Yup. Sorry to be less helpful. Probably the only thing you could do is to try a different manufacturers laptop which should have different hardware. I know LabVIEW 2022Q3 runs fine on Windows 11 in my VM but that's not very useful either.