ShaunR

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.

Well. It wasn't particularly hard or time-consuming to code a proper solution. The caveat however is that you either needed to have done it before and already know the equation (there are lots of these kinds of things in Javascript- including this one) or you needed to very quickly realise the trig and the primitives to use (usually from experience). Just the x axis doesn't cut it for me. That's why I think it is a fantastic task. Easy and quick solution if you know it (Yeah. Yours is super creepy. A fascinating window into your psyche )

Indeed. I suspect that a separate "Job Manager" would simplify things immensely which is why we are talking about modularisation. Again. If you have a "Log" module, then it can do its thing whilst the UI gets on with just updating the UI. On the surface, the UI seems to be trying to do too much (it's an aesthetically pleasing one however - much better than I could mange) I am still maintaining that delegating much of the current UI functionality into separate modules will be beneficial in terms of maintenance, readability and robustness. I'll see what I can come up with. That'd be great. It's an interesting project and I'm keen to play so if you can get that done, so much the better (PM me log-in details if necessary). I'll take a detailed look at the code when you've set that up. What will be the end product of this software? Commercial? Open Source? Lavag? Do you have a deadline?

I agree - poor task indeed. It was supposed to be a "coding" challenge, not a "semantic interpretation" challenge. Christines was fantastic though and, to my mind, no-one got the solution.

Is it a case that it used to work on the RT platform and doesn't now. Or is it that it works in windows and now you want to use it on the RT platform?