ShaunR

Well. Ever since LV2010 I've noticed that even the IDE takes forever to shut down. I have assumed (rightly or wrongly) that it is something to do with making sure the run-time exits elegantly, so the implications of a task-kill may be subtle and/or horrendous in some unknown scenario (DAQ config?).

Suffice to say. NI have done something during the shut-down process that has increased the duration significantly. I would compare your software with one that has been compiled in 2009. I would expect it to exit far more promptly if it is down to the NI environment.

Connecting VIs via their error terminals is the preferred method to a sequence structure.

You should be able to run everything on a PC configured as an RT target.  Just make sure that the equivalent PCI versions of the cards you need are supported under LabVIEW RT.  If they are, then you should be good to go.

 

The biggest issue with using desktop PC's with LV RT is that the Ethernet chipset may not be supported under LV-RT.  Check this with the NI utility (there is a utility you can load onto a USB stick to test whether your PC will work with LV RT) or on their website documentation about the various chipsets supported with each version of LVRT, and you should be OK.

 

Neville.

Yup. LAN is usually the issue. Also. Different LV versions work only with certain processors - Something to bear in mind if you are trying to leverage an old PC sitting around.

Requirements for Desktop PCs as LabVIEW Real-Time Targets

Nice find

It would be nice if the tolerance had a default value so for most use cases we didn't have to specify it.

Yup.

+1 to Ton

I don't know if I am one of those you are referring to as arguing "everything should be public," but I don't think I made that claim at all.  I assume you're referring to Shaun.  I have claimed that putting restrictions on a function reduces it's utility, which I loosely define as the number of places the function can be used successfully, but that's not the same as claiming everything should be public.

I never claimed "everything should be public" either. I argued protected vs private.

How I wish this one was true. I'd have definitely had a go

And in further exciting news in airlines, Richard Branson has announced a breakthrough (!) in aviation by revealing glass bottomed A320s for his single class but sensationally scenic Virgin Atlantic domestic UK entrant ‘Little red’.

Virgin ‘Little Red’ gets glass bottom

Will you elaborate?

He can use a variant for different datatypes (array of boolean or array of doubles) and therefore won't have a problem with overrides.

I know this went a bit off track, and admittedly I haven't read (see: understood) all discussions. But, I can see a benefit of must implement in a current app I am writing. I want all child classes of my parent "output" class to implement a "write data" method so they fit nicely into my framework. It makes sense, any output should have a method to write to that output. The problem is the connector panes need to be different. Think about a digital write vs. an analog write. I want these to be enforced in all my "output" child classes, but I can't because one needs an array of booleans, the other an array of doubles. 

 

Go ahead, throw the tomatoes. 

Variant tomatoes? The problem isn't so much with different data-types, it is more numbers of terminals where you run into trouble.

A file with tag names, expected values and/or limits . Different set-ups have different files.

(sorry to be sparse, but can't help thinking I've described this to you before, somehow )

An individual node may be generally known to work on a target

That may sufficient for the OP and it is a lot closer than nothing at all..

 Functions that work on one FPGA may not work on all FPGAs... functions that exist on one desktop target may not exist on all desktop targets. It is up to the particular target to decide whether to accept the code or not when the VI loads on that target

Right! So that must be documented somewhere (as it was for the Single Precision Functions in the FPGA example I gave). I doubt if the "rules" for the particular target are that esoteric that you can only load this single precision object on this FPGA target when it's Tuesday and you have your left trouser leg rolled up. It's more likely that it will be things like an FPU isn't present on that target (that will be documented internally at NI) and the manual will supply the features that are or are not applicable.

The OP says that it may not load on the target because the VI may be broken due to wiring, missing dependencies etc. So he is looking to weed out incompatible features (like the DLL checker that is used to check Pharlap DLLs). This is presumably so they can write it "offline" and verify the developer hasn't used unsupported features,

At the simplest level you are trying to end up with a compatibility matrix accross LV versions, targets and features. I would be very surprised if an engineer at NI hasn't got a spreadsheet with it somewhere (probably an applications engineer) Once you have that, you can add simple rules for "odd" anomalies. You don't have to start with all targets or LV versions. However, eventually you will have a complete picture. After all. Most people that use the targets "know" what does and doesn't work. It just needs to be formalised to be able to use it programmatically.

 one way would be to evaluate each and every BD object against a positive (or negative, whichever is fastest) list for each target. In that light a wire stump will not invalidate VI A from FPGA compatibility, while a DBL constant will.

 

/Steen

I think this is the only (reliable) way.

The functions and features supported on each platform are documented (example) but not in a single list that I'm aware of so you would have to spend a bit of effort pulling it all together (property nodes have tables in the help that state quite a bit about where they will and won't work).

Once done however, it can be put in a DB along with LV versions etc making examining a VI fairly straight forward with scripting. You would just need to keep the list updated with the latest LV version. You never know. Maybe NI have an internal doc that pulls it all together. Worth asking your local rep.

