ShaunR

Hi Guys,

 

I am just wondering what the impression of developers is regarding the LabVIEW 2013 release?

 

We have been developing a large application and have found it to be very unreliable and buggy. All of our developers have several crashes per week (sometimes per day). In addition, as the project has grown we have found that opening or closing a VI in our project results in a 1-2 second delay. Strangely though if we switch from project view to file view, the delay does not occur.

 

I am in communication with NI regarding the delay, but a response of ""since this delay is not that long, I do not think there is something that can make the delay shorter" is very disappointing. Imagine working on your project and hitting this 1-2 second delay every time you open or close a VI. This delay also occurs if you add a project subVI to the VI under development. :-(

 

OK, I am just interested if our perception of LV2013 matches that of others.

 

Cheers

Well. My 2p. It's the best since 2009, but there have been some real dogs (yes 2010, I'm looking at you).

For example, in a heating or cooling situation, you almost always need some constant output in order to maintain the desired temperature, otherwise the process starts to drift towards ambient. However, in motion control, once you reach your target, you shut off the output (or reduce the power dramatically to a holding current).

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).

Even after thre semesters of controls study in my BSEE program and multiple projects with manually tuned PID systems, I still feel like it's something of a black art. I've met oldschool engineers at my clients' offices with a preternatural talent for tuning PIDs, but when I asked them what their approach was, they couldn't really describe it. Just "intuition".

What's your favorite book, tutorial, or other resource on tuning PIDs by hand? I've read all the Wikipedia articles and free online tutorials presented by college undrgrads or companies with a product to sell. I'm looking for the real deal here, the authentic guide to tuning mastery!

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.

The WebSocket connection to the browser enables a display update rate of 2x per second 

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

Can't wait to get my hands on one of these. Didn't know they had even announced price yet let alone availability.

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..

Shaun,

 

Yeah, Danny mentioned the Pi earlier.  Unfortunately, the Pi only has 8 GPIO pins.  This board needs 10.  Multiplexors or serial I/O options are possible, but this is a project for high school students in their second year of programming who will have limited help and supervision.  The environment must be simple enough to set up for them to make progress quickly.

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

I bought the OEM version... $75. Yeah, that's still a lot of Arduinos. I might pursue firmata on my own, but I'm very concerned there will be too many difficulties getting in the way of the student's success. In particular, it appears they'd have to use a USB serial port and there looks to be some issues with that. Not a big deal for an engineer--potentially a project killer for a high school CS student working independently.

(What arduino would you recommend for a simple digital I/O module?)

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.

Paul, you must be super confused. My response was supposed to be to another thread.

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

I have a customer that is writing an application with C# .Net and measurement studio. Can anyone give advice on flattening and sending structures over TCP/IP to LabVIEW, and unflattening them on the other side?

 

Is there a relatively easy way to accomplish this, or will we have to write my own flattening/unflattening methods? I know we can use shared variables with measurement studio, but I don't like the idea of this. Some of the data is config data, and there is a chance it could be overwritten before we read it. That combined with the fact that I've had painful shared variable experiences means this is not really an option.

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)

1. The dynamically loaded VIs/classes need to be a part of Bob's built applications. But Bob doesn't even know there's any dynamic loading going on -- that's all private inside Alice's collection of VIs. Is there a way for LabVIEW to magically know "oh, these VIs/classes need to be included in the EXE?" even though there is no static reference to them anywhere in either Alice or Bob's code?

Not that I'm aware.

2. Assume there is no way for LabVIEW to magically know this information. Is there something Alice could have done to her code such that Bob is made aware of the need to manually add some files to his build spec as dynamic dependencies (other than just documenting it in some file somewhere and praying that Bob notices)? The answer here may include new features of LabVIEW as needed, but please specify whether you are giving an answer that can be accomplished with LV 2013 vs LV Someday.

Sort of. See next.

 

3. The whole point of using dynamic loading is so that you don't bring all the VIs/classes into memory at launch. But there may be some VIs/classes that are *never* used in Bob's application. If the answer given in #2 is that Alice specifies all the things she could dynamically load, then they'll all get bundled into Bob's EXE. That may bloat the EXE. Is there any way for Alice to write her code such that Bob can figure out which dynamic loaded VIs/classes are actually possibly used by his application (bonus points if it's a solution that lets LabVIEW can figure it out on Bob's behalf)?

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.

 4. Assuming you came up with answers to #2 and #3, do those answers still work if the set of dynamically loaded VIs/classes is open-ended (i.e., a third party could have installed yet more plug-ins for Alice's library to use, and thus Alice cannot enumerate all the possible things that need to be loaded)?

Yes.

^^^^ This a million times.

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.

Even better than testing for an invalid refnum is actually trying to use the reference.  Recreate it if you get an error.  There is some post somewhere by AQ that points out the race condition in testing for refnum validity.

 

Here’s an example of a “refnum created and maintained inside a non-reentrant VI” from one of my projects:

Reference retry.png

Nope. It's far too slow. 

A minor warning about that technique.  A reference is destroyed if the top-level VI under which it is created goes idle.  The “First Call” primitive is reset when the subVI it is contained stops being reserved for execution.  If you are working with multiple top-level VIs (such as if using dynamically “launched” VIs) then it is possible to invalidate the reference without resetting the first call.

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.

 or things I should take into account when deciding community vs public.

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

 I wonder how much active development still goes on in 2009?

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

Awesome idea. I don't use DVRs much (or OO) so maybe that's why my mind didn't go there, but I much prefer how the DVR implementation works.

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

It expects the .dll to be in the same folder as the library (see picture). Perhaps it has something to do with that? The add-on is in the vi.lib virtual folder under Dependencies. The error case displays a pop-up which says that there isn't an OpenCL.dll on the system, which isn't happening.

Austin

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.

After adding the DLLs to the project manually and adding them as always include, the DLLs get added to the .exe under the data folder.

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

Hey ShaunR,

 

A little embarrassing, but my own

 

http://sine.ni.com/nips/cds/view/p/lang/en/nid/211893

 

Or the latest version at:

www.raptorview.net

 

Austin

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.

Hi Xavier,

I am new to mac as well.

I am facing the same problem as you faced before.

I have created a small .dylib written in C++ and i tried to use with the call library node.

After reading your post I figured .dylib cant be used and framework is the only option.

My question is how do i create a c++ framework using xcode 4.6.3? or using any xcode versions.

If i go through the normal template option for creating a framework I get .m files and I have no idea what to do with them.

Please help me on this

Guhan

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..