ShaunR

I think you need to do some LabVIEW courses and/or tutorials. You're clearly are out of your depth here with even the concept of what LabVIEW is and how it operates at the most basic level - you have bitten off more than you can chew. Go and ask ChatGPT how to make a LabVIEW program to add two numbers and you will see the difficulties you face.

That works. Thanks.

Interesting. Not the sort of behaviour of a company that's about to roll over.

English *is* my first language and I'm not as eloquent as you are. There is no real argument here, though. I still use LabVIEW 2009 for development because there is little that the later versions offered of significance. It's also robust, stable and fast. That cannot always be said for some of the later versions (looking at you 2011/2012). Some features that actually got us excited weren't even on the roadmap (VIM's anyone?). NI have been so far behind the curve for features that we want that we have all created our own solutions so if one of them actually gets implemented, it's a moot feature. TLS/SSL, for example was only released in LV2020 but I (and Rolf) had created solutions a decade before that. The one thing we have been yelling at NI about for about 15 years is Unicode which we cannot really make a native solution for. This is why I laughed when it was mentioned in this talk. I moved to HTML UI's and relegated LabVIEW to a back-end service through Websockets which solved the problem but it's a sledgehammer to crack a nut.

I don't think anyone is saying that, so much, with respect to NI as a whole. But the effort and investment in NXG made LabVIEW (Classic?) the withered limb of NI, Now they have lots of C# devs who can't do jack with LabVIEW. From this seminar, it looks like this is a solution (lots of C# devs) looking for a problem (Cloudy stuff) and they see LabVIEW as a stagnant technology instead of the axiomatic driver behind their hardware it actually is. Don't get me wrong. They can very easily move into this space and do all the cloudy stuff. But their view of how this will fit together is flawed (IMO). They are viewing it purely like an IT system rolling out images (think AWS Compute-IAAS) when, in fact, those images will be highly specialised LabVIEW installations for very specific and usually custom hardware configurations. They lost Test and Measurement to Python a while ago-arguably the mainstay for LabVIEW.

I've really no idea what this means. If you are just looking for a volume of any code then VIPM has hundreds of libraries (with source) that you can train on. You will have 10's of thousand of VI's with source to point your algorithm at. Apart from that, you will have to be more specific. Artificial Insemination is coming for us, boys and girls.

You'll need to define exactly what "experimental setups" means - I've no idea

Chasing the golden geese, it seems. Interesting stuff throughout but the real juice is at about 55mins in the "Distribution of Resources". (Spoiler, it's a small club and we aint in it). The mention of porting Unicode made me laugh heartily though . My final takeaway was too many C# coders left over from NXG.

Maybe an option on the right-click menu?

I've no idea if they introduced an an ini setting for aliasing or a real solution for this but a classic, flat, square, button can be collapsed to 5px and, if you make the border transparent (which is 1px), it looks like a 3px line. However it won't do arbitrary angles-horizontal and vertical only. You may have to rethink how you display your fluid with either the picture control or jpg/png images copy and pasted to the FP, if it's a real issue. I'm not sure how you are using to display a fluid (reveal behind a progress bar?). I've never used decorations as they are so limited.

How to overcome this error? By doing what the error messages says.

What is it they say about the last 10% of a project is 90% of the work? I stand by my original statement "What a crappy, poorly thought-out protocol" So. Like I said earlier, 1/2 the state is in the client and 1/2 in the server. I'll add now "they have to agree". So what if they don't agree? Well, here we go. Client and server maintain a list of packets (Packet Identifier). Ok. Can do that. OK. But what if I don't get the PUBREC? I can send a duplicate right? Sweet Oh wait. Ok So we save them up for connect only. Job done, right? Ummm. So we can only send duplicates at connect (and only if it's a persistent session) and there can only be so many unacknowledged ACK's otherwise we get spanked. So what happens if the unacknowledged packets reaches the limit? Really? Go silent or hope for the best depending on the whim of the developer? Hmmm. So what does this look like in the real world. EMQX: 2 hours before getting Receive Maximum exceeded. Hive: 20 minutes before getting Receive Maximum exceeded. Mosquitto: 1 hour before getting Receive Maximum exceeded. That's no good. Lets send duplicates if we have some acks and are getting near the limit (that's what we should be doing IMHO) EMQX: 40 minutes before getting getting disconnected (Packet Identifier in use). Can't blame them. Crappy protocol. Hive: 24 hrs and still going but getting duplicates in the subscriber (that's not right for QOS 2 but could live with it.) Mosquitto: 24 hrs. and still going. No problems. We have a winner! This is a doozy too: Fix the state (normally that would be with duplicates), restart (without persistent session-poor subscribers ) or blame someone else. Am I missing something?

This is an interesting feature that I guess is one of the mechanisms for clustering. It's basically like an HTTP redirect but I'm not sure how I'm going to handle it ATM. CONNACK is fine but a disconnect is usually the end of the conversation with an error 66. Interesting that they don't mention a redirect depth.

Indeed. It's not so much a time window. It's if packets are unacknowledged for the QOS modes. The Packet ID is shared between the Server and client in order for them to synchronise state for the duration of a packet in-flight. That's not an issue for the library as it necessarily needs to do that but I expose the Packet ID to the user in order that they can do session packet tracing. A server, for example, will take into account which packets are unacknowledged for a session and may resend or an unknown Packet ID is received and the connection must be closed. True. However MQTT can retain sessions across connections. In order to do that it keeps a track of the unacknowledged Packet ID's (QOS 1&2). Technically, they should be able to cope with a random vs sequential Packet via lookup tables if the user really needs to but I thought maybe there was a use case for sequentially increasing Packet ID's to, maybe, identify packet order.

Ok. Turns out that Mosquitto and Hive partially support MQTT v5. Mosquito more than Hive (or it may just be more tolerant) but not all the properties in the spec. So they are probably v4.x. EMQX is a 14 day trial so I didn't bother with it in the end. I'm just embarking on the cleanup and documentation (the fun's over ) but I have a quick question about the packet ID's. The spec doesn't define what they should be apart a u16 and non-zero (when they are there). So I decided to make them random (usually a good choice in crypto stuff). Mosquitto uses sequential incrementing by 1 and Hive uses sequential incrementing by 50. Technically, they are only used internally by the clients and servers but I was wondering if anyone relies on them being sequential for other things where a random packet ID would be a pain?

Sweet. I'll check it out.

Well. It didn't take long to prototype the MQTT client as I was expecting - once I figured out it wasn't my code and it was just properties weren't supported by the public Mosquito server. The Hive MQTT public server doesn't seem to support V5 either. Anyone know of a public V5 server?

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.