LAVA 1.0 Content

QUOTE(orko @ Aug 15 2007, 11:41 AM)

I would like to see what others have done (Xcontrols with additional blink properties perhaps?).

I TRIED to create an XControl once, but learned that the blinking is only active when the XControl is running.

A possible place to look for inspiration might be Stephen's Scrolling LED XControl.

The NI site has lots of real world examples in various fields.

Try looking here: http://www.ni.com/solutions/customer_solutions.htm

Good luck! I worked several years ago for a company that used C & CVI for test coding, and they wanted my group to change. Luckily, we had a large enough group and a manager that loved LabVIEW.

Simple, and works great! There are so many ways to skin a cat. http://forums.lavag.org/index.php?act=attach&type=post&id=6633

Using the picture ring, you could have a single indicator that shows not connected, connected, busy, error, etc.; update it by value based on an enum (like in a state machine) AND have it animated (almost "for free"). You can do it without property nodes or extra code.

Lookup the toughbook

I have seen these in action and quite possibly are the best rugged laptops I have come across.

My implimentation uses an animated GIF file. The GIF will always update, even when the VI is not running. I effectively stop the animation when running by selecting a different item in the ring. I should have placed a single frame 1 pixel gif as the first item in the ring; this post was jus a quick example for someone on the Info-LabVIEW mailing list where attachments aren't possible.

