Leaderboard

A customer asked me to create a powerpoint explaining the advantages of LabVIEW. While putting together the practical rationales, just for grins I asked Chatgpt to create a presentation explaining the philosophy of LabVIEW in a Zen sort of way. Here is what it came up with. Zen_of_LabVIEW.pdf

I spent a long time online with YouTube support and finally got to the bottom of it. The Channel is back, and all the links work!

Phew that is a pretty strong opinion! Although I personally am not a fan of the overall style of DQMH none of my problems are with the scripting/wizards or placeholder text. I think any framework that tries to do "a lot" will be complicated... your own personal framework (which you likely find trivial to use) is likely to be a bit weird to others. DQMH is extremely popular for a reason... To paraphrase the words of a wiser person than I, "please don't yuck someone elses yum"

Many years ago I made a demo for myself on how to drag and drop clones of a graph. I wanted to show a transparent picture of the new graph window as soon as the drag started, to give the user immediate feedback of what the drag does and the window to be placed exactly where it is wanted. I think I found inspiration for that on ni.com or here back then, but now I cannot find my old demo, nor the examples that inspired me back then. Now I have an application where I want to spawn trends of a tag if you drag the tag out of listbox and I had to remake the code...(see video below). At first I tried to use mouse events to position the window, but I was unable to get a smooth movement that way. I searched the web for similar solutions and found one that used the Input device API to read mouse positions to move a window without a title and that seemed to be much smoother. The first demo I made for myself is attached here (run the demo and drag from the list...). It lacks a way to cancel the drag though; Once you start the drag you have a clone no matter what. dragtrends.mp4 Has anyone else made a similar feature? Perhaps where cancelling is handled too, and/or with a more generic design / framework? Drag window out of listbox - Saved in LV2018.zip

The examples you provide are invalid JSON, which makes it difficult to understand what you are actually trying to do. In your VI, the input data is a 2D array of string but the JSON output is completely different. Your first step should be to define the types you need to produce the expected JSON output. Afterwards you can map your input data to the output data and simply convert it to JSON. The structure of the inner-most object in your JSON appears to be the following: { "Type":"ABC", "IP":"192.168.0.0", "Port":111, "Still":1, "Register":"Register", "Address":12345, "SizeLength":1, "FET":2, "Size":"big", "Conversion":"small" } In LabVIEW, this can be represented by a cluster: When you convert this cluster to JSON, you'll get the output above. Now, the next level of your structure is a bit strange but can be solved in a similar manner. I assume that "1", "2", and "3" are instances of the object above: { "1": {}, "2": {}, "3": {} } So essentially, this is a cluster containing clusters: The approach for the next level is practically the same: { "TCP": {} } And finally, there can be multiple instances of that, which, again, works the same: { "EQ1": {}, "EQ2": {} } This is the final form as far as I can tell. Now you can use either JSONtext or LabVIEW's built-in Flatten To JSON function to convert it to JSON {"EQ1":{"TCP":{"1":{"Type":"ABC","IP":"192.168.0.0","Port":111,"Still":1,"Register":"Register","Address":12345,"SizeLength":1,"FET":2,"Size":"big","Conversion":"small"},"2":{"Type":"ABC","IP":"192.168.0.0","Port":111,"Still":1,"Register":"Register","Address":12345,"SizeLength":1,"FET":2,"Size":"big","Conversion":"small"},"3":{"Type":"ABC","IP":"192.168.0.0","Port":111,"Still":1,"Register":"Register","Address":12345,"SizeLength":1,"FET":2,"Size":"big","Conversion":"small"}}},"EQ2":{"TCP":{"1":{"Type":"ABC","IP":"192.168.0.0","Port":111,"Still":1,"Register":"Register","Address":12345,"SizeLength":1,"FET":2,"Size":"big","Conversion":"small"},"2":{"Type":"ABC","IP":"192.168.0.0","Port":111,"Still":1,"Register":"Register","Address":12345,"SizeLength":1,"FET":2,"Size":"big","Conversion":"small"},"3":{"Type":"ABC","IP":"192.168.0.0","Port":111,"Still":1,"Register":"Register","Address":12345,"SizeLength":1,"FET":2,"Size":"big","Conversion":"small"}}}} The mapping of your input data should be straight forward.

