jgcode

Great list.

...But I think our customers are probably a bit different. They don't want to "play". they just want it to work!. And work 7 days a week, 24hrs a day...

...Our system is quite sophisticated now thoug

Well, I am pretty sure all Customers want their software to work. But I agree, we are mostly likely talking a different project scope as I definitely don't have access to such a system/IP as you described. So if it makes sense for the project I do go with MAX.

We usually create the channel associations at run-time in a similar manner to this:

I have tried both approaches, I particular like integrating with MAX in certain situations:

Here is a brief list of my FORs:

• MAX is usually installed (or its not a hassle to) just install the Full Driver (which the client gets on disk with the hardware anyways).
• MAX already has an interface, no need to create one (save budget)
• And having a GUI is normally easier for a customer to navigate than a config file API (depending on the Client of course).
• MAX includes the ability to handle Scales of different types (linear, non-linear etc...) - again, I don't have to account for this my code.
• Communicating with MAX is really easy using the Task-based API (through PNs etc...)
• (So far) Clients seem to like using MAX
• Especially if they have used it before, then you can maintain a consistent interface for hardware configuration.
• Its easy to back up your configuration and port it over to another PC etc..

• It separates your (custom) application
• Your application has a dependency on MAX

Then in-line with the ant-globalisation (lol) posse then neither should be used since they are both global variables and this is a sin

I used to be that posse, but it was due to narrow-mindedness.

I now think they have a valid use case as per my posts above and link to D's article.

And I agree (on a real-time NI system) I am "probably" going to use the SPSV.

I use SVs more in RT apps etc...

Yes, as I mentioned above, I was referring to RT. The OP wasn't focussed on a particular target.

But I am not going to use either in normal LV unless I want easy network comms (well. not even then ....).

Well, thats ok, your allowed to

NI's PSP protocol seems pretty nice, and it sure is a fast way to share data/messages between a Target and a Host application.

I haven't tried the Network 'this is the way SV were meant to be used" Streaming feature of LV2010, but that looks very cool.

Also for tying into a Database or Alarms, is pretty straight forward, so I have found you could save a lot of work using them.

<edit>

So one would think, but actually one can use a network-published shared variable even in a time critical loop on RT--as long as one configures it to be RT-FIFO-enabled. Then LabVIEW is smart enough to wait to do the networking part of the operation outside the time-critical loop. (Of course, there will be jitter in when the remote recipient gets the data because of the networking, but if this is OK for your application--as it is for ours--then this works fine. One of the folks at NI recommended I do it this way a couple years back, and it works.)

</edit>

Thanks Jon... <dreamy eyed adulation> you're my hero.

I had hoped to separate the data collecting code from the data saving code, but this appears to be the easiest way to accomplish the main goal.

lol

I thought you might mention that

But in this case its seems best as you mentioned.

Couple other questions:

How do people manage tasks/channels/scales between the project and the executable on the target computer? My idea was to provide a known good measurement and let the engineers develop and use new tasks, channels, and scales in NI Max as needed. When testing it out on the target computer Max gave me a licensing notice that, since the target computer doesn't have a Labview license, you can use max to modify those things but not create them.

Ok - you are ready for this...

You can create Tasks , Scales etc... in your LabVIEW Project! [... the crowd goes wild...]

I love this, now I can associated hardware configuration with the Project, meaning its easy for anyone (or me in the future) to quick get access to the configuration and is the first thing I do for development.

When it comes time to test/build etc... I use the Import/Export features integrated into the Project.

The only downside with this is that is I want to include DAQmx configuration for an installer it has to be as an .nce file.

The Project exports as an .ini only.

So it means importing the .ini to MAX then exporting it back out as .nce so I can point the installer to it.

Don't know if this has changed in LV2010, or if there is an easier way.

[License] I have seen this license but never been affected by it. What was the result of actually trying to create a Scale?

I mean if the customer buys NI-DAQ hardware which ships with the DAQ-mx drivers then they are going to need to create Scales etc... so this should not be an issue.

I normally get the prompts but I just acknowledge them and it all (seems to) works.

I think you are all missing the point... ...SV's have a network feature and that is the only reason people (should?) use them

