Leaderboard

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!

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

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.

In the LabVIEW community a phrase that has been used to describe undocumented, or incomplete features of LabVIEW has at times been called Rusty Nails. In searching LAVA it appear this is never explained and so this post is intended to give a brief history with as many details as I know having not been active when this all took place. The earliest reference to "Rusty Nails" found online (thanks to AQ) is by Greg McKaskle of NI in 1999. Someone was asking about all the undocumented INI settings that could be found, and how some weren't exposed to the Tools >> Options dialog. Greg's reply was this: Back in the LabVIEW 5.x and 6.x era there was a new emerging technology that was LabVIEW Scripting. NI had created scripting for their own purposes but the community saw it and wanted to be able to automate editing, or creating LabVIEW code. With the help from Jim Kring and others, the basic tools for enabling scripting in LabVIEW were available. The story of how this came about is worth a post of its own, but the summary is that NI shipped a VI that didn't have a password on the block diagram, which allowed for the creation of any object, given an ID. Using a for loop, you could easily create every object in LabVIEW, including objects which facilitate in creating and manipulating code. Discussing scripting often leads into discussing other INI keys which enable private functions like the well known SuperSecretPrivateSpecialStuff. It is possible this is one of the keys Greg was referring to. Other INI keys from 5.x can be found here. After these discoveries the NI forums started getting users asking about scripting, and private functions. Users were looking for help, and documentation but NI wasn't ready for this knowledge to be public and so they started deleting all posts related to private, and scripting functionality. Some of the motivation for the creation of LAVAG came about by a desire to have an independent place to discuss the LabVIEW topics that NI didn't want to have on the public forums, potentially adding to the number of support calls, and confusing new users with advanced topics that were undocumented or incomplete. After LAVA's creation a subforum section was labeled Rusty Nails, and intended to be a place to discuss Scripting, ExternalNodes, XNodes, Private methods, and general LabVIEW hackery. Over the years several private functions have been made public, and scripting has become an official feature shipping with LabVIEW. Because of this the Rusty Nails and XNodes subforums were combined into what is now the VI Scripting section. Even over on the official NI forums, discussions about private functionality and XNodes has been relaxed since those early days. Asking for private methods and getting unofficial help is something users, and sometimes NI employees will participate in, without the heavy censorship seen earlier. And topics of scripting are encouraged now that the feature has been official since LabVIEW 8.6. If you have anything you'd like me to add regarding scripting's history feel free to reply and I can add it. And if I got any of the details wrong let me know. Again I wasn't around when this all took place and I've just tried putting down the details I've heard from other developers.

This is by no means a full EtherCAT tutorial but, rather, introductory notes. Please, feel free to add to this post, expend and/or correct any mistakes and information.

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

Yes this has been done before. I believe BlueVariantView is what you are looking for. It creates a recursive tree of any data type: JSONtext on the other hand illustrates how to turn your data back into a data type.

I will change the terminal name to "Format empty input as null" to prevent reading it as referring to JSON Strings in the input rather than the entire LabVIEW string. And I'l try and give a better description:

I fixed the issue. It was actually kind of funny. So there's a security rule on the server to protect against SQL injection. It found a match with "User_group". I guess it thought someone was trying to get the user data from the database? 😁 I added an exception. All good now.

The idea about NXG in terms of how "bad" the old code base was, always struck me a bit like "throwing out the baby with the bathwater". And while I wasn't involved in any of the user sessions about NXG myself, from the things I heard, I got the impression that they were mainly trying to look for an echo chamber instead of real constructive critique. (Probably one reason I did not get contacted as I never held back about not being a cheerleader). 😁

I was at a similar meeting with NI in 2014 (in Geneva, CERN). Their concern about old LabVIEW codebase was legit, but it seems they didn't even want to hear our concerns. I had about the same experience as you when they laughed it off. My concerns were "why to change the block diagram GUI? don't do it", "VIs should be compatible, don't make two parallel incompatible versions of LabVIEW", "why you're using WPF for front panels? Ditch it completely and get html5 compatible vector graphics engine like V8 for Chromium, use open source heavy lifting for the 'view' layer. You already had funny experience with Silverlight, why you wanna do the same sort of folly again?". On my last concern they replied that it's a strategic partnership with Microsoft that matters, and everything will be ok...

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.

When do we get vector graphics in LV?

I am glad that didn't ve time to install NXG 😀

Hopefully this alleviates any concerns about LabVIEW becoming unsupported in the future in favor of NXG.

These are two separate issues: drag over not working, and drop deleting tree items. You can use the attached VI to copy a tree and event structure out of. What's important is that you have the old event ("Drop?", not "Drop"). You can replace the tree with a system tree as long as you right click on the tree and select Replace. Don't delete the tree. TreeWithDropEvent.vi