In a previous life, I used to teach a CLD level class using this book, and enjoyed it a lot -- Some of it is certainly outdated at this point, but I think it still has a lot of solid info / strategies in it. I've attached the files as a .zip file to this post. Good luck! Effective LabVIEW Programming Files.zip

I have put some effort into improving the VI icons in Messenger Library, in hopes of making things clearer. I have particularly been trying to get rid of the magnifying glass icon, which was standing in for too many concepts. I have also tried to improve the Palettes by putting the standard VIs (that one would most commonly use) in the root-level palette: The 2.0 version also introduces Malleable API methods (the orange-coloured ones), which make code cleaner. If anyone could spare some time, it would help me to have feedback. Especially from people who have not used Messenger Library before, so I can get an idea if the key concepts come across. New 2.1.3 version is available here: https://forums.ni.com/t5/JDP-Science-Tools/New-icons-for-Messenger-Library/m-p/4412550#M192

Yes you can. The official form is at https://www.ni.com/en/forms/perpetual-software-licenses-labview.html Some things to keep in mind: There is a current promotion (valid till the end of December 2024) where those who used to have an SSP can renew it today as if the SSP never expired in the first place. That means you can get the latest version of LabVIEW, under a perpetual license, at a discounted price (compared to buying it "new"): https://forums.ni.com/t5/LabVIEW/LabVIEW-subscription-model-for-2022/m-p/4398958#M1296289 Quotes/sales are now handled by external distributors, rather than Emerson/NI. Lots of people have reported that they didn't get a response to their quote requests, or didn't get the expected discount applied. If that's the case, message Ahmed Eisawy, the Director of Test Software Commercialization (who wrote the forum post in my link above) and he'll get it sorted out.

You want an ability to override the Equality or Comparison operators? I'm unsure, whether it really existed in OpenG packages, but now you have those neat malleable VIs, that let you do that: Search Unsorted 1D Array , Sort 1D Array , Search Sorted 1D Array. They have an additional input to specify your own equals or less function in a form of a custom comparison class or a VI refnum. There's an article to help: Creating a Custom Sorting Function in LabVIEW

This is exactly what was said in that ancient thread: Tree control in labview. So if you add 65536*N to the Item Symbols property of the Listbox and have the "Enable Indentation" option activated, you shift the symbol/glyph and the text N levels to the right. Could be useful for simple 'parent-child' relationships, if you don't want to use a Tree. And still it's used in Find Examples / NI Example Finder window:

I once went for an interview where they gave me a coding test and asked me to modify it. It was a very long time ago so I don't remember the exact modification they wanted (nothing to do with memory leaks) but I do remember the obtain queue and read queue inside a while loop with the release queue outside. I asked if they wanted me to also fix the memory leak as well as the modifications and they were a little puzzled until I explained what you have just said. I must have seen (and fixed) this while-loop bug-pattern a thousand times since then in various code bases. I also created this VI which I generally use instead of the primitives as it intialises on first call, can be called from anywhere, and prevents most foot-shooting by rolling them all into a single VI and ensuring all references but 1 are closed after use. Queue.vi

Those aren't typo's and errors. They are tests to see if we are paying attention.

In the past I have used the IMAQ drivers for getting the image, which on its own does not require any additional runtime license. It is one of those lesser known secrets that acquiring and saving the image is free, but any of the useful tools have a development, and deployment license associated with it. I've also had mild success with leveraging VLC. Here is the library I used in the past, and here is another one I haven't used but looks promising. With these you can have a live stream of a camera as long as VLC can talk to it, and then pretty easily save snapshots. EDIT: The NI software for getting images through IMAQ for free is called "NI Vision Common Resources". This LAVA thread is where I first learned about it.

Just to share how I got around this: By deleting 1 front panel item at a time I found that one single control was causing PaneRelief to crash; an XY graph. Setting it temporarily to not scale and replacing it with a standard XY graph (the one I had had some colours set to transparent etc) was enough to avoid having PaneRelief crash LabVIEW, but it would now just present a timeout error: I found a way arund this too though: the VI in question was member of a DQMH lvlib that probably added a lot of complexity for PaneRelief. With a copy saved as a non-member it worked: I could replace the graph, edit the splitters with PaneRelief without the timeout error (even setting the size to 0), then copy back the original graph replacing the temporary one, and finally move the copy back into the lvlib and swap it with the original. Voila! What a Relief... 😉 I probably have to repeat this whole ordeal if I ever need to readjust the splitters in that VI with PaneRelief though 😮