That is not true, due to the error wiring to sequence dataflow they can be a much better choice.

Also, you are never going to use a NPSV in a time critical loop (or any serious loop), you are going to use a SPSV.

Active Content? Is that the same as Unread Content?

Active Content

The first time I used SV's that fact kicked my butt in a major way. For this reason alone I think SV's are poorly implemented in LV and could use a "service pack".

I don't think they are poorly implemented just because you have to initialize them.

I don't want to be reading uninitialized data for one (there are warning for this tho on the error wire), and (I am not 100% sure but) there maybe resource optimization reasons for this too (for NPSV).

The release of the SV API in 2009 was really cool, as I find it seems to be a bit more polished than Datasocket API (in terms of error handling etc...).

One thing that drove me crazy was that the SVE was not linked to the TypeDef (engine?).

However, in 2010, this has been added/fixed which is a great step forward.

Now if they started to include some of the DSC functionality in LabVIEW Pro...

Question:

How do I go about showing the post-scaled data to the user while saving unscaled data and scale information to disk?

I haven't look at it in detail yet, only had a quick play when it came out as I had to demo it, but in LabVIEW 2009 (or rather DAQmx 9.0) the new TDMS API (2.0) is integrated with DAQmx.

The increased speed is attributed to not having to go through the TDMS, LabVIEW or OS buffers, essentially data goes from hardware to HDD.

See here, as it mentions logging raw data to reduce file size footprint.

Reading out the data should still come out scaled.

Worth checking out methinks?

Cheers

-JG

I like using Globals as constants/WNRM or WORMs (posted here by Darren), and have been doing so more and more since that article, especially for tools in LabVIEW.

I don't see the point of writing a FGV and the code that sits on top of it when I can use a global, with less work, if the Use Case suits it.

I also like AQs ideas on Scoping a Global.

As for Single Process SVs (SPSV) vs Globals:

SPSV have error in/out to control dataflow

SPSV have an optional timestamp if you need to check the last write time

SPSV can be easily updated to a Network Published SV (NPSV)

I use SVs more in RT apps etc...

A few other things... you need to initialise the SV variable before you use it.

You can also buffer these variable in different ways.

And the configuration is Project based.

I am not sure where SPSVs store their data now.

If i remember correctly in 8.5, it used to create a VI for each variable (that was annoying).

For globals the data is stored in the FP of a VI and you can have multiple objects in that VI.

So you can view data easily, e.g. for Tools, you can open this VI and as a developer you have essentially created a configuration dialog for your tool.

Summary: I think it really depends on the use case and user preference!

I go in through Active Content.

It appears that the font used by system controls has changed between XP and Win7. As a result, some character graphics (progress bars using ||||||||) that I used in tables and MCLB system controls no long fit the same. Does anyone know of a way to fix this? Di you even know what the font (and size) was in XP and is in Win7? I poked around but could not find it.

Sure wish we could embed data types and controls other than string in a MCLB or table.

thanks for any suggestions.

-John

Some of my GUI got severely messed up when they were compiled n XP but were run buy the client in Win7.

I found it easier to switch to compiling in Win7.

It is indeed an important improvement!

Tell me about it

This will translate into other areas too - for example in LV2009 a Shared Variable API Refnum will also break when linked to a typedef, and the type-def is updated.

Error occurs!

LV could not find addons\_ICON Library\scripting\_icon_lib_scripting.lib.

Thanks huotom.

Sorry, some files were missing from the build.

The new version (0.14.1) is up on LAVACR and has fixed this issue.

Cheers

-JG

In LabVIEW 2010 if I now link a Type-Def to a Shared Variable, the linking is persistent on the Control updates

This is a feature I have been looking forward to for a while.

I didn't know it made it in until I just tested it then, so I'd thought I'd share.

This is going to save a lot of time.

Thanks NI

Cheers

-JG

LabVIEW 2009

