ShaunR

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

I tried suggesting something like this some years back to "keep out the riff-raff"

Wouldn't have kept me out

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

I can understand that sentiment

But my rule comes from the fact that if I move a VI (by nudging it one pixel up and to the side with the cursor) to see if the wires are correctly attached to the right terminal, and yes that has been and is always one of my first methods when debugging code that appears to behave strangely, I want to see the wires move with it so I know approximately that they indeed are attached to the terminal they appear to. With hidden bends you don't have that at all and need to move the node sometimes many steps to see if they really attach correctly. And shift-cursor is not a good way to do it.

Too many hours on Linux Double-click will highlight the entire wire and show all kinks, even if behind a primitive

 

And to Shaun and others, be happy I'm not in the LabVIEW development team. I would penalize any VI call that is not using the 4*x*x*2 connector pane by an extra 1 ms delay, and document it as a special optimization in the compiler of the 4*x*x*4 connector pane pattern.

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.

Just don't tell my boyfriend about her.

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

If you went this route you could replace the hilbert function with this implementation in what I sent you and still capture the transitions in a similar fashion.  Lots of options.

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