Leaderboard

So a couple of years ago I was reading about the ZLIB documentation on compression and how it works. It was an interesting blog post going into how it works, and what compression algorithms like zip really do. This is using the LZ77 and Huffman Tables. It was very education and I thought it might be fun to try to write some of it in G. The deflate function in ZLIB is very well understood from an external code call and so the only real ever so slight place that it made sense in my head was to use it on LabVIEW RT. The wonderful OpenG Zip package has support for Linux RT in version 4.2.0b1 as posted here. For now this is the version I will be sticking with because of the RT support. Still I went on my little journey trying to make my own in pure LabVIEW to see what I could do. My first attempt failed immensely and I did not have the knowledge, to understand what was wrong, or how to debug it. As a test of AI progression I decided to dig up this old code and start asking AI about what I could do to improve my code, and to finally have it working properly. Well over the holiday break Google Gemini delivered. It was very helpful for the first 90% or so. It was great having a dialog with back and forth asking about edge cases, and how things are handled. It gave examples and knew what the next steps were. Admittedly it is a somewhat academic problem, and so maybe that's why the AI did so well. And I did still reference some of the other content online. The last 10% were a bit of a pain. The AI hallucinated several times giving wrong information, or analyzed my byte streams incorrectly. But this did help me understand it even more since I had to debug it. So attached is my first go at it in 2022 Q3. It requires some packages from VIPM.IO. Image Manipulation, for making some debug tree drawings which is actually disabled at the moment. And the new version of my Array package 3.1.3.23. So how is performance? Well I only have the deflate function, and it only is on the dynamic table, which only gets called if there is some amount of data around 1K and larger. I tested it with random stuff with lots of repetition and my 700k string took about 100ms to process while the OpenG method took about 2ms. Compression was similar but OpenG was about 5% smaller too. It was a lot of fun, I learned a lot, and will probably apply things I learned, but realistically I will stick with the OpenG for real work. If there are improvements to make, the largest time sink is in detecting the patterns. It is a 32k sliding window and I'm unsure of what techniques can be used to make it faster. ZLIB G Compression.zip

We're back again this year. Free 24 hours of virtual LabVIEW presentations. Come join us! https://www.glasummit.org/ We're also looking for presenters. I know some of you all have a lot of opinions...

Hi there ! If this subject interest you, I'm currently working on a new State Machine Toolkit for LabVIEW. You can find some shorts videos about it here : https://www.youtube.com/@EmmanuelGeveaux Or some posts about it here : https://www.linkedin.com/posts/emmanuel-geveaux-93836130a_labview-statemachines-ugcPost-746286803261... This toolkit will be Open-Source, free for students, education purpose and within LabVIEW Community Edition use. I'd be happy to ear any feedback on those videos and posts. Best regards Emmanuel

Are you seriously expecting anyone to install a random executable on their system from an unknown publisher, provided by an anonymous person on the web, where one can't even get a proper link in Google to the actual company page? Sorry, but anyone doing that should not be allowed near 5m of a computer system!

You may not care @ShaunR, but I and others do. You favour pragmatism. I understand the appeal and the benefits of a "first interaction support" AI. My concerns center on the long-term, collective social and cognitive side effects of AI dependence and replacing human interactions with AI interactions. (AI can be used well or poorly) Are you interested in exploring this topic further?

Being on-topic is easy for an LLM to achieve. Being useful is harder, and that definitely hasn't been achieved in this case. So it's just time-wasting slop. Probably. Same purpose(s) as all other spambots, just using new tools: Either they will edit their posts later to insert spam links, or they're just vandalizing for the sake of it. That would indeed be putting AI to much better use. This part has harmful side-effects. Software community forums everywhere are shrivelling up, and I bet that one big reason is because people now talk to bots more, and talk to each other less. Sure, this makes answers more readily accessible, but the costs are: The loss of motivation to learn how to ask questions well. The loss of opportunities to share our knowledge with others directly. The loss of human networking in general. These activities have intrinsic social value beyond just acquiring information.