<object id="scPlayer" class="embeddedObject" width="619" height="633" type="application/x-shockwave-flash" data="http://content.screencast.com/users/jgcode/folders/LabVIEW/media/c01d213a-8e59-4b38-8d61-01c66567b340/jingswfplayer.swf"> <param name="movie" value="http://content.screencast.com/users/jgcode/folders/LabVIEW/media/c01d213a-8e59-4b38-8d61-01c66567b340/jingswfplayer.swf"> <param name="quality" value="high"> <param name="bgcolor" value="#FFFFFF"> <param name="flashVars" value="thumb=http://content.screencast.com/users/jgcode/folders/LabVIEW/media/c01d213a-8e59-4b38-8d61-01c66567b340/FirstFrame.jpg&containerwidth=619&containerheight=633&content=http://content.screencast.com/users/jgcode/folders/LabVIEW/media/c01d213a-8e59-4b38-8d61-01c66567b340/SV%20Type%20Def%202009.swf&blurover=false"> <param name="allowFullScreen" value="true"> <param name="scale" value="showall"> <param name="allowScriptAccess" value="always"> <param name="base" value="http://content.screencast.com/users/jgcode/folders/LabVIEW/media/c01d213a-8e59-4b38-8d61-01c66567b340/"> </object>

LabVIEW 2010

<object id="scPlayer" class="embeddedObject" width="711" height="648" type="application/x-shockwave-flash" data="http://content.screencast.com/users/jgcode/folders/LabVIEW/media/f8ea8774-4a97-4fdb-94ff-ac0b5413e00a/jingswfplayer.swf"> <param name="movie" value="http://content.screencast.com/users/jgcode/folders/LabVIEW/media/f8ea8774-4a97-4fdb-94ff-ac0b5413e00a/jingswfplayer.swf"> <param name="quality" value="high"> <param name="bgcolor" value="#FFFFFF"> <param name="flashVars" value="thumb=http://content.screencast.com/users/jgcode/folders/LabVIEW/media/f8ea8774-4a97-4fdb-94ff-ac0b5413e00a/FirstFrame.jpg&containerwidth=711&containerheight=648&content=http://content.screencast.com/users/jgcode/folders/LabVIEW/media/f8ea8774-4a97-4fdb-94ff-ac0b5413e00a/SV%20TypeDef%202010.swf&blurover=false"> <param name="allowFullScreen" value="true"> <param name="scale" value="showall"> <param name="allowScriptAccess" value="always"> <param name="base" value="http://content.screencast.com/users/jgcode/folders/LabVIEW/media/f8ea8774-4a97-4fdb-94ff-ac0b5413e00a/"> </object>

Project Explorer integration... ... <- make it happen.

I hear ya!

You seem to be fine with the OpenG VIs, but you could probably also modify the MGI VIs so that you can easily save to the same file.

Nice link.

I wonder if the MGI people have a solution for inherited class? (and whether they post here?)

Managing multiple Section names for inherited classes was too hard for me, I much prefer OpenG VIs.

GDamnit, I suck

Do you want users to be able to see and edit the class details? If so, ini files are as good as anything. If not, saving to a binary format would probably be wiser. (Users have an annoying habit of messing with things that are better left alone.)

Or you can put a checksum in your file. Change a bit and they're screwed... (That should teach them some manners...)

I have had some customers who just want to 'see' the data, others like to (or are happy to) use it as an API into the system.

Application fit and finish--like storing default values and other user customizable information--is pretty low on the priority list.

I thought this would be a bit more of a higher priority in most cases (not higher than than the test rig working obviously)

e.g. From my experience only, customer loses their app custom settings on startup = annoyed customer.

So its normally a req.

Nice job Jon! LVOOP Assistant is now my second favorite user contributed tool. (Hard to dethrone CCT, though I will definitely use this more than CCT.)

Thanks Dave

"Link to your own Static/Dynamic method (.vit) templates

Create your own Virtual Folder names etc..."

Both of these occurred to me while watching the videos. Being able to set my own templates would be more useful for me than defining custom virtual folder names. I tend to create virtual folders on an as needed basis depending on the class requirements rather than use a pre-defined set of folders.

My next step is to open this up.

The settings are what I like, but obviously people would have their own templates that they like - so I can point to those.

[Virtual Folders] The LVOOP Assistant gives me the option of adding my favorite folders anytime to the Class without the need to worry about syntax or scoping etc... (and if they already exist it just ignores it). You can start with a few and as your Class changes over time you can bang in more.

