TG

QUOTE(dthomson @ Feb 16 2008, 05:50 PM)

I've got a system in which there are numerous top-level VI's running in parallel. One of them will obtain a reference to a functional global and then share that reference with other top-level VIs. Each of these VI's can then call the functional global and have it execute various commands .....

if the functional global is reading a long file and another VI tries to access it, the 2nd call gets an error 1026, reference not valid.

A Call by Reference is similar to a sub-vi call. I would expect that the LV scheduling system would queue up requests to the functional global like it would for any other sub-vi call.

I haven't been able to find documentation on this feature. It makes a certain amount of sense, but surprises me since it apparently isn't documented. Does anyone else know about this "feature"?

Thanks,

DaveT

Sounds to me like the scheduler is not handling the refwerence correctly or the error is normal under your scenario.

The ref goes invalid because it is in use by the long running VI perhaps?

The other Vi sees a locked or busy reference and then assumes it is invalid after a timeout?

I can feel ears perking up right now LOL!

I may have run into stuff similar to this before but usually I go bezerk and just fall back on a crappy work around to keep things moving along.

Like repeatedly testing the reference in a loop (ignoring 1026 error) until it becomes valid again (with a timeout of course).

Just thinking out loud here...

one thing I know is LV sometimes invalidates references with me but the rules are not so clear as to why. Its always a valid reason but still

somewhat of a pain to track down.

As an addendum to my senseless gabbing I think if you have not already digested this it might be helpful. At least there may be a clue there and an idea as to how to proceed.

http://wiki.lavag.org/Lessons_learned_from_plugins

QUOTE(tcplomp @ Feb 8 2008, 05:22 PM)

So what I do for tools (like the Code Capture Tool) is put the code in '_' folder, then create a .mnu file that contains the items I want (and that refer either to a <user.lib> or are located in the source and refer to a relative path to the '_' item), than copy that together with the items I want.

You can put the .mnu file in the user.lib folder and it will show up restart (or fire a private method called app.palettes.refresh)

The ini stores the views and position of the palettes, so that will be covered by this.

Ton

I appreciate the response Tcplomp.

I just wish I could follow through on it. Ive read it a hundred times.

please bear with me, this may be a dum Q but how is a mnu file created?

I have always struggled with LabViews palette folders, especially User.lib folder.

I have 4 copies of LabVIEW 8.2.1 and I need to work on one program at a time in 4 different places for various reasons.

What Id like to be able to do is have "exactly the same" user.lib palette display on the four machines so as to not get twisted around looking for

user made VIs.

I really would rather have a few meaningful tips as to how this and other nice things could be accomplished.

Its easy enough to copy the folder but Q is how do u guys get the palette views to copy over?

Also, since Ivs started this one how about a palette tips and tricks thread regarding user palette for future

Thank You

Gosh Darnit. I used to get those really great videos u guys post. Now all I get is a blank page.

I hope it on Lava';s end.

Id like to know whetre the state charts are in version 8.5?

Perhaps I am missing something.

QUOTE(jfazekas @ Feb 6 2008, 05:04 PM)

Conclusion: Cluster method is always faster. For extremely simple data types, the cluster method (on my PC) is twice as fast. I did an example of a very complicated data type and the cluster method was 1.5 times faster.

Thats not bad. I thought it would be much slower.

Seems proper to make the tradeoff if data privacy and protection is high on the priority list.

QUOTE(JoeLabview @ Feb 3 2008, 07:39 PM)

One thing you left out is the difference in experitse over the visitor from NI & LAVA.

I look around here and you have a higher percentage (per capita) of experts than NI.

This is where the enveloppe gets pushed.. So numbers don't mean much in that respect.

I agree, in my exp there is a lot of eye glazing at NI when a significant Q is asked.

That does not happen here. Thats whay I joined in 2006 and never regret it.

QUOTE(Aristos Queue @ Jan 15 2008, 05:17 PM)

Take a look at this:

http://dontclick.it/

There are some interesting aspects to this UI.

Thoughts?

Even though I found it initially confusing I appreciate that the 'world' is realizing the drawbacks to mouse clicking.

I been clicking over 20 yrs now and believe me it actually hurts to click now.

Id also like to see visual panning based on eye or head movement.

QUOTE(Michael_Aivaliotis @ Nov 11 2007, 04:05 AM)

It was back in http://web.archive.org/web/20021106025801/http://www.lavausergroup.org/' target="_blank">November of 2002 when I decided to start the LAVA website and forums.

..........................

It was pretty awesome to meet with LabVIEW users outside of the traditional sales oriented framework of the NI funded meetings.

