In any case all is going great and I have the Write and Read XNodes working fine.  So I wanted to compare their performance to the native, or polymorphic equivalents.  For performance I have my normal VI version set to inline, with debugging, and automatic error handling off, and set to reentrant. 

Calling the this VI in a loop 1,000,000 times takes about 2ms.  I then ran the same code but as an XNode and it took 265ms.

So I figured this must be because the XNode VI isn't being inlined.  So I added code to the GenerateCode.vi and have it set to make the execution settings the same as the normal VI version and ran again.  Still about 200ms.  I tried the reverse, and made my normal VI not inlined and it now takes 200ms.

I put probes in my GenerateCode.vi and see that I am setting the execution correctly, but when I right click the XNode and choose Generate Code from the wizard menu, the VI generated doesn't have the settings I set.

Has anyone seen this type of thing before?  Is there some extra work involved in setting this execution settings, or is this a bug that there is no need to inform NI about?

EDIT: In doing some tests it seems the diagram provided in the GenerateCode.vi is a "XNodeGenCodeScratchPad 1" and is likely not the VI that the XNode runs, so changing the settings of this VI does not change the execution settings of the VI that is ran when the XNode runs.

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. 

Using LabVIEW 2018 32-bit, I created an application for Windows 10, but random crashes occur with error code 0xc0000005.

My suspicions fall on the VIs used to communicate with the Yokogawa WT5000, but after reviewing the various lvlog files, I haven't been able to identify which specific VI is causing the crash.

That said, I would kindly ask for your assistance in identifying the VI responsible for the issue. Thank you.

03dc9418-0115-4f24-ba73-07f98ebf6821.zip 3eb1d949-0f35-4147-809b-7f7dff13ad06.zip 6bcc6278-fb26-48c7-a715-ab2f35a336de.zip 6f80126d-b9e2-4a12-b7f2-e8c15fb9ea48.zip

How do I get For Loop conditional terminal back? 

You can create your own plugins.

Take a look at:

http://webspace.webring.com/people/og/gtoolbox/CustomizePropertyPages.html

Template and examples are available for download.

I had read about how people have problems with buidling applications with VIMs in 2023Q3, but there seems to be all kinds of other issues going on. At first builds would fail with Bad VIs, but clearing the compile cache removed that. Now instead, LabVIEW hangs on "Initializing build", then crashes after a while. I've reinstalled/fixed the full LabVIEW installation, mass compiled everything including the entire VI lib etc...but to no avail.

I see a lot of users say they have moved back to 2023 Q1, or plan to wait for 2024 (will there even be a new release in 2024 I wonder...), but are there users out there that do get things to work fine, even with RT Linux targets and 64 bit? I'll reinstall once more and this time try the 32 bit version...but if things still do not work I think we'll skip 2023 and hope for better days in 2025(?).

I need to upgrade my Intel Mac to an M1 and was wondering if there are any gotchas. I already know that I need Windows11 ARM. But will that work ok with LabVIEW and how about the drivers? Will Windows emulation cover all the issues?

At first I thought NI was missing the help for a specific obscure VI, but as you see above, it's the entire help system.

You will be shocked, shocked, to hear that I have had some big problems with the LabVIEW IDE and especially the App Builder for years. I’m about to rewrite a framework I developed originally to facilitate building distributed data-collection and control systems in the cRIO context (which implies that the code must be written and synchronized across FPGA, RT, and PC targets simultaneously.)

I’m facing some architectural decisions and I’d like your thoughts.

I’ll describe the existing architecture, then the kind of problems I consistently contend with, then some proposed approaches for the new framework. Sorry, this is long, but I’ve condensed as much as I’m comfortable. (The post was originally like 3 times this length.) I’m more than happy to provide extra detail on anything you’d like.

Here’s the (simplified for clarity) architecture and style of the original framework.

• With few exceptions, all functionality that needs to exist on multiple platforms is written in a LV language subset that is supported on all the necessary platforms. Practically speaking, this means that for a unit of functionality or definition of static state needed on (for example) FPGA, RT, and PC platforms, I write a VI that can compile on FPGA and use it directly in the RT and PC code as well.

• This shared-code approach is used mostly for static system definition and for lower-level communication protocol definitions and implementations. The FPGA code, for instance, instantiates class objects representing physical hardware modules connected to the FPGA and/or software compute modules running on the FPGA. The VI instantiating these module objects can then be run as-is in the RT or PC context, ensuring that static initialization is identical on all platforms. The definition of and serialization code for message formats for these classes is written similarly.

• All code is written within a class hierarchy. Inheritance is used sparingly, shallowly, and exclusively (I think) for behavioral—rather than data—inheritance. Composition, on the other hand, is extensively used. My first OO exposure was in a couple of years of Java development, so I was naturally biased towards the notion that “everything is a class.” A system is a “rig” class object which contains “chassis” class objects which contain “module” class objects etc.. “rig”, “chassis”, and “module” classes are written essentially abstract, and are always instantiated as system-specific concrete children. (If interfaces had existed when I first coded this, I would of course have gone that route instead.)