Hi all - sharing an open-source LabVIEW client we’ve been developing at Nominal. The idea is simple: keep LabVIEW doing what it does well on the test stand, while streaming the resulting data to Nominal for analysis, visualization, and collaboration. Instead of test data living on individual machines or desktop TDMS files, engineers can stream data directly from LabVIEW into a shared workspace, where it can be time-aligned with logs, video, and other data for analysis. Nominal's LabVIEW client supports real-time streaming, TDMS upload, and NI Linux RT. Install via VIPM LabVIEW client source on GitHub We're also building Instro, an open-source Python library for instrument control and test automation. For anyone running a mixed LabVIEW/Python test environment, we'd especially love feedback on where you draw that boundary today and what instruments you'd like to see supported. Instro source on GitHub Would love feedback from the LAVA community - on either project.

This is the nine year-old link I've saved for this - Solved: Re: New VI - default window size - NI Community It behaves oddly in that if you change it and close it before saving, it won't prompt you to save. Anyone understand this?

The recovery loop forcing is most likely related to the installation of DAQmx and other NI driver software that make under the hood use of NI-PAL and friends which is really part of the NI-PXI driver software stack. This driver goes fairly deep into the Windows PCI hardware driver stack and newer Windows versions tend to enable the newest features in the PCI chipsets. Some of these features did not even exist in the standard when DAQmx and NI-PAL that come with the standard install of LabVIEW 2020 were released. So if you want to install an older version of LabVIEW on a recent hardware, it is actually best to choose a custom install and disable installation of all hardware drivers and then install the latest version of the drivers you actually need that are still compatible with your LabVIEW version. That's of course cumbersome and the long term solution is indeed to move to a newer LabVIEW version altogether. But be aware that this problem will keep occurring. The times where hardware improvements were automatically always fully backwards compatible are definitely over. The PCI standard got so complicated over the years, and covers much more than just the traditional PCI slots that are almost unseen in modern computers. Pretty much every modern bus from USB3 and higher to Thunderbolt, all kinds of memory interfaces, and many more is nowadays using PCI technologies in one way or the other. Improving that without causing potential backwards compatibility problems got an almost impossible task. And each of the software component manufacturers from hardware firmware, to BIOS and chipset firmware to Windows drivers and vendor drivers such as NI-PAL would need to test their thing with everything else to be sure it still works. Which of course is impossible, so you end up with these issues. For LabVIEW itself I managed to install and use LabVIEW 2009 on Windows 11 without any real problems. I'm convinced that even LabVIEW 7.1 would be possible, although that most likely would require some careful hand holding and sweet talking to the installer to convince it to go fully through with it. And it might show some visual artefacts when running it under Windows 11. Hardware drivers on the other hand are a different story. The NI drivers go fairly deep into the system to allow high performance data acquisition and similar things and that has a big potential to run into compatibility trouble on newer hardware than what was available at the release date of the driver.

This year I went to NI Connect (the new NI Week) for the first time in 7 years. I thought I would be the exception and see all those that have gone year after year. But it turns out that many of us this was our first year back, or some last year was their first year back since COVID. In general I think this is a good sign, that things are moving in the right direction. NI has some new leadership that has a LabVIEW focus, and at least at the moment appear to want to push adoption. Reversing the subscription only is a welcome change, but for many it hurt the inertia of business. Once a ship starts moving in the wrong direction it takes a while to come back. Or put another way, respect is lost in buckets and gained in drops. Plenty of businesses have likely moved away from LabVIEW and NI because of poor decisions, that in my opinion, were so NI would look more valuable for an Emerson sale. I'm in the Detroit area, and plan to retire doing LabVIEW. At the moment I think I can do that. Not long ago I didn't think that would be the case. We were just blindly paying the SSP each year. The subscription only model, made management here reevaluated things. We took a few years off. Then perpetual licenses came back again so we renewed. I think we will likely get a new perpetual license every 4 years or so. This will hurt NI since this means less users on the newest release finding issues. Building back trust will take time here, and this will likely play out in a similar way around the world for other companies.