Thanks Mike. Not only for starting LAVA but for keeping it honest.

I personally have learned much about advanced concepts here, simply by reading the posts and trying out the uploaded VI's.

QUOTE(crelf @ Jan 2 2008, 07:35 AM)

http://lavag.org/old_files/monthly_01_2008/post-181-1199259246.png' target="_blank">

Congrats Tomi, and thanks so much for all your wpmderful posts so far. ;beer; here's to another 1k!

A nice cold :beer: for -> Tomi (Jimi)

for all the expert help you have given me.

QUOTE(PeterB @ Dec 12 2007, 12:33 AM)

[/indent]I have only just recieved a 2nd set of our 3rd quarter Dev Suite CDs. Thankfully NI was slower down-under for distributing the dev suite.

Peter

This is a joke right?

Guess not.

How about if I installed 8.5 full from the DVD.

Do I have to remove these parts or can they be overwritten with a fixed device drivers CD set or DVD?

Most likely not using the affected files (yet)

(I guess Ill ask NI about this too)

BTW Thanks Michael thanks for bringing this up here. Appreciated.

QUOTE(Stevio @ Dec 10 2007, 03:19 PM)

Hellow,

I need to design software for a medical application as a schoolproject. I have already a classic 1D array that is been visualized in a graph. (see attachement) How can i calculate the frequency of this signal? Another parameter i want to know is the risetime of every pulse...

When i visualized the derivate of this signal i see a lot of noise in it. I guess this is because i have an array and not a real signal. Is it possible to smooth graphs? I never used filtering before.

Thanks in advance

Greetings

There is a nice peak detector in the palletes somewhere. As long as you can find a good offset value as a trigger for the input it will work just fine

QUOTE(Michael_Aivaliotis @ Nov 17 2007, 12:07 AM)

Not really, but in the context of LabVIEW, it has special meaning to LAVA members. We definitely need an entry in the LabVIEW Wiki on "spaghetti code" and the FSM (Flying Spaghetti Monster).

Heh Im one of those spagetti guys but can't helpit.

Hard habits are hard to break.

quote name='Kevin P' date='Dec 6 2007, 02:37 PM' post='39375']

Could you post the LOGGER code?

-Kevin P.

Edit -> Arrrgggg!!! I think I found it! Man! Stupid got me again.!

Kevin, Thanks for suggetesting I upload this to the forum.

It forced me to look really hard and I am pretty sure I found my "issue".

Turns out my hard coded path was sitting in a typedef, was defaulting to empty and my error trap was not set up to shut down the LOGGER state machine immediately.

Ill let you know if it actually solves the problem when i get access to the rig again.

Cold bear coming at ya

QUOTE(Kevin P @ Dec 5 2007, 01:45 PM)

What part of the code actually opens the file ref? I've been bitten before when I had a dynamically called process launcher vi that opened a bunch of refs to files and queues, etc. I then passed the refnums along to other dynamic code.

Trouble was, the vi that originally opened the refnums ran to completion and went into idle state. Shortly after that, LabVIEW closed all the refnums it had opened as part of its automatic garbage collection, and all my dynamic vi's started throwing errors.

Since it isn't clear to me where your file refnum gets opened, I wonder if you may have a situation like mine? (Assuming you've ruled out the earlier suggestion about one of the state machine cases failing to pass the refnum through to the right-hand shift register.

-Kevin P.

Intersting Kevin..

Thats the thing. None of my vis are running to completion. Also there is no way to reduce to an example this since many VIs are instruments

and its all coupled.

I can't get access to the rig for another week so I'll speculate here, maybe someone can remember some rule or similar occurance.

The outter wrapper to the segment above is simply a queued state machine and it is dynamically launched (no wait until finished) from the MAIN processor state machine, which itself is static and runs continously.

In other words

MAIN is STATIC and launches PROCESSOR and LOGGER

PROCESSOR then launches various PROCESS's (clones)

the clones send data to LOGGER during their lifetime however the clones have no link to (or even awareness of) the file ref. Only LOGGER has the file ref in its memory shift register.

None of the important stuff is shutting down. its just that they are seperate entities not tied to each other by data flow.

The file ref seen above is opened by LOGGER

The segment above is contained within the "log to disk" frame of LOGGER..

Its all pretty simple actually, despite my imperfect attempt to illustrate with words.

The only complex part is that the clones send data packets at odd intervals to LOGGER. It is up to LOGGER to queue up the requests sent to it and execute each request when it can. I think that is generally where the issue is occuring, but I can't figure out how to isolate.