• There’s another category of class that functions more as a singleton bucket of generic functionality that gets initialized once and then provides some kind of service. The generic communications infrastructure is written that way. I happily stick identical copies of this kind of object, once initialized, all over the place as a private data member within lots of other objects. That way I can have access to all the functionality and state of the singleton object, almost as if it were a parent class, without the craziness of actually implementing its functionality further up the inheritance tree.

• Classes are used across platforms, so they necessarily include code that’s compatible with only one platform. Since class libraries are loaded monolithically, this code gets loaded on all platforms, so I have to guard (or automatically “comment out”) platform-specific code using conditional structures.

• I get around the class-locking problem with a bit of source code management trickery. The code lives in SVN in a single filesystem hierarchy. It includes a separate project for each target type with the code loaded only under that target. Locally I check out a separate clone of the source for each target type and program/build apps for that target only in that clone. Therefore if I’m programming for FPGA, RT, and PC then I’ll end up with three separate local copies of the whole codeset, and I use SVN to keep them synchronized. Ah, and of course all code is set to use the compiled object cache, which I generally clear (perhaps out of superstition) when I change target context.

Here are the kinds of random showstopper problems I continue running into:

• Random VI corruption, sometimes bad enough to crash LabVIEW at project/class load.

• Apparent persistence of previous dependencies, even when no dependencies still exist in the current (visible) code.

• Unloading project doesn’t unload project contents (which isn’t a huge problem per se but indicates unaddressed latent corruption)

• App builder magically stops building, especially for RT.

• App builder successfully builds but compiled app fails to run, either on RT or PC.

• Interestingly, I’ve had the least problems with FPGA…that generally just works (meaning that when I have a compile problem, the issue is always a bug in my code that the compiler found.)

I’ve gradually gotten better at troubleshooting and fixing these problems, but until NI squashes more issues I need to adopt an approach that avoids them better.

Over the years it has seemed like these problems have been somehow caused by constantly loading classes and codesets in different target contexts (or in 64-bit vs. 32-bit LabVIEW). I’ve drawn that conclusion partly because if I stay in a single target context, things seem to be quite stable. So my working theory is that there's some fundamental problem with using classes containing cross-target code on multiple targets.

As an aside, for most of the past year I haven’t been doing any FPGA programming, yet just changing back-and-forth from PC to RT is problematic. (In fact my sense is that most of the issues come from the RT tooling in LV, the FPGA stuff has always been quite solid for me. This is only my impression!). When working with just PC and RT I am not using different SVN clones as described before, I’m only using separate projects for the different targets…so the VI paths from the IDE’s perspective remain the same.

But maybe there’s some other issue I haven’t found. I’ve played around with, for example, whether to keep typedefs within classes, and when to use strict vs. non-strict typdefs. I’m also painfully aware of the mutation history in classes, and since I’m not developing reusable libraries for distribution there’s no downside to blowing away the mutation history, so I do that fairly often. But maybe not often enough? In theory none of this should matter…yet apparently it does. I'd appreciate any guidance on anything else that might be "dangerous" given the description of my workflow.

Potential new approaches:

I’m OK with upgrading to the current LabVIEW version. Recently I ran into the “opening a single VI crashes LabVIEW” issue and was able to fix it by opening the VI in LV2022 and saving for LV2021. (I hope this is evidence of increased prioritization of stability in LV development at NI...)

The elephant-gun potential new approach would be to dispense altogether with classes and instead fake some of their functionality with typedefs and auto-populating folders. I hate this idea, but it would limit the number of VIs that get loaded on multiple targets and simplify internal namespace considerations within the LabVIEW IDE (not to mention avoiding all of the logic around class member attributes, protections, etc.)

Another approach that has significant unrelated appeal for me is to rebuild using interfaces instead of inheritance. In fact I just watched AQ’s 2022 NI Connect talk on interfaces where he explicitly suggests replacing abstract classes with interfaces. So I’d like to do that anyway, but I really don’t want to invest in that approach yet still face instability because I’m using classes in different target contexts…assuming that’s actually the root of my problems.

Thanks for listening. Any advice appreciated.

--kej

Can anyone point me in the direction of where to look for documentation of how to add buttons like this? 

This is something us LabVIEW devs have gotten used to not having but is now so common in other graphical tools.

Pan to scroll the block diagram or front panel seems like something I would actually use quite regularly.

Found in this knowledge base.

If you are not able to access this page from another PC but it works ok on the local machine you will probably need to get port 3580 opened up.

I have found that tabbing through open Windows, or opening a new VI, in general is enough to restore the functionality, but this is very puzzling.

Anyone else has experienced this type of weirdness? The only thing that I can think of that could be different from my previous configuration is that I switched to a new laptop (Windows 10 Pro), but I can hardly fathom why that would affect this installation...

In LV2020, if you right-click on VI's panel icon, there's a new menu item: "Set Icon to VI Name". It splits the name at spaces into words and creates a nice text icon. Great!

But some places have coding conventions that require no spaces in the name -- it's easier to use git with such files. And in that case, the current code sees the VI name as all one string.