It is not that LabVIEW MAY unregister the reference, but that it WILL unregister the reference as soon as the top level VI in whose hierarchy the reference was created goes idle. This is by design and the only way to prevent that is to either keep that hierarchy active until any other user of that refnum has finished or delegate creating of the refnum to the place where it is needed, for instance through a LV2 style global maintaining the reference in a shift register and when being called for the first time it will create the refnum if the shift register contains an invalid refnum. True Actor Framework design kind of mandates that all refnums are created in the context of where they are used not some other global instance that may or may not keep running for the time some Actor is using the refnum.

Hi everyone, Just want to share our open source project "Labview Python Bridge". Connect labview apps with python apps in realtime with multi-processing data queues. https://github.com/jmor2000/labview_python_bridge If anyone has any questions or suggestions for new developments / features, let me know. Cheers Jeff

Absolutely echo what Shaun says. Nobody banned them. But most who tried to use them have after some more or less short time run from them, with many hairs ripped out of their head, a few nervous tics from to much caffeine consume and swearing to never try them again. The idea is not really bad and if you are willing to suffer through it you can make pretty impressive things with them, but the execution of that idea is anything but ideal and feels in many places like a half thought out idea that was eventually abandoned when it was kind of working but before it was a really easily usable feature.

Seems like this one has "escaped everyone's grasp" too. ParallelLoop.ShowAllSchedules=True Because was only checked from the password-protected diagram of ParallelForLoopDialog.vi (LabVIEW 20xx\resource\dialog). Present since LabVIEW 2010. When activated, allows to apply more advanced iteration partitioning schedule. In other words, instead of this you will get this Сould this be useful? I can't say. Maybe in some very specific use-cases. In my quick tests I didn't manage to get increase in any productivity. It's easy to mess up with those options and make things worse, than by default. Also can be changed by this scripting counterpart.

Look at this new download on VIPM https://www.vipm.io/package/bjm_lib_request_power/

Going a bit off topic (ironically), but wading through those endless topic-shifting conversations on Discord feels like a step backwards....It is a nice tool for a public chat, but it makes things harder to find and follow 😞

Custom Menu(With Glyphs)?Ring with custom drop down list? Floating Toolbar?😁Relace everything that can't be customed

I've generally been recommending using at least 2025 because the project dependency list is no longer saved in the project file (it got recalculated at loading anyways), making GIT commits cleaner. And the in-place save for previous (introduced with 2024) is really nice to have. I have been using 2026Q1 for my development, including a major refactoring of my HAL architecture. I've had very few issues, almost all of which were fixed by clearing the object compile cache regularly (something I have a habit of doing anyways since at least 2016). And just to throw it out there, we are expecting 2026Q3 to drop any day now. No promises from NI on a date, but we are in Q3 now.

If you have a specific structure for your chambers (ie everybody is under the "Hooovahh Chamber" directory), you could do a simple lookup and use the Get LV Class Default Value to dynamically load the classes. I do something similar with my HAL already, except I dictate what class to load based on a JSON file.

You should contact the developer. It may use features not available in earlier versions and it is a source control nightmare maintaining subtly difference versions.

参考 https://www.vipm.io/publisher/opengds/ OpenGDS UML Editor by OpenGDS

In case anyone else runs into the issue...

I tried hard to ignore your poisonous whisperings but eventually succumbed to it. 🤫

@Rolf Kalbermatter my team and I still use in some systems here! In fact this very last week we have needed to add some lua stuff to an old project.

You can 'renew' your LabVIEW CE license this way if you haven't tried it: Go to https://www.ni.com Hover over your user icon in the upper right and select "My Account". Scroll down to "Products and Services" and select "View my products". Scroll down to find your LabVIEW Community Edition and select "Renew" from the drop-down menu to the right. Apologies if you've already tried this and still had issues. Maybe someone else will find it useful.