If I go through the trouble to decouple the code for an example Im pretyu sure it will work just fine, thats whats driving me nuts.

Only reasons I can imagine to see this

1) File Refs created in a dynamic vi (One that has no link to static MAIN); ex; LOGGER, can go invalid for unknown reasons <-ugly

2) Re-entrant VIs messaging to a dymamic vi, (such as LOGGER ) can somehow cause a file ref created within LOGGER to be dropped. <-ugly

3) A Memory cache issue? <ugly but perhaps the most feasible explanation.

That beer is getting colder in the fridge...

QUOTE(orko @ Dec 4 2007, 07:19 PM)

Herin lies the problem. The loop is not keeping the file reference between iterations. You just don't know yet where it is being lost

Thanks orko, I appreciate the thoughts anyway. Ill try to get more info about this.

I have to wait until I can access the rig again for further development (troubleshooting) next week.

Yeah I am using a number of reentrant clone VIs. They are the producer points for the command to

go ahead and execute the diagram above which is a frame of a QSM very much like this one.

http://expressionflow.com/2007/10/01/labvi...e-architecture/

The QSM wrapped around this (example) code segment above however is static.

I probed the ref num and it is just a number so there is no way to tell if it is valid since sometimes it works and sometimes it shows an error

when asking it for the current file position.

I have seen this kind of thing before (and felt stupid before) where during a probe the ref appears to be valid but it actually is not, especially with Queue refs, DAQ refs etc..

A free beer to the best answer

I have trouble with writing (appending) to text file in a QSM that is in an "occurence mode" of operation whereby the queue waits for outside engueue to go ahead and do a task. The task is simply to write to a file a line of text. (see above)

This circuit is contained within a Queues state machine loop. The loop keeps the file reference between iterations. Only an outside event triggers the loop iteration. (not shown)

Outside producers give the queue its go ahead and data is sent along etc...

WHat I am seeing in the logging function shown here (this is a subVI ) are multiple errors (Error 1)
Somehow Labview is not noticing that the reference is valid or it is invalidating the reference., hence the (silly) work around just to get something
positive going. Ive seen this kind of thing before my calling VI (outter loop) is not idle this time.


Q is Should I just let the outter QSM loop to keep it alive and would that work?

What is the rule concerning a loop controlled by queue waiting for an event? Does the VI get flagged as idle and is that why the ref appears to be dropped or is it more likely a cache issue? All i know for sure is is the recycled ref is closing OR generating Error1 just for fun..

The example above works when wrapped in a simple loop but not in my QSM loop that is waiting on an occurence.
Anyone know why?



Thank You

QUOTE(eaolson @ Nov 21 2007, 04:23 PM)

I was brushing up on my events and discovered this interesting crash using two of the NI-provided examples:

1. Open <labview>\examples\general\dynamicevents.llb\Dynamically Monitor VI's.vi.

2. Run the VI.

3. Open <labview>\examples\general\dynamicevents.llb\Dynamically Register for Events.vi

4. Run the VI.

5. Do not stop the "Dynamically Register" VI. Instead, close it by clicking the "X" in the upper right corner of the window. A dialog window will pop up asking "Do you really want to close 'Dynamically Register for Events VI'?". Click "Yup".

6. Stop the Dynamically Monitor VI by either using the Stop button on the front panel or the Abort Execution button.

7. LabVIEW will crash with a "LabVIEW.exe has generated errors and will be closed by Windows" window.

I've observed this on 8.20 running under Windows 2000 and XP. Can anyone verify that it does happen on 8.5? I haven't really figured out where it happening, but it's probably at either a property node or a Register for Events node.

I also reported it to NI, but they don't seem to consider it a bug. It's not fair, but I'm not sure I agree. An attempt to access a VI not in memory seems to me should fail out with an error, not a crash to the desktop.

IM no architect but

I had discovered this exact behaviour a few months ago when I was trying to learn how to use events beyond the simple UI stuff.

Got feedback here that it was a crash on 8 and 8.2. Sorry I never tried to get at the bottom of it but

Is this not an NI example?

What what I can tell you that event structures can be dangerous creatures

if not handled properly. I have learned the hard way and I will not use them (or notifiers) for anything fancy.

As to NI thinking it is not a bug I kind of wonder if they might be a little overwhelmed

at the moment.

QUOTE(eaolson @ Nov 21 2007, 04:23 PM)

I was brushing up on my events and discovered this interesting crash using two of the NI-provided examples:

1. Open <labview>\examples\general\dynamicevents.llb\Dynamically Monitor VI's.vi.

2. Run the VI.

3. Open <labview>\examples\general\dynamicevents.llb\Dynamically Register for Events.vi

