ShaunR

I've just been bitten by this and had to convert community scoped functions to public..

I do all my development in 2009 still (although I have all the versions).

Well. To all intents and purposes, There is no difference between that and using a non-re-entrant global-just more complicated.They use the DVR technique in POOP because they don't have a method of creating singletons easily. With a LV2global, it is inherently a singleton as all VIs are singletons by default.

I would turn your aquisition on its head. Stream directly to the TDMS DB and just query it when you want to do analysis. You would then only have the data in memory that you need and no copies.

Why not just use a DVR and the "global clone" just accesses the DVR

Right. so that's a "no" then In an exe,paths are different from development as the executable filename is included. Additionally, you placed the DLL in the data directory and there is no appending of the data directory in your path code. To test, replace your path code in the image with an "Application Directory.vi", append the DLL name, and make sure the dll is in the same directory as the exe. This will ensure that when you build an exe, the dll is being picked up from the application directory regardless of how paths to VIs and libs mutate. NB: "Application Directory.vi" gives the path to the directory in which your project file resides when in the development environment.

Is that where the VI that dynamically loads the DLL expects it to be?

It looks like you are dynamically loading the dll with CL Test.vi (difficult to tell exactly because it's in evaluation therfore diagrams are locked and I cannot try a build). Therefore LabVIEW dosn't know about the DLL. You will have to add the OpenCLV_xXX.dll directly as jack states (not the lvlib, which you may have thought jack meant by library) and make sure it goes into the directory passed to CL Test.vi.

Whats the add-on? (Link?)

I had the same sort of problem the last week I made a lvlib that contained only two classes (no inheritance or anything complicated). I'm terrible at moving stuff around on disk outside of a project to get it "organised". I then close the project, re-open and let labview find or ask me where things are and let it re-link. LV is usually pretty good and without classes this has never been a problem. In this instance it just wouldn't forget an old class name that I had used previously and a couple of VIs were still linked to it-apparently. It only showed up when trying to build a package where it would show the finding dialogue and report an error of xxx.lvclass not found and the build would fail. There was no indication in the project that anything was a-miss (no broken VIs and nothing in the dependencies). Eventually, I searched all the files with a contents search to find what was linking to what (no other way of knowing) and once I found out which ones; disconnected them from library and re-added/re-saved. This fixed the problem but it took some hours to find and my bald spot now covers the rest of my head with all the scratching. . I have vague recollections of a thread on here about similar behavior being reported, then fixed, then coming back again.

You must be using LV2011 or below. I came to the conclusion (rightly or wrongly) that dylib support was an incremental development on the Mac with the dialogue one step behind. LV2010 and below cannot use dylibs at all (the library won't load). In Labview 2011, you cannot choose them from the drop down in the CLFN (must be Framework), but they do work, So if you create the call in 2012 and back-save or type the path and function name in;, it will be fine (the library will load). 2012 and later are fine and you can select them in the drop-down..

Wouldn't have kept me out

Most of these I think could be alleviated just by turning on the alignment grid and "snap to".

Too many hours on Linux Double-click will highlight the entire wire and show all kinks, even if behind a primitive Wouldn't be any worse than using classes They've already put in optimisations to increase compile times and code base by 500% for them

Try running the Static Code Analyzer. Any code is crap according to that but it is good for finding wire bends or wires backed up/bent under controls and icons.

ไม่หึง.ไม่รัก

I wouldn't. I'd just take rate of change (dy/dx) of the Vrms and if it went outside a value, count the event (assuming it's a bit noisy and not zero when unchanging).

Use the AC & DC Estimator VI to measure Vrms and just note when Vrms changes.

Came across a nasty little issue today. It seems that the Mouse Events are not backwards compatible between 2009 and subsequent versions. Following is a link to a zip file that contains two VIs. One is saved in LV2009, the other in 2011. If you open the LV2009 version in any later version you get a broken wire. The 2011 version, however is OK when opened in 2012/13. If you back-save (Save For Previous Version) from a later version to 2009, you also get a broken registration reference wire when loading back up in 2009 . http://www.labview-tools.com/download_file/119/309/ .

That's disappointing. I've nearly finished my MDI API

Well. My list doesn't just include stability. It also includes performance (both exe and IDE). There have been only 2 that have been exemplary (too long ago to remember exactly before 7.0, but started at around 2.x and have no bad impressions). Only labview before 8.x was bullet proof IMHO and even as far back as 2.x it was rare to get an Insane Object (the equivalent of a GPF in the more modern versions) which I experienced 2 or 3 times a year.. So. Outstanding editions: 7.x 2009 There have been some real dogs too 8.x (yes all of them!) 2010 That leaves high project risk but maybe worth it for the features or if specific fixes address business critical problems you have experienced (they didn't for me).. 2011 ("Performance and stability release" was a joke, and I said so at the time) 2012 So on to 2013. My experience so far is that it is excellent and, if it didn't have the JSON issue or it had a a few more new events, I would have upgraded from 2009 when SP1 comes out. The issue for me is that when installing the latest DAQ it states that it will bork 2009 DAQ functions and I'm not prepared to do that. So whilst I might have upgraded to LV2013, I am now and will be forever stuck at the current version of DAQ until I abandon 2009..

Have you tried updating from the 2013 device driver DVD? A nasty little gotcha!

You can still keep your state machines. Just contain them in modules with defined responsibilities and interfaces so that they are encapsulated..

That's why I like my title of "Archetype". Old and experienced; one of the original blueprints familiar with the arcane arts of LabVIEW

I don't use quickdrop but I've always wanted a palette that shows (say 10 of) the "most used" VIs similar to how chrome shows the most visited web pages. I've also wanted dockable palettes so that the "favourites" could be docked to the top of the screen. I think it's very limited use of the screen space to have the floating windows (urrgghhh. The probe window!). The same could be applied to "quickdrop". Just dock it to the top of the screen and have a single text entry like the chrome address bar that drops down when you type stuff into it and goes away when it loses focus.