I would very much appreciate it if someone with spare time wants to rewrite this VI to handle CamelCase names:
vi.lib\LabVIEW Icon API\Set Text Icon\Adjust Text to Fit Rectangle.vi

There's a small While Loop at the left side of the diagram that splits the VI name into an array words. It needs a bit of adjustment, something like, "If input string contains spaces then do the While Loop as it stands today. Otherwise, call some function that will split the string into an array of words based on CamelCase separation."

If it helps, I found this rather amazing Stack Overflow post that provides a detailed 10-part regex expression that can successfully translate this:

Quote

__ToGetYourGEDInTimeASongAboutThe26ABCsIsOfTheEssenceButAPersonalIDCardForUser_456InRoom26AContainingABC26TimesIsNotAsEasyAs123ForC3POOrR2D2Or2R2D

into this:

Quote

To Get Your GED In Time A Song About The 26 ABCs Is Of The Essence But A Personal ID Card For User 456 In Room 26A Containing ABC 26 Times Is Not As Easy As 123 For C3PO Or R2D2 Or 2R2D

I couldn't quickly get it working, so I moved on to other projects. But it would be nice...

The first one is auto-wiring when you drag code into a stucture (as discussed here).

My latest gripe is strange behaviour when dragging a VI from one BD window to another. I do this operation quite a bit to copy code. In LV2017 now when I drag a VI in from another VI as soon as it enters the new VI (but before I have released the mouse) it is as if the block diagram of the target VI only refreshes like once a second and so I see my VI jerk around. It does this the primitives as well as other VIs.

I cannot comment about LV2016, but at least in LV2015 and every other version I can remember, dragging a VI from one block diagram to another was butter smooth.

Anybody else seen this or is it just me?

Does the "save as" really work? Curious if others have success with this feature.

When I close a project I never want to defer these changes, I am used to this option being "dont save changes". See the video, it shows clearly what is happening. As can be seen from the video if I re-open the same project from the Getting Started Window it opens instantaneously which is further proof that it is not actually closed. I really hope this is not a new feature, this is really dangerous behaviour as you think the project is closed so go to commit files or whatever.

This has been reported to NI, no CAR as yet.

Anyone else seeing behaviour like this?

2020-07-25 18-46-58.mkv

Anyone else seen this?

I ve moved from LV2018 to LV2020 and it seems that position of Clean Up Wire changed from:

To:

Can this be changed somehow? I end up creating constants now and have to click multiple times 

I'm looking for a way to run "LabVIEW.exe" hidden (I'm using LabVIEW 2018) , so without the splash screen and the starting window.

I tried Method 1 and Method 2 described in this article https://winaero.com/blog/run-a-program-hidden-in-windows-10/, but nothing.

I tried also the INI parameter key "HideRootWindow=True", but only the taskbar icon is hidden.

I asked help to NI Support, but nothing.

This is my last chance:
Somebody knows a way to run "LabVIEW.exe" completely hidden in Windows OS?

Thank you,

Francesco

Do we have any association between these integer values and readable names?

Not that it's hard to extract all that from 'lvapp.rsc'; but maybe it's already done?

I right-clicked on a class wire and noticed a menu item with the same name as my class, and inside I got this automatically generated palette.

I guess someone is going to tell me it has been in LabVIEW for like 5 years or something?

Does anyone know if there is a way to hook LabVIEW Options Window (Tools menu bar) in order to add a custom configuration panel? For example when you install FPGA and Mathscript they are new menus you can access (cf. screenshot). I don't know if this can be achieved through LabVIEW project providers but I can't find any information about this subject.

Thank you in advance to anyone who can provide help or informations.

My other complaint is that I've  installed every version of LV since 2.5 in a "LabVIEW" folder -- no version number added -- and I can't figure out how to make the NI Package Manager let me do that.  So I've ended up with 3 or 4 different LabVIEWxxxx directories (depending on how far things get before the install crashes).  And if I completely uninstall all NI software, NI Package Manger still thinks it's installed and won't reinstall, but since it's not really there, there's no way to fix it. 

I'm on my third hard drive copy.

Hmm.  Sorry, I didn't mean to turn this into a b!tch session. 🙄

My question is whether or not I should uninstall just LabVIEW 2016 (leave everything else on there) before attempting to upgrade?  I'm not sure how much I have to take off to get a "clean" enough install, but not too "clean".  If that's even the problem.