4. Run the VI.

5. Do not stop the "Dynamically Register" VI. Instead, close it by clicking the "X" in the upper right corner of the window. A dialog window will pop up asking "Do you really want to close 'Dynamically Register for Events VI'?". Click "Yup".

6. Stop the Dynamically Monitor VI by either using the Stop button on the front panel or the Abort Execution button.

7. LabVIEW will crash with a "LabVIEW.exe has generated errors and will be closed by Windows" window.

I've observed this on 8.20 running under Windows 2000 and XP. Can anyone verify that it does happen on 8.5? I haven't really figured out where it happening, but it's probably at either a property node or a Register for Events node.

I also reported it to NI, but they don't seem to consider it a bug. It's not fair, but I'm not sure I agree. An attempt to access a VI not in memory seems to me should fail out with an error, not a crash to the desktop.

IM no architect but

I had discovered this exact behaviour a few months ago when I was trying to learn how to use events beyond the simple UI stuff.

Got feedback here that it was a crash on 8 and 8.2. Sorry I never tried to get at the bottom of it but

Is this not an NI example?

What what I can tell you that event structures can be dangerous creatures

if not handled properly. I have learned the hard way and I will not use them (or notifiers) for anything fancy.

As to NI thinking it is not a bug I kind of wonder if they might be a little overwhelmed

at the moment.

QUOTE(torekp @ Nov 7 2007, 02:32 AM)

Here's my main tricks along those lines - I hope this helps. Create a folder "tests" within your user.lib and unzip the contents of the zip into there, thereby creating a sub-folder within tests which holds the VIs and project. The VI "1D_dbl_data_changes" is just a random VI that I'm calling dynamically. A built executable is included. LV 8.2

http://lavag.org/old_files/monthly_11_2007/post-4616-1194402653.png' target="_blank">

Hey thanks Torekp I appreciate the quick response.

This example looks detailed enough to be close to what I am looking for although Ill need a few leisurely

hours to figure it out completly.

It looks at first glance that you are using Labview default directory as the anchor for all other locations.

I know there is a simple way to change path variable in INI file for Labview but have not yet attempted it.

Still waiting on that wiki to get wikified;)

Thank You

Hi guys

I tried LAVA search and found some good stuff but would also like very much to find some (decent) examples of how to use relative paths properly

so that the APP can resolve where things are in either Edit or Executable mode.

Thank You.

QUOTE(Vladimir Drzik @ Oct 26 2007, 06:57 AM)

Hi guys

Windows has a standard shortcut for text editation. If you press Ctrl+Arrow, you skip a whole word in the respective direction. It would be very useful for me to have this shortcut for editing text in LV, too. Especially for label and caption edits.

Vladimir

I may be wrong about this but I have seen this work and then not work when editing strings and such.

I think it works until you encounter a LF or until the label resizes. Again not sure but I have seen it not work sometimes.

Never studied it further because it is

just a minor annoyance.

Nice short story.

Nothing like revenge on a rude cell phone user

PS

I noticed that filmmaker actually had a rolling track for the first scene.

QUOTE(Thang Nguyen @ Sep 12 2007, 06:31 PM)

@Ben: Could you tell me what is the format into string VI? I don't know about this . I have to you the property strings[] and array indicator to get the string of an enum.

@All: You guys are experts in LabVIEW, so if you have time, it's really helpful if you can list down these tricks in VI. I really want to learn more about these stuffs. It's hot :thumbup: .

Thang Nguyen

You are making a good point Nguyen.

I am always amazed at how little I know (the holes in my knowledge) and I been reading LabVIEW user manuals for years.

It would be really nice to see some of the little tricks of the trade explained here. Trust me they are not known by everyone.

Might save someone a lot of grief.

QUOTE(TG @ Oct 14 2007, 08:38 PM)

I was very happy when I >> thought << it had been resolved.

Download File:post-2402-1192819271.zip

8.2.1

In fact, the above example may or may not work on your machine (as I found at work when I tried to use it again.)

So instead, I used a singleton queue to make the strictly typed event reference available to the clone and this appears to be foolproof for now.

Download File:post-2402-1192819397.zip

So I guess that fixes the problem. But I need to know for next time if missing anything.

Why does a named event not function like a named queue? It appears that the event wire or a reference to it must be transferred to the clone in order that it can register for the event reliably. Again this is my best guess I am reaching here...

and yet... Example 1 worked reliably (still does here at home)

Q I keep pondering why did it work so reliably at my home rig only to not work at all on my work PC.

Anyone want to comment? Thanks

Bumping.. Thx