Neil Pate

@Elbek Keskinoglu are you trying to get a textual representation of a data structure or the block diagram itself? LabVIEW does actually have a way to save a VI as some kind of XML file or something, but its a bit hidden away and I don't actually know how to make this work. Others in the forum probably will though. See here if you are curious.

Thanks, this is gold! I did actually brwose to that (via ftp.ni.com which now redirects) but I did not find the `support` directory.

Thank you anyway for your attempt @dadreamer, I do appreciate the effort.

OK, got it. I got in touch with NI support and they helped me very quivkly!

Hi, I am trying to help a colleague restore an old ATE and we are looking for the identical DAQmx driver that was present originally. This is DAQmx 8.0.1 Does anyone know where I can download this? Unfortunately the DAQmx drivers on ni.com only go back to version 9.0 Thanks!

Maybe you can make a channel on the Discord? https://discord.gg/fP3mmBty

I seem to recall you do need to start with one of the controls that has 6 pictures. I played around with this years ago but cannot remember how I started. Will try and remember! Did you try the System style controls? They have 6 pictures and are editable (I think). Edit 2: Sorry I don't think I read your original post properly...

Sure here you go https://discord.gg/cW4hEddg

As your application grows I would expect the need to pass additional state information between the frames of your VI. You could make a "Core Data" type cluster and put whatever you want inside that. Then you just have one wire that gets passed on the shift register.

James, I found the NI automatically generated stuff quite hard to understand. I spent time stipping it down to the VIs with the black banners (under those are just the DLL calls) and actually it really is not complicated, its just packed up in a way that is completely not usable for me.

That means you are not reading from the DAQ quick enough. You can set the DAQ to continuous acquisition, and then read a constant number of samples from the buffer (say 1/10th of your sampling rate) every iteration of your loop and this will give you a nice stable loop period. Of course this assumes your loop is not doing other stuff that will take up 100 ms worth of time.

My understanding is that the class mutation history is present in case you try and deserialise from string. It is supposed to "auto-magically" work even if a previous version of the data is present. This is a terrible feature that I wish I could permanently turn off. I have had lots of weird bugs/crashes especially when I rename class private data to the same name as some other field that was previously in it. This feature also considerably bloats the .lvclass file size on disk. For those not aware, you can remove the mutation history like this

The point is more about the difference in behaviour with connecting the cluster and not having it connected (even though the data in would appear to be the same(. I would expect most LabVIEW developers to assume the code would function identically in both circumstances, as detailed in the OP. I cannot think of any other nodes that work like that. That is confusing and inconsistent behaviour and should not be present.

Totally tangentially... I had an interesting bug once, and I eventually tracked it down to stacked property nodes. Something which is probably expected when you think about it, but not obvious at first is that if one of the actions of a property node does give an error then the following property nodes do not execute. I guess this is related to the comment posted by @sam above regarding ignoring errors. I never expected a property node could fail if the reference was valid, but there are certain conditions where it can happen. I forget what caused it though.

Rolf, what I meant was that the bevaiour as manifested is strange and unexpected, and not even something we could recreate in our own code.

I dunno, something about this feels fishy to me. I agree with @bjustice this feels like a bug (or perhaps just a badly designed API). This is not the same as polymorphism as the connector pane is not changing. We could not write any normal LabVIEW code that had this same behaviour.

That DMC deck is quite nicely done, thank you for sharing it.

Well, given that this is some kind of (bad) timing logic, and 59 is suspiciously like the number of seconds in a minute, I would suspect this is some kind of check to see if the elapsed time is > 1 minute. I strongly suspect this code is overcomplicated and there are signficantly simpler ways of doing things. These four sections of parallel code below look like they constantly evaluate if the elapsed time is greater than 45, 30, 15 and 59 seconds. The shift register on the boolean essentially latches (i.e. remembers) the previous value, and I think the XOR is used to reset the latch. I am not sure what is in the other cases of the Case Structures. Strangely the top one is active on a False, whereas the others are on True.

Ah right. Thanks for the clarification.

I don't think this is LabVIEW. We wish LabVIEW allowed you to put things like checkboxes and dropdowns in a table.

Just what I wanted, thanks for the inspiration.2022-10-13 20-30-18.mkv

Super surprised at this result. Run the VI and change the colour using the colour picker widget, while the widget is open the top loop which uses a property node works fine (Color Box 2 updates in real-time)! The bottom loop does not show this same behaviour, the value is only updated to Color Box 4 when you exit the widget. Colourbox.vi

Wait, does the underlying colour box update while the widget is open?

Yeah but I want to grab the colour while the widget is open.

Thanks. It was just a thought. How would I use Refnum to Pointer on the colour picker widget though? Is it even possible to get a reference to that little popup window?