All Activity

Reds, NGL, I don't understand what you're saying, but I'm gunna take a stab at it. It sounds like you have massive SSD with the various partitions for the specific versions of LabVIEW on it. From the VERY brief googling I've done, it sounds like BCDBoot sets up a boot a virtual hard drive (VHD). The VHD can be booted from windows (I am not sure what side-by side means with respect to booting the VHD, but I am assuming it means I can run the "real OS" and the "LV OS" versions of windows at the same time). I think BCDEdit allows me to modify the boot of the VHD or it is the command line execution that creates the VHD's and BCDBoot is the one that boots the VHD. So, assuming I am on the rightish track, would the VHD only contain information related to LV specifically, such as LV/MAX/other NI software/git with its specific diff/merge for the LV version? If so, then what would the "real OS" be in charge of with respect to LabVIEW? I guess what I'm not fully putting together is, why virtual hard drives? From my very basic (mis)understanding of things, the VHD can be mounted/unmounted at will to swap between the versions of LV, so why couldn't you do that with multiple partitions on a SSD? It sounds like that was Tim_S's solution, with the various flash drives being the VHDs in this scenario. Googling the difference, I see that VHDs are meant for virtual machines, so I am assuming that when you BCDBoot the VHD, you're booting a virtual machine's image to work in tandem with windows which contains the LV version and what not. Matt

I have a system I've been using for years that works pretty well. Windows has a very capable boot manager. Once setup, it will prompt you to select which Operating System you want to boot into at system startup. You can have a different copy of Windows installed on basically every partition on your GPT formatted hard disk. If you start googling around for the "bcedit" and "bcdboot" Windows commands, you'll quickly find yourself deep into this rabbit hole. Sadly, I have the options for those command line tools memorized because I do this so frequently, and for so many years If you really want to get sophisticated, you can also use the Windows boot manager to boot *directly* into a VHD - without any host operating system running. This allows your VHD *direct* access to all the NI hardware without any translation layers in between. This is known as "Native VHD Boot" in the Microsoft documentation. If you're booting directly from VHD's - these VHD's are portable to new machines. You're just going to have get very familiar with the bcdedit, bcdboot, and diskpart command line tools. It's all doable, and it all works, but these tools will start to make your feel like you've living in Linux world, and not Microsoft world . It just takes time to learn and get familiar with the tools. I've been taking this approach for many years - I can't even imagine living without these capabilities. I don't know why anyone would mess around with docker or any of that stuff. The capabilities built directly into Windows meet 100% of my needs. The only special thing you need is a generously sized SSD, formatted with many different partitions (one partition per Windows copy).

I have a LabVIEW application that produces a continuous stream of binary measurement data. Right now, this measurement data streams into a LabVIEW notifier, and multiple "listeners" can "subscribe" to that data and monitor what is happening. Both the producer (publisher) and consumers (subscribers) are all native to LabVIEW right now, so it all works great with LabVIEW notifiers. But, now I want to have a non-LabVIEW listener. What to do? The semi-obvious choice would be to switch the code so that the data would be streamed on TCP/IP instead. But what higher-layer protocol would you want to use for that? It seems to make like the RESTFul and gRPC models are more client-server oriented. I want something this a very loosely couple producer-consumer model, where you have one producer and any number of listeners. What are some good candidates?

ShaunR, Based on what you are saying, it looks like I'd need to go down the VM route. However, I'd like to verify I'm using the right jargon after rereading my initial message and reading your response. When I am saying portable, I mean that I would like to be able to transfer what toolkits and what not relatively easy between PC's. So if my PC crashes or I have to change PCs in a few years, I don't have to recreate my wheel and be super meticulous about everything. When I say isolated, I am thinking since I do dev work in 2 different versions, then those versions shouldn't be interfering with each other for common drivers, such as DAQmx. So to me, that means that they should never be able to see each other, thus isolated. If both of these are accurate to the jargon, then I do need to go down the VM route. However, I am unsure if what I think portable means is what it actually means 😅. Thanks, Matt