I confirm that this license is nearly identical to the standard EULA we use for our commercial products. Some wording is not applicable to a distributed palette of VIs like this. Our intention was to share a few reusable tools, used internally, with the community. Ideally, we should have released them under a standard open-source license such as MIT or a similar option. These VIs have been released “as-is,” without support or any guarantee that they will function for your specific use case. You may need to troubleshoot or fix any issues on your own. Feel free to use them in any context. I’ll look into whether it's possible to update the packages on the tool network to replace the current license with a more standard open-source one.

I put a temporary ban on inserting external links in posts (except from a safe list). We'll see what affect it has.

This is the modern 2020's equivalent of "works for me".

Your reporting of spam is helpful. And just like you are doing one report per user is enough since I ban the user and all their posts are deleted. If spam gets too frequent I notify Michael and he tweaks dials behind the scene to try to help. This might be by looking at and temporarily banning new accounts from IP blocks, countries, or banning key words in posts. He also will upgrade the forum's platform tools occasionally and it gets better at detecting and rejecting spam.

Apparently they moved it under Visible Items Edit: This also affects other types of structures.

Well, there are two aspects. The first is the technical one from hackers diving into the software and unhiding things that NI felt were not ready for prime time, to complicated for simple users, or possibly also to powerful. The main reason definitely always is however: if we release that, we have to spend a lot more effort to make it a finished feature (a feature for internal use where you can tell your users: "sorry that was not meant to be used in the way you just tried") is maybe 10 - 20% of development time than the finished feature for public use. There is also support required. That costs money in terms of substantial extra development, end user quality documentation (a simple notepad file doesn't cut it), maintenance and fixing things if something does not match the documented behaviour. And yes I'm aware they don't always fix bugs immediately (or ever) but the premise is, that releasing a feature causes a lot of additional costs and obligations, if you want to or not. The other aspect is, if someone who is an active partner and has active contacts with various people at NI, he is infinitely more likely to be able to influence decisions at NI than the greatest hacker doing his thing in his attic and never talking with anyone from NI. In that sense it is very likely that Jim having talked with a few people at NI has done a lot more to make NI release this feature eventually, than 20 hackers throwing every single "secret" about this feature on the street. In that sense the term "forcing NI's hands" is maybe a bit inaccurate. He didn't force them, but led them to see the light! Not out of pure selfless love, but to be able to officially use that feature for himself. The according Right-Click framework was a proof of concept to see how this feature can be used and mainly an example to other users how it can be used, and indeed once it worked it had fulfilled its purpose. That it was not maintained afterwards is not specifically JKI's fault. It is open source, so anyone could have picked up the baton, if they felt it was so valuable for them. The problem with many libraries is actually, if they are not open source and free, many complain about that, if it is open source and/or free, they still expect full support for it! In that sense I have seen a nice little remark recently:

Well, you are missing some important details in "The story of how this came about". So maybe indeed "it is worth a post of its own". It was LabVIEW 7.0 where they forgot to put a password on one of the VIs shipped with LabVIEW. And that VI had some node(s) on its block diagram including, I think, the BD reference property for the VI class. The community indeed got excited. But what did NI do? They tried to hide everything again in LabVIEW 7.1! I made a joke then that "our mother" NI must had had a PMS so she put the most interesting toys on a top shelf. So I made a"ladder" for us, kids, to get to them again and called it hviewlabs was me then, because that was a name of my company I used to sell my LabHSM Toolkit, an actor framework with actors controlled by hierarchical state machines (statecharts), long before the Statechart toolkit by NI, "THE Actor Framework", DQMH, and even before LVOOP. After PJM_Labview has published his private class generator http://forums.lavag.org/index.php?showtopic=307&hl=# and class hierarchies http://forums.lavag.org/index.php?showtopic=2161# and http://forums.lavag.org/index.php?showtopic=314&hl=hierarchy# (neither topic is available anymore) it became clear how to get access to private classes, properties and methods. However, it wasn't convenient enough. My PMS Assistant made it really easy. It gave back the access to those features to a much wider community of LabVIEW enthusiasts As you can see from the PMS topic discussion, by that time brian175 already had made his DataAct Class Browser. And he got really excited about the possibility not only browse but also to actually create objects, property and method nodes with the properties and method NI didn't want the users to see. By April of the same 2006 he figured out object creation too and incorporated the capabilities of PMS Assistant into DataAct Class Browser. At that point, I guess, NI decided that "the cat is out of the bag" and there is no point to resist. Nevertheless even after VI Scripting was made released by NI some classes, and even some properties and methods of public classes remain hidden even in LabVIEW 2024. I wonder why DataAct Class Browser is no longer available (as of January 2025) as well as original findings by PJM_Labview even here, on LavaG. Did NI "politely asked" admins to remove all that and just forgot about my PMS Assistant?

Unfortunately, many of those are bots. I've disable user:pages long time ago, because of the spam. If there's anyone that deserves a lot of credit lately it's @LogMAN. He's doing amazing work cleaning up the pages and adding/editing content. There's a push recently from NI to support the Wiki and promote its use to the broader community and within NI internally as well. So, we should see more traffic and more activity than usual, which is great. This is one of the reasons for the recent stability updates. I encourage everyone here on LAVA to find whatever LabVIEW topic they are passionate about and start adding some pages or even fleshing out some existing content that needs improvement. One way to start would be to find some information that you always wish NI had easily available on their website but could never get easy access to. Then create that on the Wiki.

Hello ladies and gentlemen! Prepare yourselves for a massive wall of text. Thank you in advance. First time poster, long time lurker. Over the last decade I have found answers to a myriad of Labview related questions I've had on these forums, and I'm hoping some of you can help me out with my current conundrum. I've a solo developer for a large labview based automation project. I have worked with other labview developers in the past, but we've always kept what we were working on very compartmentalized because nobody ever wanted to deal with LVMerge. At the time they all said Labview effectively had zero way to merge VIs. Since those old days (9 years ago) we've come a long way. Unfortunately like many engineers I am horrible about UI/UX design - I'm trying to fix basic functionality, I don't care that you can't find the button (at least I don't care right then). But because of how solid the software is getting we're finally in a good position to start dedicating time and effort into improving our UI flow and design. So in the run up to this, and knowing I had basically zero experience with LVMerge/Compare except that the previous developers considered it "impossible", I did a few tests. My goal was to continue some development in the block diagram of the main top level VI in my own git branch, while another developer worked on UX changes on a second git branch. Then when he was ready we'd merge everything back together. All of his changes were focused on the Front Panel - he never opened the block diagram once. He was moving things, resizing things, changing captions and boolean texts, but never labels, and then adding various decorations as he wanted for clarity and organization. My initial test merges worked flawlessly. I was surprised how easy my small merges worked. From there he tinkered away when he could over 4ish weeks on the UI and I kept my usual pace on the main top level working on various bugs. I tried to limit what I was doing in the top level - most of the block diagram changes I made were cosmetic. It needed some TLC. Anyway fast forward and now we're ready to merge everything back together and ... I can't. I cannot get it to work. I've tried so much stuff. At first the errors were almost always during the LVCompare phase, usually about an insane block diagram object on the "base" vi. I'm familiar with heap peak so after a crash I'd comb the error log as well as I could (wish that thing had some documentation) and then try to find the offending object and fix it. More often then not I wouldn't see an issue with the object at all, and lots of the advice online is "just delete and remake the object" but I hate that solution because it means I fundamentally don't understand the actual problem, and when I'm merging three different versions of a big VI that gets tough to do. I've been experimenting with the tools, and eventually turned off auto resolve. Okay cool that would get me through the compare stage and actually open LVMerge where I could select which versions of things I wanted. From here it became a game of cat and mouse where I go through changes one by one till I get a crash, investigate, fix, change something related to said crash, and then run it again. This has been time (and sanity) consuming. It never worked, and eventually I got stuck on a merge change that I couldn't even identify what it was changing between the three, but I know that no matter which I select it crashes. I've kept trying various things since then. Resizing the tab control positions to be exactly the same Deleting a few FP objects on the base and FP update versions that I had removed when making BP changes on my version Adding a few objects I created for the same reason Added all 3 versions of the VI to the main most up to date project, opening and running them all to make sure there are no serious insane objects that are breaking them. They all run. This is by no means an exhaustive list of everything I've tried, but its what comes to mind right now as the major tries. Currently the state I'm in is that when I run it with all 3 versions with all the changes from above made to them, I can't get through the Compare stage because it crashes with a insane object error about "undo.cpp" which makes zero sense to me. What is it undoing? I tried limiting the number of Undos in LV settings, that didnt help, I tried increasing the limit greatly, that also didn't work (maybe didn't increase enough? Trying that now). I'm really deep in the weeds on this one now, and I would love some fresh perspectives. What's probably going to happen is that I'm going to write it all off as a lesson, and we'll just have the UI dev make his changes again on my current most up to date version - but I would really love to figure out the compare and merge process, and best practices for using it. The documentation for these is abysmal. There's basically nothing. I could probably pay for NI's annual subscription and maybe get some direct help from them but I had it out pretty big with some NI sales guys a few years ago when they transitioned away from perpetual licenses to the subscription model, and I don't want to pay them on principle; but I will if needed. Ultimately even if we do the changes again, I'd still like some best practices on where we went wrong and how to avoid this in the future. We're growing fast, and I could see having another full time labview developer working with me in the future and would love to come away from this with as many answers as possible on how to work in a team on labview binary files. If you've made it this far all I can say is thank you. Now please send help. PS: some info I should of added we use Labview 2021. I don't think we're on SP1, I don't remember why not, and I am willing to try updating. also willing to pay the sub and just upgrade to 2025, but not without good reason like someone tells me all about how they solved so many issues with Compare/Merge in the last 4 years and its going to be so much better I'm attaching my most recent error log from the crash I had last night. Its a doozy, reporting a TON of objects on both the FP and BP as insane. lvlog2025-08-11-15-32-09.txt

Thanks, I'll be honest, I'm allergic to Discord. Vehemently so. To the point where I refuse to use it. Just seems like a lot of unfiltered noise to this old man. I'm gonna play with NodeRed and see if it's the tool of choice. And oh, back in the day I was a National Instruments Alliance Member. Dunno if that's still a thing or not. Cheers,

Sir, TestStand is developed with C#, and my Sequence Toolkit was developed via LabVIEW from zero, and I posted it on this forum for the purpose of learning and communication. As a LabVIEW enthusiast who had ever worked at NI for several years, I don't understand why you said that.

When you send the message you encapsulate the message as a cluster of string and variant. You don't seem to unwrap the variant from the name/variant cluster in the receiver. What I expect to see is something like this in the receiver:

Drat, and now my typos and errors are put in stone for eternity (well at least until LavaG is eventually shutdown when the last person on earth turns off the light) 😁

If the child classes are statically linked in the code (via class constants, or whatever other mechanism you use), then this approach should always work, because the child classes will always be in memory.

Done some simple testing. On a directory containing 838 files it took 60 ms.

I have experienced the same thing when my VI was the member of a large class. I removed the VI from the class, set the splitter positions, and then added it back to the class. :shrug:

I'm prone to use JKI state machines for this sort of simple test sequencing. It is easy to learn, and surprisingly powerful once you become proficient with it. You can also use JKI State Machine Objects (traditional JKI SM wrapped in a class) which makes it simple to support multiple parallel state machines, and which also supports using events. Regards, Rick

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.

A bit sad to have to say this nowadays that most of the traffic on this forum is about leaked videos, money rituals and human sacrifices, but isn't this the part where someone starts to repost links to basic LabVIEW training resources on the NI site?

If you look at the actual array sizes, things will make a lot more sense. 1. The Build Array will add the number of expanded elements to the first dimension. The array size after the first Build Array is (2,0), which is still an empty array. 2. The Transpose Array will swap the array sizes. The array size after the Transpose Array is (0,2), which is still an empty array. 3. Again, the Build Array will add the number of expanded elements to the first dimension. In this case, it will add 1 to the first dimension, resulting in the array size being (1,2), which is no longer an empty array.

Probably not the feedback you are expecting but we really should do something about the nasty root loop API calls in the input API. I have somewhat progressed with this over the years and have the windows stuff all working for mouse and keyboard (and a little of the Linux) but I don't have a Mac so can't do anything on that. If there is some interest then let me know and I will see if I can allocate time to getting an API together.

C:\Program Files\National Instruments\LabVIEW 20xx\resource\PropertyPages\Pages\Format & Precision\pp_SetControlF&PString.vi Valid if no error.

Setting up the project:

Not likely. I think the Administrators always resisted such requests unless there was a real legal matter involved. But LavaG had several nervous breakdowns over the years, either because a harddisk crashed or forum software somehow got in a fit. It was always restored as well as possible, but at at least one of those incidents a lot got lost. Some of that was consequently restored from archives other people had maintained from their push notifications from this website, but quite a bit got lost then. You can still see some old posts where the whole text is underscored and links for as far as they are present point into nirvana. These are supposedly not well restored posts and by now of at best historical value, so hard to justify to try to clean up.

i can't really answer your question but I suggest you watch this presentation :

We are still looking for beta testers to join the ongoing testing phase of SOTA, our unified development environment for deep learning in LabVIEW. Now in its 36th version, SOTA is designed for developers interested in exploring deep learning using graphical programming. If you're passionate about innovation and eager to shape the future of graphical deep learning, we would love to hear from you! 🚀 𝐉𝐨𝐢𝐧 𝐭𝐡𝐞 𝐋𝐚𝐛𝐕𝐈𝐄𝐖 𝐒𝐎𝐓𝐀 𝐁𝐞𝐭𝐚 𝐓𝐞𝐬𝐭𝐞𝐫 𝐏𝐫𝐨𝐠𝐫𝐚𝐦 𝐚𝐧𝐝 𝐒𝐡𝐚𝐩𝐞 𝐭𝐡𝐞 𝐅𝐮𝐭𝐮𝐫𝐞 𝐨𝐟 𝐀𝐈 𝐃𝐞𝐯𝐞𝐥𝐨𝐩𝐦𝐞𝐧𝐭! Are you passionate about artificial intelligence? Do you want to be part of a groundbreaking journey to revolutionize AI workflows? SOTA, the unified AI development platform, is looking for beta testers to explore its latest capabilities and provide valuable feedback. 𝐖𝐡𝐲 𝐉𝐨𝐢𝐧 𝐭𝐡𝐞 𝐒𝐎𝐓𝐀 𝐁𝐞𝐭𝐚 𝐏𝐫𝐨𝐠𝐫𝐚𝐦? Be the First to Explore: Get early access to the 64th version of SOTA, featuring powerful tools like the Deep Learning Toolkit and Computer Vision Toolkit. Collaborate and Innovate: Share your insights and ideas to help us refine and improve the platform. Experience Unmatched Simplicity: Discover how SOTA’s graphical programming language, ONNX interoperability, and optimized runtime simplify complex AI workflows. ⭐ 𝐖𝐡𝐚𝐭’𝐬 𝐢𝐧 𝐢𝐭 𝐟𝐨𝐫 𝐘𝐨𝐮? 𝐄𝐱𝐜𝐥𝐮𝐬𝐢𝐯𝐞 𝐀𝐜𝐜𝐞𝐬𝐬: Be part of an exclusive group shaping the next generation of AI tools. 𝐄𝐚𝐫𝐥𝐲 𝐈𝐧𝐧𝐨𝐯𝐚𝐭𝐢𝐨𝐧𝐬: Test cutting-edge features before they’re released to the public. 𝐃𝐢𝐫𝐞𝐜𝐭 𝐈𝐦𝐩𝐚𝐜𝐭: See your feedback implemented as part of SOTA’s evolution. 💡𝐖𝐡𝐨 𝐂𝐚𝐧 𝐀𝐩𝐩𝐥𝐲? Whether you're an engineer, researcher, or AI enthusiast, your voice matters. If you're curious, innovative, and ready to explore, we want you on board! 👉Contact us if you want to join the open beta! https://lnkd.in/dWrckRJV or hello@graiphic.io or PM Stay informed and follow us on our youtube channel ! 👉 https://lnkd.in/dmP49rCa Stay informed on our website ! 👉 https://www.graiphic.io

The LabVIEW Wiki has received an update. Hopefully, it responds with fewer errors.

Can you please provide an up-to-date solution to the question?

Welcome to the LAVA! Wire your struct to a Property Node to access public properties and fields. You can set it to either read or write a value. Please be careful when changing signatures. LabVIEW does not automatically detect when the type of an argument changes. You'll have to manually update all calling sites to match the new signature which can lead to bad behavior. That said, calling by ref or by value both work. Here is a complete example for both of them: namespace DemoLib { public struct MyStruct { public string Message { get; set; } public int Number { get; set; } } public class MyClass { public string GetMessage(MyStruct data) { return data.Message; } public int GetNumber(MyStruct data) { return data.Number; } public string CreateMessageByRef(ref MyStruct data) { data.Message = "Hello from CreateMessageByRef"; return data.Message; } public int CreateNumberByRef(ref MyStruct data) { data.Number = 42; return data.Number; } } } Example.vi

I just went through the examples and everything appears to be working. Edit: Running on Windows 11, using LabVIEW 2019 (32-bit) As someone who is familiar with your SQLite library, it feels very familiar Thanks for sharing!

There is to my knowledge no way to modify the JKI Builder. Although I think they did fix in recent years a bug that sounded exactly like what I ran across. But the JKI Builder has many other limitations that I'm not fond of so I still rely on my own setup. I basically use ogrsc_builder_3.0.0.11 for the renaming of the VI hierarchy with the opglib prefix with one modifications and then a heavily modified version of the OpenG Package Builder to package everything into the OpenG package. One caveat here, the ogrsc_builder_3.0.0 is from ca. 2009 times (and in 8.6 source code version). It will likely not go well with modern lvclass' and lvlib's and even more likely with lvlibp's files. It does have support for at least lvclass and lvlib but that is most likely fairly unmature seeing when it was last touched. lvclass and lvlib still were fairly new back then and had several quirks even in LabVIEW itself. I changed deep in the belly of the OpenG Builder in OpenG\build\ogb.llb\Copy Resource Files and Relink VIs__ogb.vi, that for shared library names the file name is changed back to the previous <file name>*.* with some magic to detect the 32 or 64 in the file name if present. It's not fail safe and for that not a fix that I would propose for inclusion in a public tool, but it does the job for me. What basically goes wrong is that when LabVIEW loads the VIs, it replaces to magic place holders with the real values in the paths in the VIs in memory and when you then Read the Linker Info to massage that for renaming VIs, you receive these new fully resolved paths and when you then write back the modified linker info you cement the not-platform neutral naming into the VIs and save it to disk. The OpenG Package Builder modifications mainly have to do with a more detailed selection of package content and special settings to more easily allow multi-platform support for shared library and other binary compiled content. In terms of user experience it is the total opposite of VIPM. It would overwhelm the typical user with way to many options and details that it could be useful for most. I had hoped to integrate the hierarchy renaming into the Package Builder too, since the information in the Package Builder would be basically enough to do that, but looking at the core of the OpenG Builder in Build Applciation__ogb.vi will for sure make you get the shivers to try to reimplement that in any useful way. 😁 And yes the naming of the tools is a bit confusing. The OpenG Builder is the tool that massages an existing hierarchy into a new on with VI renaming and relocating them into a configurable tree and fixing up relative paths to be correct for the new names and locations, while the OpenG Package Builder grabs a list of files and simply pushes them into an OpenG package (basically a ZIP file with configuration file). It would be quite useful to integrate the OpenG Builder as an extra prepare step into the OpenG Package Builder but that is a taunting exercise.

@hooovahh Is still weeding out the spam. I think he's in the eastern US time zone so he's 3 hrs. ahead of me ☺️. Much thanks to him. But I'm also improving the filters. Unfortunately, I think there are some sleeper accounts that were created before the changes that are starting to post. But, yes, I think it's getting much better. BTW, I just discovered that if you ctrl+right click a posted image you can set its' size! neat.

Update To get it to work I had to downgrade to version 6.0.0.25 - OpenG File Library (from 6.0.2.28) 6.0.0.18 - OpenG Array Library (from 6.0.1.20) May be this helps someone else 🤷‍♂️ Thanks

Mwuhahahahaha! Three config tokens have escaped your grasp! I modified them specifically for folks like Flarn! They don't appear as plain text anywhere in the EXE (or in any VI for that matter). Do they guard any great secret of LabVIEW? I'm not telling! But you can have fun pouring through the code and looking for interesting bits and trying to figure out what you need to put in your config file. LabVIEW 2013 or later. Good luck.

Maybe you'll get Xmas before you know it... I found a way to retrieve all tags from a VI. I basically scan the VI file and get an index to the position of tags in the file. I then extract the tag names. Since I don't know to which objects it is related, I have to scan all objects on FP and BD to associate them properly. Once done, you get a list of refnums and variants for the Object's references and a list of tags to which it is associated. I also included an example of code to write a tag to the Block Diagram. Use the same template to write to FP or any objects. Open the project and launch "Get All Tags from VI". Browse the path to the example file "Tagged Test VI" and that's it. Saved in 8.6 but will work in 9.0 (2009) as well. Note that the versioning is important as tags are seen only through scripting and NI can change the way it is saved from one version to the other. Retrieve Tags 8.6.zip