"Public Service Announcement"

Since LabVIEW is a contracronym is the first place, shouldn't it be LVIEWOOP? Or just LOOP?

I don't want to get bashed, so I am going with L-VOOP

This is a really nice convenience, thanks!

Joe Z.

No probs!

You can limit your responsability by making the package to be installed on version = 9.0 instead of >=9.0...

But then, you'd have to make a new package for 10.0 after you've verified the compatibility, and 11.0... and 12.0.

I suggest you wait until it breaks.

I did look that this originally, but yer, its not really maintainable for me, so v1.0.5 is all opened up.

but I'm not sure it's intuative.

Agreed.

Sorry, I was out most of the morning, so I didn't spend as much time on feature some of it as I wanted to.

But wanted to get it out for feedback

My first goal was proof of concept (that I could script it).

I can always give it a facelift, now that I have the functionality.

So at the mo, you are cloning the active VI, i.e. QD'd VI.

I tossed up separating the functionality into another tool (but didn't for whatever reason) - so I have thought about that it may not be best suited where it is.

So for now (no proj int):

Maybe a dropbox of all VIs in the Class would have made more sense too? You could clone multiple methods at once, but that is not my usually use case.

I could make it a separate Tools Menu action that operates on the Active VI - that might make more sense?

Thanks Jon. Exposing non-standard features using VIPM is very helpful.

Note to users: NI's policy is that vis in vi.lib are not for public use unless they are on the default palettes. Functionality is subject to change in future versions and forward compatibility is not guaranteed or implied. This isn't to discourage anyone from using them, just be aware of the potential consequences.

Good point - although I thought that was what the resource folder was for

I have been digging into this API more and more with scripting etc...

So I didn't want to keep doing this from disk.

I haven't had to persist object data in my apps very often (uh... ever?) so I haven't got around to doing it yet, but I'm sure it could be done.

How do you normally (/like to) store your application's configuration (settings) data?

For me: Like MGI's example I like to keep the data in the Object and read and write the "Object" rather than passing the data out to some other structure. This means I do not have to expose 'private' data through less protected APIs, whilst making use of cluster to ini functions and not having to expose that cluster as well (except to File IO Friend Class).

Like Francois said, the downcast prim is based on wire type, not object type. Try using the Preserve Run Time Class prim to get the behavior you expect.

Feature Request: Clone a Method VI

I have updated the repository with a new version - you can now easily clone a method using this tool.

Supported Templates include:

4815 - 4x2x2x4

4833 - 5x3x3x5

4834 - 6x4x4x6

4835 - 8x4x4x8

(Assumes any other LVOOP Class Control is a data member or parameter).

<object id="scPlayer" class="embeddedObject" width="1113" height="737" type="application/x-shockwave-flash" data="http://content.screencast.com/users/jgcode/folders/LAVA%20CR/media/a4f9ea3b-9061-4523-88b1-452d556909df/jingswfplayer.swf"> <param name="movie" value="http://content.screencast.com/users/jgcode/folders/LAVA%20CR/media/a4f9ea3b-9061-4523-88b1-452d556909df/jingswfplayer.swf"> <param name="quality" value="high"> <param name="bgcolor" value="#FFFFFF"> <param name="flashVars" value="thumb=http://content.screencast.com/users/jgcode/folders/LAVA%20CR/media/a4f9ea3b-9061-4523-88b1-452d556909df/FirstFrame.jpg&containerwidth=1113&containerheight=737&content=http://content.screencast.com/users/jgcode/folders/LAVA%20CR/media/a4f9ea3b-9061-4523-88b1-452d556909df/LVOOP%20Assistant%20-%20Clone%20Method.swf&blurover=false"> <param name="allowFullScreen" value="true"> <param name="scale" value="showall"> <param name="allowScriptAccess" value="always"> <param name="base" value="http://content.screencast.com/users/jgcode/folders/LAVA%20CR/media/a4f9ea3b-9061-4523-88b1-452d556909df/"> </object>

This feature was sponsored by:

Where drinking from a camouflaged can... ...makes you look tough.