There should be a forum on the dark side for that, but anyway, here you go. LabGRAD_21.zip

For fun. 😄 "Science isn't about why; it's about why not!" - Cave Johnson

yes

With ZLib you just deflateInit, then call deflate over and over feeding in chunks and then call deflateEnd when you are finished. The size of the chunks you feed in is pretty much up to you. There is also a compress function (and the decompress) that does it all in one-shot that you could feed each frame to. If by fixed/dynamic you are referring to the Huffman table then there are certain "strategies" you can use (DEFAULT_STRATEGY, FILTERED, HUFFMAN_ONLY, RLE, FIXED). The FIXED uses a uses a predefined Huffman code table.

😅 You might be waiting a while, I'm mostly interested in compression, not decompression. That being said in the post I made, there is a VI called Process Huffman Tree and Process Data - Inflate Test under the Sandbox folder. I found it on the NI forums at some point and thought it was neat but I wasn't ready to use it yet. It isn't complete obviously but does the walking through of bits of the tree, to bytes. EDIT: Here is the post on NI's forums I found it on.

The Weather Station example that ships with LabVIEW shows a bit of this. but the data is not Base64, its just a pure characters,

The thing I loved about the original LabVIEW was that it was not namespaced or partitioned. You could run an executable and share variables without having to use things like memory maps. I used to to have a toolbox of executables (DVM, Power Supplies, oscilloscopes, logging etc. ) and each test system was just launching the appropriate executable[s] at the appropriate times. It was like OOP composition for an entire test system but with executable modules. Additionally, crashes were unheard of. In the 1990's I think I had 1 insane object in 18 months and didn't know what a GPF fault was until I started looking at other languages. We could run out of memory if we weren't careful though (remember the Bulldozer?). Progress!

I have always used this library to prevent the screensaver and windows lock from occurring. Our IT locks down the computer so the screensaver, lock screen, cannot be changed. This library bascially tells Windows it's in Presentation mode, e.g., slideshow, watching a movie, etc, such that the screen will not got to screensaver or lock screen.

@hwkim418 There are many ways you can go about this. Here's a few examples using JSONtext. (VI saved in LV 2019) object_deserialization.vi

4. WinAPI version using ChooseColor function. NativeColors.rar Far from ideal, don't kick too hard. 🙂 Determine Clicked Array Element Index is from here.

I'm excited to release ViPER ViPER is an Object Oriented design Framework that supports dependency injection and recursive object creation. Systems are assembled at runtime from a collection of pre-built components defined by an Object Definition Document. Please visit the project on GitHub https://github.com/kurtafriday/ViPER I've presented this framework at several GLA Conferences, for an overview and guidance please view. GLA 2021 https://labviewwiki.org/wiki/GLA_Summit_2021/Open_Source_ViPER GLA 2020 https://labviewwiki.org/wiki/GLA_Summit_2020/ViPER_-_A_LabVIEW_Dependency_Injection_Framework This branch of ViPER has been used by us to develop systems in regulated industries for several years, it's solid and reliable, however its windows only. I'm working on ViPER_WinRT which is compatible with Windows and RT and we have already used it for several systems. I'll be releasing ViPER_WinRT in the coming months. I'll work to get ViPER onto the VIPM Tools Network soon. I'm looking forward to the feedback and I hope you enjoy and get value from this framework. Ping me if you have any questions. kurt@medulla.net

Update: I compiled an executable with ShaunR's help. My LabVIEW VI (LV 2017) communicates fine with a simple C++ program, but my executable doesn't. I found a workaround (turn the "keep it simple" boolean off, to use the workaround). Still, I'd like to understand. The C++ sharmemtest.zip uses Microsoft Visual Studio 2015 and boost (version 1.76.0, if it matters). sharmemtest.zip shmem_testr.vi