And on a "funny" note, I just saw that LV2019 SP1 was released last week (I've been using 2019 f1).  I'm downloading the offline version at the moment.  My screaming fast work network is telling me I only have 3 days until the download is complete...

Cat

Cannot install the Vision Development Module 2019, the installer just closes soon after starting, no error messages or anything.

Staring Package Manager directly gives this error:

Anybody else having issues?

I've been developing a fairly large program using drjdpowell's Messenger Library (over 60 actors so far) and I am encountering slowdowns in the LabVIEW environment (LV2017 SP1) that I've not been able to figure out.

After running my source code multiple times (in order to make edits to the code), I find that the duration of time that I have to wait after stopping the code becomes increasingly long.  Sometimes it get to the point where I need to wait over a minute before I can continue using the LabVIEW environment! 

Is this normal/expected behavior?  It makes using LabVIEW very painful, and it ruins my train of thought. 

Any suggestions on how to improve things?

Thanks,

Bruce

LV NXG got itself some new features that finally make me conceder it, more so because of the LV2018 release bugs and the fact I can't work with LV2017 along with LV8.5.

It supports DAQmx, Vision, FPGA, SVN, TestStand and much more. 

Mainly, I hate feeling left behind stuck at LV2016, especially when it comes to Python support.

However, I don't see here a thread about NXG with active users so I don't know what is not yet supported and what will be the learning curve. Will I, again, be NI's guinea pig?

I understand they have a code migration tool yet I don't know how good it is for huge projects. Is it using a VI at all? Does it support scripting and OO? Could I use llb/lvlib/lvlibp/...? What are the benefits? Is the FP resizable?

Migrating upstream is one thing. What about downgrading? Even Regular LabVIEW can't handle downgrade (just try writing a vi in 2016 with a conditional indexing tunnel and save it back to 8.5 that didn't have this feature - LV8.5 will crash).

Yours truly,

Guinea pig SN: 23145211.

Anyone have ideas? What good is this ID GUID-looking value?

1. There is an "actor" that generates some data on a User Event. The main loop VI of that "actor" is the bit of code that also creates and "owns" the actual User Event, and it never stops running so should never go out of scope.
2. There is a second "actor" that registers for this User Event and receives the data. This VI gets dynamically loaded into and out of a subpanel. This is all working well and is a technique I have used successfully for a long time.
3. When I insert a different VI into the subpanel (or rather as soon as I remove the first VI and stop the loop) the Generate User Event in (1.) errors out with Error 1 and if I validate the User Event reference it transitions to Not A Reference at the same time.

What I do not understand is why a consumer of the User Event (i.e. registered for it) can cause the underlying User Event to become invalid.

Edit 1:Even weirder, if I try and Register again using this same User Event (exactly the same refnum number) there is no error (yet if I test for Not A Reference at the exact same place I am registering it gives True), see picture.

Edit 2: Today I learned that the Register Event node does not seem to do any checking on the input refnum, as can be seen in the second picture you can register a NULL reference which seems strange to me.

As I said I have used this technique many times in the past and cannot recall seeing this behaviour.

Any ideas?

Using LV2015 SP1 on Win 10

My LabVIEW 2016 32 bit is crashing a lot.

I can guess it is related to:

1. incompatibility with DAQmx 9.1.5 and the related device driver which I need for LabVIEW 8.5.1 which I also use (NI's support jumped on that issue yet I think it is not related)

2. an addon that I use to access OpenCV leaving some references open in the dlls

3. Controls with same label or with no label (I believe that this is the issue -LV can't recover correctly in such cases)

However, I don't want to guess like NI's support that it is point 1 and do nothing to prove it.

I expect to see the reason in a log file yet the support wasn't able to show me where to find it.

Searching around I found the dmp file under documents\LabVIEWdata

Is that the way to check those crashes or one of you know of a better way to check it beside elimination?

Thanks in advance

This is all a bit deja-vu for me as I struggled with a similar issue some years ago however none of those techniques seemed to do the trick now. All the forum posts seem to indicate this is quite a tricky thing to get right.

Any ideas?

I'm still stuck with 2010 at work, and we have tried to remove the compiled code from all our shared code, and that seemed to work to start with.

Then all of a sudden (I don't really know what we did to cause it to happen), all enum constants on block diagrams that was linked to a particular type def control, changed to the first value of the type def (index 0).

That was really odd, but after a bit of investigation we blamed the "Remove-Compiled Code" option and put it back, and we've never saw the problem again, until today.

I still had one shared lv-class, with removed compiled code, that got screwed up today.

I checked with my tortoise and the VI had no changes made to it, but still my enums were changed to the first value.

So I closed the VI, and removed the Object Cash (LabVIEW Data\VIObjCache\10.0) folder, and reopened it, and now it was all good again.

Am I the only one that have seen this problem?

//Mike

https://forums.ni.com/t5/LabVIEW/Parallel-Access-DVR-Bug-LV2017/m-p/3696695#M1039519

Perhapse i'm stupid , but i don't find how define default conepane for CTRL-N short cut. Previously i have one "4815" conepane each time, and now it's "4834" . I have try to modify "defaultConPane" parameter in labview.ini but without effect, and when close Labview "defaultConPane" parameter go back to "4834" .

Any suggestion?

Regards

Eric

I have recently discovered a subtle, but potentially disastrous, bug that can cause the Event Data Node to get confused as to the order of items which appear. I noticed this bug in LV2013 SP1 and have verified it still exists in LV2015 SP1.

Please can somebody try recreate this on their system. I have not bothered installing 2016 and 2017 yet so cannot verify if the bug still exists.

To recreate the bug:

1. Open the attached VI. Notice the NewVal output is used. Also notice the Source element has been hidden.
2. Add a new event, the Slide Value Change event to the existing Numeric value Change event. Notice the Source element is now present again and now OldVal is used

ES Test.vi

I'm using LabVIEW 8.5 up to 2016 on a Windows 10 64 bit.

After:

1. installing LV2017, some modules offered by the update manager

2. Windows pushed the big developer update

I suddenly found out that LV8.5 stopped working.

It appears in the Task Manager as using 32 % CPU yet there is no icon in the taskbar.

I tried clean boot, safemode and malwarebytes.

Do you have any idea before I uninstall it, clean its registry trail and reinstall?

NI's support simply states that LV8.5 is not supported under Win10.

Thanks in advance.

http://forums.ni.com/t5/LabVIEW/Load-lvlbp-from-different-locations-on-disk/td-p/3634295

I have project file that includes lvlibp library, functions from inside are called from many places inside application.

Now this library resides in directory A, I want to do disk cleaning and load the same PPL but from another place on disk. 

I have played with it and I can not do this... When I remove currently used ppl it goes to dependencies. When I add to project library from new path there is hundreds of confilcts that can not be resolved. 

Is there a simple catch that I am missing? 

demo.zip

Hooray!

This is probably old news to some people, but I share anyway for those that don't know 

For example, if you select Documentation from the Category pull down menu, next time the dialog will show up with the Documentation.

Is there an option to make LabVIEW not remember last selection?

Among all the categories, Documentation is different from all others: VI description gets focus; for all other categories, Category gets focus.

It's difficult to automate the dialog.

I have probed around and the values being persisted to disk and read back are correct, the bug seems to be in the setting of the FP.PanelBounds property.

I suspected it could something in Windows (like the restoring animation) interfering with LabVIEW as the window "appears" but I have disabled this and still no difference.

Am I doing something silly here? There seem to be lots of different properties for setting window bounds and stuff like this (see https://decibel.ni.com/content/docs/DOC-22385) so perhaps I am doing this a dumb way? I am pretty sure I used this technique on Win XP and LabVIEW 8.6 and it worked perfectly. At the moment using Win 10 and LV2015SP1.

Recover seemed to work yet I got a message saying that the vi can't be saved and it was actually corrupted:

"Cannot load diagram of "....vi""  and the only option is "cancel save".

Regular cut and paste tricks didn't work and before starting to go over the Hex code I tried something that I didn't see anyone write about and it worked so here it goes for those future corruption fighters (I can't promise it will work each time though):

The VI was written in LV 2011. I tried opening a new vi by using the still opened corrupted vi as a template.

It didn't work.

I moved up to LV 2013 and it still didn't work.

Trying the same with LV 2014 did the magic.

All that was left to do is to save to previous version (LV 2011) and correct the file's location and name.

Done. 

What genius thought this was an "improvement"?

And how do I get back a compact view of the icons rather than the screen hog version?

.Rolf knows me well.

Am I the odd one out here?

Don't suppose there is some SuperSpecialIniKeyForDefaultLocalVariableDirection?

Looks like there are some link between the content of these files and the tabs shown on the control properties panel.

What I really want is shown additional tabs for the decorations.

What gives?

Long time reader, first time poster.  I have learned a lot from lavag, and really appreciate what you all do here.  

I am building an LVOOP architecture that sort of straddles the line between AMC and AF.  One of the most frustrating things I have run across (as with most AF type architectures) is debugging shared clones.  I've run into some behavior that I did not expect and wanted to see if anyone knew what was going on.  First some definitions:

• Behavior A: Opening a Shared Clone Reentrant subVI from the block diagram of a running VI opens the original, "uncloned" VI, reserved for execution.
• Behavior B: Opening a Shared Clone Reentrant subVI from the block diagram of a running VI opens the active, running clone VI, which is capable of being debugged.

I once thought that behavior A was how LabVIEW worked, however in developing this framework, I have found that some subVIs show behavior B.  Behavior A and B seem to correlate to dynamic and static dispatch methods respectively, but I can't make sense of why.  If I create a simple example without OOP (see attached), I get behavior A.

Has anyone ever seen this behavior, and if so, am I missing something really obvious?

Secondly, does anyone have any tricks or best practices for getting into active clones to debug?  My only idea at this point is to include some sort of notifier/queue/etc to active a Front Panel Open Method.

Thanks in advance!

Drew T.

CLA, CTA

I am getting some strange behaviour when using LV to read a PNG file.

For reasons I cannot explain I get coloured pixels where I do not expect them. The attachment shows what I expect versus what LV is giving me. I have tried playing around with the transparency threshold input as a last resort but this does not seem to have too much effect.

Any ideas? Any other tricks for reading a PNG file?

Strange behaviour I am seeing in LV2015 32-bit (Win10). For some reason I cannot create a DAQmx task in a Virtual Folder in the project, only directly under My Computer.

I am pretty sure I used to be able to do this. Any ideas what is going on here?

• I'm working on a large project, and I'm running LV2012 32 and 64 bit on Windows.
• I have an typedef enum inside a class. The enum happens to be the sole member of the class private data.
• The enum is public and is used here and there all over my application
• I decide to add another value to the enum and ... BAM! ... All instances throughout my project are reset to the first value of the enum.
  

Kind of defeats the purpose of the enum, don't you think?!

What do other people do? Define all enums fully during the design phase and never change them again? Label each instance of the enum with the desired value to provide some insurance against morphing? Don't use typedefs and update them all manually?

I have seen something today I was not expecting.

If I probe a notifier wire, in the probe window I get two different messages in the Probe Display on alternate executions of the same piece of code:

I get this:

I remember some time ago a discussion somewhere (cannot remember where) about the possibility of a Variant To Data figuring out which data type to output depending on what type the output was wired into.

Even though the type input is shown as a bold input (i.e. "required"), it is possible to leave this off. I have always manually placed down the desired output type, just as a force of habit more than anything else.

It seems that as long as there are no other structures in the way the Variant To Data is able to figure out the type it is being wired into, so is there any sense in placing a type constant?

Interested to hear what others do here.

Otherwise, for the present case, I suppose that just sequencing the event generating blocks together with a Clock Tick and displaying the results may do, for the debugging I need.

TIA, Enrico

Thanks for sharing. I'm working to put together a set of best practices for using this feature and I'd like to know everyone's... well... best practices

As we know, probes inside parallel loops don't work. That's usually indicated by a slightly greyed-out version of the probe ID in the block diagram (1).

However, if I insert a disable structure inside the for loop, I can suddenly have a working probe again (in the Enabled case)!

In this picture, probe 3 is a memory I32 probe (old values are shown in the array) and I can actually step through the disabled diagram and get useful readings from the probe.

And no, this VI hasn't been flarned

Works in LabVIEW 2014 32 and 64bit.

Existing code using the Timeout event fails to compile, (Event data copy, err=1), or loads with messed up event structures (e.g. FitControlToPane instead of ValueChange). This is LV2014SP1.

Anyone has any clue about what could have happened? Keywords to search for are perhaps too generic. I have already cleared the compillation cache and rebooted the machine, next to try would be reinstall LV, but I'm wary of starting a long cycle.

TIA, Enrico

If you call:

then you get an application instance and a VI name to use in Open VI reference. But that doesn't seem to solve an issue I'm having.

In my calling VI (from where Tools > MyUtilityVI was selected) I have front panel control with User Tag information in them. I can get a reference to this VI and use Read User Tag.vi to get to the string data I've embedded in the controls. The string data is actually a LV class flattened to XML. This is where I get a bit confused - in the utility VI I can read the XML string and place an unflatten from XML string function to typecast it back to a LV class. When I debug and run the utility VI in the dev environment (Project application instance) it works fine. But when called from the menu, and in NI.LV.Dialog app instance, I get error 1527 "Attempted to read flattened data of a LabVIEW class that is not currently loaded into LabVIEW"

This is presumably because some derivative/child of the class is not in memory in the NI.LV.Dialog app instance. So how do I make sure that the entire class hierarchy is available to this application instance? Into the Unflatten XML String function I'm passing an instance of the class parent, but presumable a child or two is missing. Unfortunately the class has dozens of children, and I'm not keen on placing them all into the block diagram to ensure they're accessible to this application instance!

Here I read about accessing VIs across contexts, but I don't see a solution. This opens a reference to the VI in the original instance, but the utility VI is still in NI.LV.Dialog instance so cannot access the class hierarchy.

Here is a chap attempting to dynamically launch a VI into the application instance of the calling VI, but it fails. According to Stephen this is not possible, LabVIEW prevents it to keep everything in the NI.LV.Dialog context.

Ultimately, my LabVIEW Project will become a tool installed into user.lib, with the utility VI in the Tools menu (project folder). It needs access to the VIs that define the toolkit, which currently are in the active Project (because I'm still developing the tool), but ultimately will be found in the user.lib folder. Will it start working once I migrate all the VIs like this?

I am attempting to write a Tools Menu item to slot into the IDE. The intent of this "Tools" VI is that it determines the application instance that launched it and dynamically run a VI in that application instance so that the launched VI can access VIs in that instance. This is basically a custom Unit Testing tool that looks for particular VIs in the project that houses the application instance.

I was attempting to use the App.MenuLaunchApp property in this "Tools" VI so that I could wire up an Open VI Reference node with the right application instance and the name of the VI to run dynamic VI to run. I added an extra indicator on the launched VI to show what application context it is running in.

If I have a VI open from a Project and then launch the "Tools" VI from the Tools menu, then the dynamically run VI indicator shows "My Computer" (referring to the project housing the application instance). However - if I launch the "Tools" VI from the Tools Menu while Project Explorer is showing then the dynamic VI launches in the NI.LV.Dialog irrespectively (the indicator on the front panel of this VI shows this).

Is this expected behaviour? Is there a way around this so that the dynamic VI gets loaded into the right application instance even if launched from Project Explorer?

Thanks in advance.

Basically, trying to input a 1D double array from a "Split 1D Array" node causes a broken arrow in some situations.

Advanced TDMS Write Polymorphic with Broken Wire Behavior.vi

Typically I'd stick a breakpoint there so that the particular Actor clone's BD will pop up. But in that case, the front panel also opens, which very often leads to buggy behavior or errors when the Actor later tries to stick itself into a subpanel.

Anyone have some workaround suggestions for this? I run into the problem a lot and always slug through somehow but I figure someone's got a better procedure.

I'm developing an application that uses some PCIe hardware. My daily developing computer is a laptop docked to a dock station. Now, I would like to develop testing my subVIs in the remote desktop that has installed the PCIe hardware. I know I can enable remote debugging, compile and transfer the executable, then execute and connect from my laptop, but this is very inefficient and slow process to test subVIs.

I could install the full development environment in the remote desktop, develop in this machine with remote connection (or even directly on this computer, as it's next to my laptop), but this is not the way I would like to work with every similar project.

Do you have any better approach to debug remote desktop applications? I have heard something about using VI server and executing remote panels or similar, but I have never done such a thing.

Any comment is welcomed.

Thank you.

I know it's possible because I can edit palette sets and do this manually, pointing LV to my .mnu file on disk whether or not it is in the LV Installation Directory. But, I can't find a way to programmatically tell LabVIEW to add those same menu files. My only option so far is to copy them all to the <LV>\menu\categories\<API> then refresh the palettes.

Thoughts?

I haven't found any way to launch IE from keybord and I decided to make my QD shortcut to do this.  I've used LabVIEW Icon API and build simple code as shown on snippet. Everything work fine when I want to change Icon of a VI holding the code, (ie. replace "QD Launch VI Ref" with reference to the VI) but the situation is different when I am using it as a QD shortcut.  I have to wait about 5-10 sec once Icon Editor is launched.  It's far to long.

Does anybody can tell me how I can do this process faster or give me another way I can run IE using keyboard?

My primary disk is a nice fast SSD, but it is not huge. As such I want to move as much of this stuff off the c:\ as possible.

I have moved the Update Service stuff onto bigger (mechanical) HDD, this is possible by changing the preferences of the NI Update Service. I don't yet know if this has actually worked, as I manually moved all the files after changing the preferences.

Does anybody know if it is possible to move the NIFPGA and ProgramData\National Instruments\MDF somewhere else?

EDIT: I edited slided.3ds in Blender and the changes were visible on the Boolean slide switch controls.

1. Place an Initialize Array node in the block diagram
2. Make it a large number of dimensions (really anything more than 1 will work, but do more for full effect)
3. Do not connect anything to the Initialize Array, so it remains void
4. Right-click the output terminal, and go to Create->Indicator
5. Look at the index displays on the front panel.

When the array indicator is created, it's supposed to set aside memory to store the selected indices for however many dimensions are needed. But apparently, if the type is void, it only sets aside room for one dimension, leaving the additional index displays pointing to addresses that are supposed to be used for other things. I searched for the values that appeared using Cheat Engine, and sure enough, it cuts into a section of memory that looks like it's being used for something else.

On a side note, just for fun I changed the values on all the index displays, and one of the index displays changed to show garbage characters. Then when I closed the VI, LabVIEW crashed. So yeah, it looks like a buffer overflow.

This is in 2014 btw.

In 2013 and prior when I close the project explorer it closes and unloaded all VIs associated with that project, but 2014 does not that do that. In 2014 all the VIs stay open and I have to close them all before I can get back to the Getting Started window, but that doesn't mean that anything left memory. This becomes an issue if some top level VI is running with a hidden FP, I can close everything I see, but can never get to the Getting Started window since a VI is running forcing me to kill LabVIEW.

I'm hoping I'm missing some option somewhere that would close all Project VIs when the Project closes, otherwise I might be sticking with 2013.

I am dusting off some old code I use to get a Windows Notify Icon running. This code was originally developed in LV2009 I think, but recently used in a project in LV2012 with no issues.

For convenience I have wrapped up the .net NotifyIcon API in several LabVIEW classes. My test code works fine, but I have some strangeness with the event callback VIs (these are invoked whenever you interact with the notify icon). Specifically, when I run the code my callback seems to change context from my project to something called <W>, and is in a reserved type state as shown in the second picture. When I stop my main VI this VI does not come back out of this state. This causes my classes to be locked in the project (reason for locking is they are apparently reserved for another application instance, which I can only presume is because of the reserved callback VI).

In LV2012 when I run my main VI the callback VI does not get reserved like this, and when the main VI finishes everything goes back to normal.

Any ideas here? What is the <W> context and why is it on localhost rather than My Computer?

This works well most of the time but every so often it gets stuck on start-up of LabVIEW because the recovery dialog pops up and waits for user input.

Is there a way this can be suppressed?

I was wondering if starting the automated build version with a separate INI file would solve this problem. Any ideas?

Heiko

It's obvious to me now, but did you know that Linked Tunnels can have more than one output tunnel linked? For example: create a case structure with one input tunnel and two output tunnels. Click on the first output tunnel and link it to the input tunnel. Now, click on the second input tunnel and link it to the the input tunnel. Viola! Both output tunnels are now linked to the same input tunnel

See attached picture.

I have some old code I need to make some changes to, and am not certain what version of LV it is done in. I so not have those old versions installed on my PC, and don't really want to install the wrong version.

The .lvproj has <Project Type="Project" LVVersion="10008000"> in it, does anybody know if this is 8.6 or 8.6.1? My suspicion is that is it 8.6.1

Thanks

Neil

So this has bugged me for basically forever. Is there a simple way to apply a library style icon to a single VI or control that was not previously part of the library?

I know it can be done using the properties dialogue of the library, but that applies the icon to all the VIs in the library which is really not desirable most of the time as then many other VIs need saving.

This happens a lot when I create a new VI or control and realise it probably belongs in a different library to the one I initially created it from.

Am I being stupid here and there is a menu option somewhere I have never noticed? 

Can anybody point me to the correct sub-forum on lava to post old NI idea exchange things so they can maybe get more traction? I seem to recall there being a sub-forum called "Orphan ideas" or something like that, but my search-fu has failed me.

thanks

n 

So, I guess the Labview is monitoring the clipboard changes and always trying to parse the clipboard data to the format of a FP control or something else, which could be time-costly.I'd like to know if anyone here have experienced the same issue or if there is another possible reason or solution for the stuck?

I have a problem debugging applications executables on a remote desktop.

I have created a very simple vi to test the issue.

It contains only a while which generated random numbers every 100ms.

The vi is created in LV2013 and the development machine is running windows 7

I have generated an installer the includes the necessary runtime.

For the executable the ´enable debug´ is on.

The remote machine in running windows xp sp3.

I have checked and can confirm that the NI service locator is running.

Also I have manually added port tcp 3580.

When I first executed the .exe I got the popup to unblock the application in the firewall.

I choose the unblock option.

However after all these things I still get the error `failed to start debug server´ on the remote machine.

Does anyone  know a solution to the problem.

many thanks.

When a blank VI is opened and any simple program written, both the tools and controls palettes work correctly when using either auto tool selection or manual operation.

However, once the file is closed or LV shut down, and then the file reopened, neither of the palettes operate correctly and further file editing cannot be performed. For example, with the tools palette and manual operation,  the only tools that can be cycled thru are operate, breakpoint and probe while in auto the only tool is scroll.

I have checked out this behaviour on four different simple programs and get the same response.

The VI in all cases is unlocked.

Any help in resolving this would be greatly appreciated.

Regards,

GraemeJ

From 2013, you can't insert ctl-file any more.

For me that is a show stopper right now. So I can’t upgrade to 2013.

Can anybody at NI let us know, why this support was dropped, and what the work around would be for my exe file that currently opens CTL files and shows then in a sub panel?

I have the problem that the projects that I and a colleague developed cannot be built by our automatic build system, there are VIs missing which are part of an lvlib which we created. I managed to reproduce the problem by checking out to the same path as the automatic build does and there the lvlib does not find it's VIs either. Looking into the lvlib file with a text editor I saw paths (or URLs as they are called there) that equal our development environment. For trying I changed them in the text editor to the location where the build shall happen and, voilà, the lvlib would find it's VIs again.

So these URLs are for sure absolute paths which are used to find the VIs. But from what I've read I understood that the lvlib (at least outside of vi.lib and user.lib) stores relative paths, so either I didn't get the point or something goes wrong there or it's a LV bug.

Whatever it is but I really need to get this working so one option is to change the paths for the time being to relative paths. I tried with the format "./<subfolder>/<VI name>" but the dot is then replaced by the library name (which is, of course, not a valid directory). Does anybody know how to enter there a valid relative path?

Thanks and cheers,

flintstone

Has anyone see this type of behavior before?  Is this due to something I did or is it a bug?  Any fixes/workarounds?

i have not contacted NI yet since this could be my fault and it only happens with a certain project and only recently (I have been using LV2013 for awhile now without this issue).

thanks for your input.

-John

Looking at the %LabVIEW%\resource\dialog\PreferencesDialog\PreferencePages folder I see a pageTemplate.vit template.

I have created a new VI (prefPage_CCT.vi) and was hoping that a section would show up in the options dialog.

Unfortunatly this doesn't work.

Has anyone done this?

Ton

.

I looked in the VI Scripting nodes, but it looks like CaseSel only holds the current visible case and doesn't track previous ones.  I gave about 90 seconds of brainpower to thinking about writing some sort of tracker that runs in parallel, but I'm not at all experienced with VI Scripting and it made my brain hurt to try to track each and every case in every open VI.  If anyone knows a way to do this easily, let me know.  If not, maybe I'll petition the Labview Gods to add a previousVisibleCase property to CaseSel objects.  With something like that, I think it would be pretty simple to write an RCF plugin or a ctrl+space shortcut.

Mike

If you have a diagram like this below, and you like to add a +1 here:

The result becomes like this:

Enough is enough, I can't live without this feature but I tweaked it so it actually works.

Or at least it seem to work, please feel free to test it.

Place the attached VI in the Plugin folder:

..resourcedialogQuickDropplugins

Update the Insert.vi plugin and add this Sub VI here:

Insert_GuessInsertPoint.vi

(I've updated this sub VI)

Did it work for you?

Cheers,

Mike