Rolf is the man you need to talk to.

But here is my limited tuppence.

Pharlap uses a stripped down windows API that implements many but not all Windows API calls (I'm pretty sure you cannot use normal windows kernel mode drivers AKA sys files-Rolf will confirm). There is a checker that you can run on DLLs to see if they are compliant and you need the version for which LV version you are using (I've linked to the 2009 one, but there are 2011, 2012 etc that you can find with a bit of Googling). If it is not compliant and you do not have the source, then you are up a creek without a paddle. If you have the source, then you will have to hide in a dark room for a couple of months to make it compliant.

If you need a "sys" file then this is a hard-core kernel mode driver and fraught with rabbit holes not only in respect of the driver, but also it working within Pharlap. It is an "expertise" in its own right - I would highly recommend you sub-contract it out if you cannot get support from the supplier or choose a different card.

According to wikipedia

National Instruments sells the NI USRP 292x series, which is functionally equivalent to the Ettus Research USRP N210. NI also offers LabVIEW support for this device with the NI-USRP Driver

The only major difference I can tell is the size of the FPGA and NI don't state that there even is one in their docs.

There's nothing quite as confidence-shattering as feeling like the dumbest person in the room. 

You get used to it

Thanks ShaunR... your clear analisys of what was wrong help me find a solution... just I will use a file for each language instead of an unique file for the all languages... but it seems to be great...

 

 

Max

Well. I've been there. I wrote a library for changing UI elements "on-the-fly" (passa mak). I deliberately excluded unicode since it is platform dependent, but it could be modified for a particular use case.

Labview doesn't (officially) support Unicode. There is a "hack" to display Unicode chars in indicators, but all labview functions/primitives still only support ASCII.

You need to use the library that Tim_S linked to to even have a chance of manipulating unicode chars, which you are obviously not using.

You should really say "No like the president"

When people ask me how I spell my name. I say "like the sheep"

I have, sort of But only for the UI (not for things like charts etc, but I suppose I could have).

I used the same code as I use for config dialogues (it just iterates over UI controls), and kept a history of changes in a DB. You then just query the DB. You can go back, forward and, if you put a little bit of additional info in (like a short description), you can list the last (say) 10 changes in a menu and jump straight to them unwinding the list.

By linking the entries to the control label, it works transparently and is not application dependent. I also attached events to all controls that I was interested in so I didn't have to write specific queries to enter them into the DB.

Sorry if this is off topic but this is the second time you have called me by my name (sorta) do I know you?  How do you know me by my name?  And not that it bothers me but could you please refer to me as "hooovahh" (or hoovah if you don't count the correct number of letters) other members may only know me by my alias and I think it was be easier if we referred to each other by our internet names.

Nope. Don't know you or what your real name is (a hoover is a vacuum cleaner over here and in everyday usage). It was, and always will be a typo (apologies).

My handle, however, IS my real name. (I don't care how you spell it and even I get it wrong sometimes whilst typing. Luckily I rarely refer to myself in the third person )

Yup.

What hooovahh said.

So I've tried to load every snippet in this thread to LV2012 and all I get is a picture on the BD. I tested LV by grabbing a couple from the dark side and they work fine.

 

I created a few of my own as well and could load them back in.

 

Could there be a filter on the LAVAG server that is stripping out the meta data?

 

I'll share my SuperSecret toggle snippet here and see if I can load it back into LV.

 

Change SuperSecret Setting.png

 

 

EDIT:

 

I think something is happening on the server. My image file on disk was ~15k in size and when downloaded is ony 5k.

 

Hmmm....  

Yup.

I checked my snippet after Hoover said (on another thread) and it was fine.

I've now uploaded the same snippet to http://postimage.org/image/5p8stekp7/ and it works fine when downloaded. Definitely something going on with lavag.org. Maybe it's now being optimised/compressed?

You are expecting that "Whole Match" really means Whole Match except those bits I don't want?

LV Help

whole match contains all the characters that match the expression entered in regular expression. Any substring matches the function finds appear in the submatch outputs.

To match individual components you have to create capture groups. The ?: syntax means that you exclude that component from the list of capture groups (this isn't a LV peculiarity, it's how all regex parsers work).

So whilst  (The quick brown fox jumped over thes*)([a-zA-Z0-9]*)(s*dog) will give you three terminal outputs with

1. The quick brown fox jumped over the

2. lazy

3. dog

(The quick brown fox jumped over thes*)(?:[a-zA-Z0-9]*)(s*dog) will give you only two terminals with

1. The quick brown fox jumped over the

2. dog

Similarly. The quick brown fox jumped over thes*([a-zA-Z0-9]*)s*dog will give you only one terminal with

1. lazy

In all cases the Whole Match will give you the whole string if all capture groups match and bugger all if it doesn't.