Hey Person of Fancy If you want device drivers, DAQ, vision toolkit or 3rd party driver support then VM is the way to go. All versions of LabVIEW work fine (with caveats) in Virtual Box and VMware - just read up on NI's licencing requirements for VM's. This will be GB's of data each save and VM's run like slugs compared to your dev machine. Also the computer hardware will not be representative of the final target you will deploy to. So beware- here be dragons! When it comes to LabVIEW, I also have USB sticks with customer specific versions so that I can go on-site and seamlessly integrate into their teams. These are only applicable if device drivers et. al. are not a concern (e.g. UX, TCP, GPIB, Web Applications and stuff like that). Some want me to keep the USB while others want to keep the USB stick with IT - in the latter case, source control is their problem and for the former I just check in the entire USB stick. if you don't use a VM and have multiple LV versions, there are 2 issues you need to be aware of You can only have one NI-DAQ version across all LabVIEW versions (this is the main reason why you need VMs but there are others). If multiple versions are needed in different LabvIEW versions then VM's is the only way. Recompiling in a later version is a huge risk because back-saving is, anecdotally, about 90% reliable and can easily fail in convoluted cases. The best defence is to adopt a workflow that mitigates the chance and rely on source control when that fails or vice versa. Projects are relative paths so as long as you include all code under your project directory (and don't scatter it around different drives and non-hierarchical directories) you should avoid this most of the time. For those times you don't, revert from source control or back-save. Keep your project code separate from vi.lib!

I've only started looking into Docker, so I can't comment there. I've some old versions of LabVIEW that I have on a VM and that works without an issue. My IT department gripes at me about VMs as each one is a license of the operating system.

You might check out this; https://github.com/solitontech/SLL-Drona I have only played with the Demos, but they are pretty impressive.

I don't understand why you're being aggressive, but I suggest we take a closer look at the library first. I'm interested in taking a closer look at the library and hope that the code is open and customizable. At least with TestStand, quite a lot of the code is customizable! ;-)

Tab is moving only one cluster. Why is the tab not moving down the clusters in the array? This is my homework. I have submitted it for grading. But, I want to know why the tab is not moving down in the array! Thanks. Tab.vi

The Sequence Toolkit looks like a nice alternative to TestStand that I personally would like to see more of. I doubt there is any copyright infringement here.

Hey Fancy Folk, I am looking for solutions to creating a portable and isolated LV Dev environment (2018 32 bit and 2024 64 bit along with various toolkits). From what I understand, I believe I need to go down the VM route for my needs, but I wanted to see what other people think because I don't know what I don't know. Background: I do dev work in LV 2018 and 2024 and want to isolate them from each other. I am also using git for version control and I don't want to have to continually tell git what version of diff/merge tool to use on a per repo basis - less clicks in my life the better. So, I am trying to make my future life easier since I currently know how things are set up and can recreate that wheel when things are settled vs when things go bad. Right now, I have LV 2018 and 2024 both installed on my PC and it works good enough, but I am sure I'll eventually get bitten by having both on my PC. My initial thought was to look into either a VM or Docker and create an image for both versions of LabVIEW. Googling around, it looks like NI said that Docker was a no go because NI Drivers need kernel mode drivers and user mode libraries (Are NI Drivers Supported on Docker Containers? - NI), which makes me think that VMs are the solution to my problem. However, NI also says that NI software should generally be good on VMs, but it is not officially supported (Are NI Products Supported on Virtual Machines (VMs)? - NI). I am not claiming to be a SW engineer and I am unsure what tools exist, so I wanted to see what you guys think and if you have any advice for how to proceed.

Thanks sorted out.

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.

So, you have basically just implemented what looks like a copy of the TestStand Sequence Editor. Looks like NI would have good chance of winning a copyright lawsuit against you, and frankly I hope they do.

Homework done help reqd_sr_1.vi

Homework done help reqd_sr_1.vi

LVCompare CRASHES In my attempt to comapare a VI that is quite bigger than the avarage VI (about 550 KBytes), LabVIEW always crashes after some loading time. Comparing other (smaller) VIs than this one works perfectly. Output I get: LabVIEW caught fatal signal 25.1f0 - Received SIGSEGV Reason: address not mapped to object Attempt to reference address: 0x41 Segmentation fault (core dumped) (Yes I am using LabVIEW on Linux, which is quite special on its own) As you may see I am using LabVIEW 25Q1 Pro and this issue with the crashing LVCompare still remains. I already wrote a ticket to NI and gave them some information, and now they are investigating this issue.

This topic is repetitive. Please go here “Sequence Toolkit“ ”

Support "Tag Engine" to interact with your program a variable transfer bridge. Support "Lv_muparser", variables can be operated through expression. Support for drag-and-drop editing of your sequence like in TestStand. The logical steps in the Flow Control "support infinite levels of nesting. In addition to the preset steps in the "Step Pane" ", you can also develop your own test steps according to the project requirements. They will be automatically placed in the" Addon "catalogue. Support user define "Flag" like Skip and Pause(Breakpoint). Unlike TestStand, all of the features in the toolkit can be integrated into your source code, and the toolkit is based on the DQMH architecture. Later, you will be able to call DQMH API in your program to start Sequence Editor or execute sequence (you need to wait for the subsequent package to be uploaded to VIPM).

Support "Tag Engine" to interact with your program a variable transfer bridge. Support "Lv_muparser", variables can be operated through expression. Support for drag-and-drop editing of your sequence like in TestStand. The logical steps in the Flow Control "support infinite levels of nesting. In addition to the preset steps in the "Step Pane" ", you can also develop your own test steps according to the project requirements. They will be automatically placed in the" Addon "catalogue. Support user define "Flag" like Skip and Pause(Breakpoint). Unlike TestStand, all of the features in the toolkit can be integrated into your source code, and the toolkit is based on the DQMH architecture. Later, you will be able to call DQMH API in your program to start Sequence Editor or execute sequence (you need to wait for the subsequent package to be uploaded to VIPM).

Hi I need help with listbox in labView version 2025. I have 5 columns in the listbox. the last column has numeric values. when I select a row (record), I can display the whole record by clicking a button. I want to reduce the value in the last column. On repeatedly selecting and clicking I want the value not to decrease below zero. when the value reaches zero I can not decrease anymore. Give a message, "Out of stock" help reqd.zip

Welcome to the active side of LAVA! You may be happy to learn that perpetual licenses are back: https://www.ni.com/en/shop/labview/select-edition.html Binary files are always problematic when merging. Even LVMerge does not get it right all the time, especially when the differences are too large, which gives you the first clues: Whenever possible, avoid merges - no merge means no merge conflicts Establish a process to avoid merges - perhaps finish implementing the functional part first, then hand it off to the UX designer. Establish an environment of clear communication among developers - telling a colleague to wait 5 minutes for your work to finish so that they can base their work on yours is a very effective way to avoid conflicts in the first place. Merge changes in small, iterative cycles - this reduces the chances of merge conflicts and insane objects If more than one developer needs to touch the same code at the same time, review your architecture. Split large VIs into smaller SubVIs, build reusable components, separate concerns, etc... In my team we seldomly need to merge (perhaps once or twice in the past 10 years). We split the project into functional groups with clear boundaries. The lead developer is responsible for ensuring that the boundaries are maintained. When a team member needs to make changes that affect others, we first merge everyone's branches, then do the change, then continue with normal work. At least for us this has proven very effective. I can't say much about LV2021 because I'm still working with LV2019 but in general the SP1 version is more stable and reliable. Maybe take a look at the bug fixes and known issues to help you make a decision: https://www.ni.com/en/support/documentation/release-notes/product.labview.html?version=2021-sp1 For your merge issues, however, it will most likely make no difference. Since LV2024Q1, however, NI has made considerable changes under the hood, including new tooling for diff and merge: Improvements to Comparing VIs Changes to Compare VIs and Other LabVIEW Files Generate VI Comparison Reports with the LabVIEW Command Line Interface Perhaps more useful is the new feature that allows you to open a project without changing the save version, which means you can edit and save VIs in earlier versions (as far back as 2017) without having to go through any extra steps. This also means you could try to merge using LV2025Q3 and keep the merged files saved for LV2021. The chances are slim that the errors can be resolved in newer versions but it might be worth a try. And you don't need a license for that. You can evaluate LabVIEW for a couple of days (I believe up to 30 days). *cough* Community Edition *cough* - pardon me

Yes it is fixed. Thanks a lot!

I think this is fixed now. Please check.

Hello 4 years later. Is Sam Sharp's presentation using Test Complete still the preferred solution? I tried out the Ranorex demo today and pretty quickly rain into the issue that it seems to be just recording clicks on pixels rather than any concept of buttons and numerical entities.