We use the MPSSE.dll LABview driver from Benoit. We are trying the i2c read 1 byte and multi bytes. We expect ack for all bytes except the last byte with nak. During read, we understand that the I2C master drives the ack/nak. However, ack and nak happens randomly. Any body have any suggestions Thank you Dan

Another VI I thought someone reading this forum thread might find helpful. This one calls the one I posted previously as a subVI. "Make Control Glow.vi" draws a fading rectangle behind the specified control. Save it and its subVI ("Offset Glow Rect.vi") to the same subdirectory. For example, here's a glow on a system OK button. Color and border thickness are parameterized. Saved in LV2020. Make Control Glow.vi Offset Glow Rect.vi

Not from NI, that I know of. I did make a similar API that wraps the Qt framework. That involves creating external windows though; your toolkit has the benefit of being integrated with VI front panels. Original LAVA post: https://lavag.org/topic/19611-utf-8-text-svg-images-inheritable-gui-components-dynamically-composed-guis-layout-management-splitters-in-tabs-mdis-taskbar-integration-and-much-more/ NIPM installation instructions: https://jksh.github.io/LQ-Bindings/docs/ As Mikael and Rolf said, class constants are not needed: Definitely! LabVIEW's built-in support for dynamic GUIs is very poor. NXG was starting to show some promise with dynamic controls, but that's now dead. So, community-built tools are sorely needed. Are you planning to make public releases of your work? Layouts are common concept in a wide variety of GUI toolkits. Makes it so much easier to create resizable GUIs and support a variety of screen resolutions.

Here is a VI that gets the title of the window that is active. You could then continually loop until the title you expect is active, then perform operations. https://forums.ni.com/t5/LabVIEW/Get-Current-Active-Window/m-p/3930389#M1116926

This seems to work... CRC16-CCITT-FALSE.vi

You can add text labels to a dial. It does not turn it into an enum but sort of works like you would expect (change the data type to U8).

If you google "LabVIEW modbus" you'll find some solutions. Top one for me was a 2015 article on NI's website.

I think I have this fixed. Tried a compiled version of the transport library; this worked without issue. I made the timeout changes, which did not seem to have an impact on performance. I then recompiled everything (the server-side code is used in multiple applications on the system); the delay I was seeing with the one message/response went to expected amounts in tests. I've been waiting to test this with the whole system up and going; unfortunately, we've been battling drive issues that are stopping everything else. Can't definitively say it's fixed. Can't point to a smoking gun. I'm appreciating this forum and the people on it right now.

Hi all, sorry i had to do some other work. @ O_o: We already took a look into the UML editor from GOOP: The code is horrible. @drjdpowell: Thank you for your Picture and your inspiration. Up to now we try an other way. We will report if we found a solution. Thanks again Oliver

I have been working on an architecture that uses VI Server to send messages between application instances, both local and across the network. One of the problems I have run into is the fact that VI Server calls are blocked by activity in the root loop (sometimes referred to as the UI Thread). There are several things that can cause this: other VI server calls, system dialogs (calls to the one and two button dialog functions), if the user drops down a menu but does not make a selection... (I'm sure there are more...) Since this is a pretty normal way of communicating between applications, I was wondering if anyone had any ideas for a work around. Here is a basic description of my architecture: Message is created and sent to local VI that sends to outside application instance. Local sending VI opens VI server connection to remote instance. It then calls a VI in the remote instance that takes the message as input. This remote VI them places the message in the appropriate queue on the remote instance so it gets handled. If the remote instance root loop is blocked, the sending VI on the local machine is also blocked. I could try to eliminate all system dialogs from the remote application, but that only partially addresses the issue. I really wish a future version of LabVIEW would eliminate this problem with the root loop and VI Server all together. BTW: using LV2012 but this issue exists in all versions. -John

Just slap an 'Always Copy' node after the constant in the second case and it is all good (LV10). They should probably change the icon of that function to a band-aid. (Of course the number of places you need this is supposedly declining, but it is still good to know for those of us stuck with old versions).