Note that you can use any type of GIF on the front panel or the block diagram (

didn't mean to leave that there). I included the decoration and custom background color on the fp to show the transparency.

Drag and drop a few of the "smileys" from the LAVA forums into a picture ring. Don't get carried away, though. You wouldn't want your VI to start looking like a myspace or geocities page

Animated GIFs :thumbup: :headbang:

OOOOOoooooh

This is one of my favorite hacks.

Do not give up on the array just yet, although I am a member of the camp that tries to avoid arrays on FP.

SIDE NOTE: if the baby (Anna) does not start crying before the end of this post, I'll make a quick code snibbit detailing this process

That being said, you CAN get a reference to the element of an array, now keep in mind that it is a generic reference BUT and this is a big BUT

You can register that event to a value change event/and or whatever other event you are looking to trigger off of.

And here is the beauty of it all. Say you register that array element for the mouse up event, the event structure will give you a CtrlRef to the specific array element that fired the event, thus allowing you to get the value of the specific array element that triggered the event.

Now the only caveat is that you have to do some mouse/ctrl position magic to determine which # element changed in the array, but you're in luck, this code already exists somewhere on this forum, possibly in the CR.

Well the baby did start to cry...... REALLY Cry and I'm out for now, i'll try to update the post later

ok back... inside of this VI you will see 2 examples

1. Registration of the entire element of the array to a val change event

2. Registration of an element of the array to the val change event.

The way to get the static reference of the lower level elements is to simply right click the element and say make reference.

Enjoy

From your friendly neighborhood captain

QUOTE(Puzzlemaker @ Aug 14 2007, 12:24 PM)

Yeah, I ended up with a super-complex cluster. I was trying to avoid that, thinking maybe there was some sort of way to store the data.

Can you explain this statement a bit further. How would the data storage avoid the need to develop a large complex data structure? As was mentioned earlier this is really two separate problems; desiging the data structure (cluster or otherwise) to contain your configuration information and, secondly, storing that data structure in a file.

The cluster is the most native way to store such a structure in LabVIEW, but other options are available. Then storing such a structure is the seocnd challenge. Quick and dirty ways to store any cluster from LabVIEW into a file is the Datalog file or the conversion to XML/XML file storage VIs included in LabVIEW.

The XML functions are in a sub-palette of the string palette, while the Datalog File VIs are found in a sub-palette of the Advanced File Functions.

Christian

Example of using a classic transparent picture ring to show & hide a Mozilla type "throbber" on your front panel.

If your company has a content filtering system like Websense then the VI Road Show page will load, but the video frames will appear blank. The best you can do is watch these videos from home :thumbdown: or hope that NI can find a place to host these videos on their own servers...

QUOTE(jpdrolet @ Aug 14 2007, 08:39 AM)

100% of population will be at animal level in 2½ years.

I don't think this will happen in Alfa's lifetime; (n-1)/n * 100 is the closest it will get...

QUOTE(Jim Kring @ Aug 13 2007, 08:02 PM)

Since the whole point of DAQmx is to have context sensitive functions (on top of a well designed state model) that simply "do the right thing" when they are called, I'm guessing that the DAQmx API designers would agree that calling the DAQmx Read function on a task that is not yet running should repeatedly try to start the task (until a timeout occurs) if a "resource already in use" error occurs inside the DAQmx Read function.

This bug is going down...

Jim,

I could not agree with you more. My solution to the problem is semaphores, I create a wrapper around Daqmx read with an acquire semaphore before the DAQmx read and a release after. I pass the reference to the semaphore using a VIG or just obtain the named semaphore inside the wrapper. This gives the Daqmx Read the functionality you would expect it to already have, it works pretty good.

QUOTE(Aristos Queue @ Aug 13 2007, 10:38 PM)

[...]

Typedefs are dumb. They have no memory. Other tools that index into typedefs store indicies or store names (which ever seemed most logical for that particular tool), but neither is satisfactory when the typedef gets edited. The typedef does not remember "This was 1, this was 2, and this didn't exist at all before" to allow other tools to correct themselves. The behavior you get is the behavior you get.

[...]

Hi AQ,

I do understand what you mean and don't expect the type def to be a magic tool, but I just wanted to point out that the behaviour is different wether the cluster is a type def or not. You say "The behavior you get is the behavior you get" well... Regardless of what classes can do, to me, the behaviour I get is a non-consistant behaviour ; this is what bugs me.

Now, this said, I guess you're right and I should free some time to learn to use LV classes ; that's on my roadmap.

I belive your best bet is to try to re-architect what you are doing because I don't think that since the limitation has already been fixed in future versions that NI will help you find a work around.

Welcome, feel free to ask for anything other than 2 things: cracks to licensing and solutions to homework problems. And keep an eye out for scarchasam, it's currently running a muck and we're trying everything we can do to isolate it.

Have fun

~,~ Premium Blend

Hi,

Take a few seconds to do this :

- create a cluster with a few control in it

- save it as a type def (or strict type def)

- place it in a VI, and create a property node on one the control inside the type def

- save the VI

- open the type def and modify the order of element of the cluster

>> The property node is no longer linked the same object but to the object that now has the same index as before, idem for an event in an Event Structure.

This behaviour is surprising and not consistant because if the cluster is not a type def (or strict type def) the property node and the event remains linked to the same object, no matter its new order.

Noticed in LV 8.20

Anyone thinks this should be repported to NI as a bug ?

Oh, the food is GOOD in Texas!!!

Yummy!! And people were great!

Thanks again guys for the fantastic BBQ!! You guys ROCK!!

Can the work be done remotely, with final integration done on-site?

I have a large (multi-gigabyte), fixed record length binary file that I extract values from in a post-processing step (no data acq running). I used queues and parallel loops to improve my data load time from ~5 minutes to ~30 seconds!

Here is a picture of my VI. My records are binary, but you could use "read lines" and a for loop to enqueue the strings in the lower loop. Part of my conversion to actual values is done in a sub-vi that I use in other places; you could use Ton's example to extract the values from the string (spreadsheet string to array).

To improve your load time; Use parallel loops to retrieve data and convert it; predefine your array sizes and use replace element instead of build array or autoindexing.

The "King of Staves" might have been renamed the "Kring of Staves".

Some of the avatars look familiar! (and thanks http://forums.lavag.org/index.php?act=attach&type=post&id=6598)

I just finished looking at Aristos' LabVIEW Tarot Deck, and I must say that "The Palettes (IL The High Priestess) card is great. I hope he doesn't mind me placing it here.

http://forums.lavag.org/index.php?act=attach&type=post&id=6593

A change to the palettes is a break in harmony. I've been trying to come up with a good analogy, but I keep thinking of Figure 3.3 on Page 21 of "A Software Engineering Approach to LabVIEW" (recommended to me by Stephen). The figure depicts four interfaces; a British (right sided) dash board, a tank control, a joystick control and a gameboy type control. Quote from the book:

QUOTE

"Transferring from one mode to another would involve learning a new combination of controls. This would not only be tiresome but could be dangerous. The likelyhood of an accident is greatly increased during the learning phase"

I don't want to die in the CLD test!

I'll share one last thing; my IT department asked everyone to install Office 2007 by the end of July. I blindly obeyed, and now "experience" what M$ calls the "Fluent" interface, but I affectionately call "Effluent". The Office 2007 toolbar now looks like this:

http://forums.lavag.org/index.php?act=attach&type=post&id=6594

Note that the File menu option is missing. Not moved, GONE!

"OK" I say; just press F1, search the help and figure out how to turn it back on... Aha! You CAN'T!

http://forums.lavag.org/index.php?act=attach&type=post&id=6595

Now you understand why I'm frustrated and "touchy" about changing the interface...

QUOTE(Christina Rogers @ Aug 9 2007, 09:41 PM)

You can copy the INI file from your previous version of LabVIEW and you should, for the most part, feel right at home in 8.5. I agree this should be easier, and I've talked to a few people at NIWeek about how we could improve the upgrade experience to preserve the user preferences.

Hi,

Who shall I direct the following request to ?

I'd like to be allowed to bring my labview.INI file with me at the CLD.

Maybe if NI receives dozens of same request, things will change

Thanks

QUOTE(LV Punk @ Aug 9 2007, 08:13 PM)

[...]

Again, I say leave the friggin' palletes ALONE!

I totally agree with LV Punk and i2dx. There has been a significant change in the palettes layout introduced with LV 8, it took me a while to get use to it (and I know I'm not the only one) but I have to say that it is now more organized than it was in LV 7 and earlier. But changing at every new version does not make any sense.

QUOTE(LV Punk @ Aug 9 2007, 08:13 PM)

Link 1:

No Express VIs Required!

Link 2:

Do you use Express VIs?

Most answered NO!

Link 3: Perfect analogy for Express VIs "

They are what crayons are to art

"

As regards express VIs, well... I never used them and never liked them until I saw a demo of the brand new vision acquisition and vision assistant express VIs, these two are really really well done (nice job Brad :thumbup: ) and I encourage everybody to give them a try.

I am now wondering if the other express VIs have been updated the same way, if so I'll start to use them.

I appreciate that NI is trying to improve the user interface, but come on. Defaulting a new install to the Express VI pallete? :thumbdown: NI, for the love of god, PLEASE stop f'ing with the palletes!

I spent over 10 minutes configuring the LabVIEW environment before STARTING my CLD test. I missed by two points because my functionality was not completed. The architecture was there, I just ran out of time. If I have to use 8.5 and a yet another NEW pallete scheme for my retest (in ~ 3 weeks) then I might just as well cancel the test and stay a CLAD.

Sorry. This just sucks. What are people on forums supposed to do to help new users? You tell someone to look under Functions>Programming>Dialog & User Interface>Events and they reply "I don't have a "Function" or "Programming" choice?

Again, I say leave the friggin' palletes ALONE!

Link 1: No Express VIs Required!

Link 2: Do you use Express VIs? Most answered NO!

Link 3: Perfect analogy for Express VIs "They are what crayons are to art"

(Whew. We now return you to your regularly scheduled program...)

QUOTE(silmaril @ Aug 7 2007, 12:32 PM)

Which kind of hardware are you using?

The point is: if your I/O hardware can do the critical timing, all your LV application has to do is initialize it and get all the data when there is time

QUOTE(cobra21 @ Aug 7 2007, 09:31 AM)

USB? Hmmm. Is it USB 2.0 compliant? Are there intermediate drivers or is ActiveX involved?

When I hear USB instrumentation, I also start to think laptop computer. A laptop might be configured to conserve power causing I/O delays... USB is fast, but not deterministic. If you're passing alot of data back and forth then there might be blocking; the USB interface is busy on a large read of data and is not available for a write...

From the NI website: "As the industry's most famous and prolific data flow programming company, NI maintains the highest quality standards that its customers deserve. Unfortunately, their customers don't realise that they deserve project-oriented, self-optimizing, and altogether non-G code material in their 'SSP' subscription packs." Give us some GOOP to dip into and we're happy!