ShaunR

I don't think it is as different as you might think. With temp controllers you reduce power approaching setpoint since you only need to put enough energy in to compensate for heat loss (synonymous with your holding current and, generally, it is a current unless they are gas heaters). You need far less energy to maintain a temperature than you need to get there (overcome thermal inertia). Similarly with motors. You need more energy to drive to position (overcome mechanical inertia) than hold it for exactly the same reasons. That's the thing about PID tuning. It doesn't matter what the system is (3 fat ladies on a see-saw). It's an empirical method to map a systems final output solely in terms of its input to arrive at an approximate model of the system - regardless of what the units may be (deg/C, deg/rad, or lemons).

It is a black art because it depends on the load and the symmetry of (in the case of temperature controllers) the heat/cool cycles (try an oven with nitrogen injection cooling!). It is always a trade-off since some systems cannot tolerate any overshoot and therefore require different parameters to those that can even though they behave the same in relation to transients. You can formally calculate PID parameters but they are, at best, a "first best guess" in real world applications and unless you are dealing with an ideal load, will need to be tweaked with things like prop-band and dead-band. This is all you need to know about calculating PID. http://www.dcnz.com/resources/tutorials/pid.pdf The rest is knowledge of the system and experience with similar systems which give you the Control Engineers equivalent of "Code Smell". It is similar in many ways to debugging which is why it is difficult to explain by the experienced engineer.

Is that a limitation of the STOMP server? I would expect far better than that with websockets.

Great More binaries to support

It's been a problem all around the internet of late (not just LAVA). Even spam killers such as Akismet are not immune. It was such a problem that I wrote a plugin for the CMS I use and released it last week to the CMS community. I get zero spam on my site, so I'm waiting to see how effective it is for those really suffering..

Just to get the last word in The Raspberry I has 17 GPIO pins.

As you are not constrained by labVIEW. Raspberry PI is a cheap option (check out the forums for lots of goodies and examples). You can program it in either Java or Python and has USB/LAN/GPIO built in.

I don't think it was Paul who was confused. Look at your post above his

Flatten to JSON. You'll be able to use clusters on your side and they can use equivalent objects on the other side (within reason)

Not that I'm aware. Sort of. See next. The classic solution is to make access to the dynamic VIs loaded by a relative path. Then you can have a directory that you just add dynamic VIs/Classes to. This is slightly different to what you are describing as they are not bundled or built with the exe. Instead, they are usually supplied and managed as a separate installation. But they will not break the exe if not present (just that feature/function will not be available) and are flexible to add/remove functionality. The issues with this approach are that the "modules" have to have diagrams attached otherwise they cannot be loaded into different versions of LabVIEW. So stripping the diagrams creates version and maintenance problems but as the password protection of some LabVIEW versions was compromised (the best solution); it is unsavoury for commercial products. Distribution of the total solution is problematic from a NI only stand-point too. It can easily be achieved via a VIPM package, but NI don't own that. So Alice would distribute a VIPM package with a dependency on the modules that would get pulled in and installed to the right place alongside the exe. Using NI builder solutions are much less elegant requiring a source distribution for the modules and an exe build for the main VI that must be modified to get to install in the right locations on another machine or labview version (because of absolute paths) and requires work from Bob to realise. Yes.

Hear, hear. The palettes are hopelessly restrictive and haven't really changed since 2.x. I would like to see dockable palettes that I can attach to the screen edges (and to each other) and be able to create palettes that I can drag and drop primitives onto as a quick favourites for that project. I've had a play with the "Smart palette" and it's good. But not exactly what I would like. Still hate the probe window so much that I'd rather create temporary indicators on FPs rather than use it (especially for strings which you cannot format). And while I'm ranting Are they ever going to fix the greying out during execution highlighting that seems to forget and get confused as to where and what it should grey out.

Nope. It's far too slow.

Agreed. You are much better of testing for an invalid refnum instead. Then it will be created on the first call and if it ever becomes invalid - recreated.

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