ShaunR

As you are the only one that has commented on it al all (indirectly). I think that's a resounding "don't bother". Also means I don't have to look too closely at DTLS just yet

So. that's a resounding "don't bother" on the CoAP then

If Emerson buy NI, you can look forward to no LabVIEW at all.

Here is a List API. Seems complicated but it's a "managed" list with lots of features. Overkill for what you need but it demonstrates a point. You could use it for your data but then you'd have a dependency. I'm guessing you don't want dependencies at this point. You'll notice it has two items in the cluster - Name and Variant (variant is a general type and think of it as your Cluster). The important part is that it has a "Name". This is a poor replacement for the Cluster Name (functionally) but it does enable lookups, even by regular expressions. It serves a very similar purpose but operates at run-time instead of design time The name is just a string label. It can be anything. Granted it's not as simple as an enum but it does give much more flexibility and doesn't require design time editing of the control to make changes. The tradeoff is complexity. Now you have a way of making a list behave like a database but you need specific functions to look up and return data. This, from one of the list examples, returns all items with a numerical label: Intuitively you will realise that having duplicate data is not very useful unless you can distinguish between the original and manipulated. Up until now you have used the Cluster with an unbundle which has served you well but are now finding that you need to edit the cluster every time you add new variant of your data. The label gives you that ability at run-time instead of design time with a small increase in complexity. However. Your biggest issue is compartmentalization - separating config from data. Now. What if only the List (aka data array) wasn't tied to a particular data type? Then, by thinking carefully about the labels you use, you would be able to differentiate between the different data types, different devices and different configs There are other ways to approach this. But from where you are at present I would suggest this way - at least until you are more confident with your abilities. The database I suggested earlier requires a different mind-set and classes are a huge learning curve. This is a modest step from where you are to where you want to be.

If you are going they way I think you are, all you will do is swap [un]bundles for VI's and add a lot of boiler plate. To be fair. You monster cluster isn't really that much of a monster-more like a tribble. My advice (if you're not going to re-architect) would be just to split out the data from the config. Your All Scan data BG and HRS is actually an identical format so you could rationalise that into a single array which will make adding more of the same format easier (just add and index into the array-no need to modify the cluster to add more data). Everything else seems to be config data.

Break down your complex and complicated data types into a complex and complicated architecture. FTFY

I expect you have. Have you also thought about using an SQLite database ?

Last time I looked it was about 1.1.1e. I don't think it was much better. I bypassed it in the end because it needed callbacks for cookies-wasn't prepared to do that at the time. I'm hoping they've moved on from there with full blown certificate verification but if they haven't, I now have a place for callbacks in the API.

source I guess you don't have the Full or Professional LabVIEW?

Building the protocol from scratch isn't a barrier for me - I'm on a roll The difficulty is that it requires DTLS (the UDP version of TLS). DTLS is something I've played with in the past and it was somewhat awkward to integrate into what I have currently so I moved past it and on to other features that I desperately wanted. CoAP would force me to look at DTLS again as it is something I've wanted, but never had a need for. IMO CoAP is a far superior protocol to MQTT. I don't really understand why MQTT gets so much love.

Anyone interested in CoAP?

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.