Neil Pate

1 hour ago, ShaunR said:

When have you known me to have a weak opinion? 

Literally never. Which is why I value your input into the community so much. (No sarcasm intended).

Would love to sit down and have a few beers/coffee sometime and muse about the state of many things LabVIEW-ish and other stuff.

@Mahbod Morshedi no need to apologise at all. This is a journey for everyone and all the opinions here are given with absolute kindness in mind, just sometimes the message gets lost in text.

If you add new features to your application, there is no need to make a new wire. Assuming you have some kind of core cluster you would just have a single wire through the whole application and you can add new stuff into this cluster. Now, that will start to get clumsy at some point (when it reaches what we sometimes call "megacluster" status). 

To prevent this from happening it is normally better to try partition your application into independent things, (loops) that contain just the data they care about. Then each thing becomes simpler.

Then you need to figure out how to communicate between these things and you go down a rabbit hole.

Have you looked at one of the popular frameworks like DQMH?

20 hours ago, ShaunR said:

I think you'll find the polymorphic VI is used to get the data back out again. One of the issues with LV is that it's very easy to get data into a generic form but it's a bugger getting it back out again due to strict typing. I used the polymorphic method for reconstitution when I created a JSON parser that encoded to string (the ultimate variant) and one chose a polymorphic instance as to how you wanted it back out (string, U64, DBL etc).

yes but I think X means creating polymorphic instances for all the unique typedefs/clusters inside, so not just the normal primitives that you can create once and forget about. 

3 hours ago, X___ said:

You are reinventing variant attributes and the corresponding primitives (see my post above).

This being said, there is a lot of things to be commented on your code from a G-style point of view :-) but I'll leave that to others.

As far as wrapping the Variant to Data primitive into a polymorphic VI, see my comment above as well. A nicety, but is this really worth the hassle?

I have done that myself for a few common types (numerics, string, path, and array of such) and I find that very handy, but I wouldn't bother for types I use occasionally, and in particular, application-specific types. Just my opinion.

yup, completely agree with this ^^^^

I have done something similar in the past where I used a global variant as a data store, and then used attributes to store/get data (and some convenience VIs to convert to the known types). It was a bit of an experiment in a system that had many data generators (different interfaces to independent pieces of hardware) and several hundreds of data variables (tags) all communicated over OPC-UA, so had a fairly sophisticated method to set/get by name as I didn't want to deal with such a mega-cluster anywhere. It worked fine, but in the end I would not really recommend it for simple systems where you just dont want to make the proper data types.

Well then I don't get the question I suppose.

Have you looked into typedefs? This solves the problem of VIs breaking if you modify the data structures as there is then only a single instance of the definition of a data type.

How do you look up the data in your array? Via --Tag?   If you are going to do that you might as well just use a map.

But anyway, I am not a huge fan of this approach. I think better composition into clusters or objects will also make your wiring neater, more testable, scalable etc

I do recognise the need for nice neat diagrams without wires going all over the place, but proper decomposition/architecture normally fixes this.

So in general I would have to say you are not on the right track with this approach, but this is of course just my opinion.

That is weird. No sorry not seen that before!

So you have tried manually changing the tool?

@Rolf Kalbermatter the admins removed that setting for you as everything you say should be written down and never deleted 🙂

2 minutes ago, ShaunR said:

1.8 MB? 

yeah that is the payload 😉

23 minutes ago, ShaunR said:

Heathen 
16.37 kB · 0 downloads

😂😂😂

I also realised I messed up my benchmark and the final High Precision Time should be after the sorting. I meant to do this just forgot! 

Done some simple testing.

On a directory containing 838 files it took 60 ms.

Have you tried this? The `last mod` output should hopefully give you the timestamp of the last modification, and it would then be pretty simple to find the latest.

I have no idea what the performance of this would be if you loop over 10000 files. That is something you would just have to try.

I actually had a similar experience when first moving everything to the new OpenG structure. It broke heaps of stuff (even inside its own OpenG stuff), so I rolled back the change.

Some time later I tried again, and think I did have to deal with a bit of pain initially with relinking or maybe some missing stuff, but since then things have been stable.

Put the acquire image and save to file in the event structure timeout case, but only write to file conditionally (i.e. if the user has clicked the button)

ok, a couple of things to address. The IMAQ close error probably happens because there is no open session the first time. It would probably be fine just to silence that error by clearing it.

The first error is a bit surprising as you dont have a timeout value wired into the case-structure so I would have expect that portion of the code to never execute. Another slightly strange thing is the name of the VI in the error message does not match the name of the VI in your code (IMAQ Write BMP vs IMAQ AVI 2 Write Frame). 

Try wire a value into the timeout (like 1000 ms or something like that) and move your acquisition code into that event.,

I do not currently have the vision toolkit installed so cannot test your code.

@Natiq this (non-functional example) should be enough to get you started. The weird arrow thing on the boundaries of the while loop is a shift register.

The event structure can also be configured to have a timeout case where you can then perform other stuff, like reading your image and writing it to the reference on the the shift register.

There is heaps of information out there (YouTube for example), a bit of searching will lead to some more details.

You have not implemented the Event Structure.

Close should be inside the loop. Before you start a new file you would close the old one.

The file reference you get from opening the file would be put onto a shift register so that you can access it in the next iteration of the while loop.

Can you share your code?

You are likely getting only 1 video because you are re-using the same filename.

There are a bunch of ways to solve your problem. For me the easiest would be to look to using an Event Structure as this stops you from needing to poll the button all the time. Do a bit of googling to see how the Event Structure works. (tip, you will configure an event that responds to the save button click, and in that event you will prompt for a new filename (or autogenerate with timestamp) and then open a reference to this new file).

2 hours ago, Cat said:

Hellooo?  Anybody home?

For those of you who don't remember (or weren't even born yet when I started posting here 😄), I work for the US Navy and use a whole bunch of LabVIEW code.  We're being forced to "upgrade" to Windows 11, so figured we might as well bite the bullet and upgrade from LV2019 to LV2024 at the same time.  And then the licensing debacle began...

Due to our operating paradigm, we currently use a LV2019 permanent disconnected license for our software development. This was very straightforward back then.  But not so much with LV2024 and the SaaS situation. Add to this the fact that I can't talk to NI directly and have to go thru our govt rep for any answers.  And he and I are not communicating very well.

I'm hoping someone here has an answer to what I think should be a really simple question:  If I have a "perpetual" license with 1 year service duration for LabVIEW, at the end of that year, if I don't renew the service, can I still use LabVIEW like always, as if I still had my old permanent license?  I realize I would not have any more support or upgrades, but that's fine.

I've read thru the threads here and in the NI forum about this, but they mostly ended back when no one really knew how it was all going to shake out.  So are we locked into either our ancient LV versions forever, or are we going to be paying Emerson/NI every year for something we don't really need?

Cat

Welcome back! Yes we remember you 🙂

So I think you can now actually buy perpetual licenses again. I have not needed to do this myself as my org has an enterprise agreement with NI, but it is possible (I think...)

Yeah it is getting out of hand. Like others have mentioned, I used to browse here daily (often multiple times per day) but since the spam bots took over I stopped coming altogether.