TG

Ok forgive me as sometimes a nerve gets pinched.

I wrote this long winded thesis on why I am unhappy with NI's QC today then I realized things are

best left unsaid.

QUOTE(Jim Kring @ Oct 17 2007, 09:54 PM)

Lately, it seems that the LabVIEW upgrade process is just trading problems. Get some new features and bugs fixed, but have deal with the new bugs. Granted, the new features are really nice,...

I wonder how my eventual transition to 8.5 will be.

I have a fairly large "in house" project going in 8.2.1 and don't really have it fully sorted out yet in terms of Vi locations, etc.

I took a stab at loading it into LV85 and saw a lot of dialogs but did not have time to drill into it so I just closed it out for now.

Wondering if there is going to be an 8.5.1 patch coming..

QUOTE(Michael_Aivaliotis @ Oct 13 2007, 11:31 PM)

I’ve always wondered who all these people are that visit the LAVA Forums but never post. There’s about 7000 registered members but only a handful post regularly. I know many of you subscribe via RSS and never visit the site. Now’s your time to shine, lurkers! Just pop a comment here, no reason to be shy. Let us know who you are, where you’re from, what you do, whatever. It will help you get to know some of the other lurkers. . For those of you still scratching your heads as to what a lurker is, a lurker is a person that decides to stay shy in either a chat room, a forum or a blog, by not contributing their comments and electing to just watch the babble ensue in front of them. Now that made no sense, but I’m sure you got it.http://avalonstar.com/2006/01/11/lurkers-speak-to-me/' target="_blank">

And yes, if you are one of those regulars you can comment too.

Im not a pure lurker but since I have developed the worst LabVIEW habits over many years (since version 1.0 on the Macintosh)

I can tell you I am definately out of my element here and struggling with the right way to do things, not being a software engineer by study

and having never made more than one or two executables for remote use I find this forum scary, entertaining, humiliating and mostly educational.

You guys are the geek squad *10 :worship:

I hate being sick.

QUOTE(Aristos Queue @ Oct 14 2007, 07:19 PM)

What you *can* do with LVClasses is this: Get rid of your case structure entirely. Replace it with a dynamic dispatch subVI "DoSomething.vi" on class Parent. Then load a new child class into memory for each string you would've wanted to dynamically instantiate. Each child class would know how to interpret zero for its own uses. This gets rid of the error-prone string compare, keeps everything type safe, and allows you to expand handled cases dynamically.

I'd give anything to see a (reasonably) simple example of this.

PS: This is not a challenge

QUOTE(Aristos Queue @ Aug 1 2007, 03:00 PM)

At the risk of confusing everyone, I do have many functional globals that are reentrant. That's how I can create separate databases -- the core VI is reentrant and contains the uninitalized shift registers. Then I create a series of wrapper VIs that are not reentrant that will be my entry points. Each wrapper VI is thus a single shift register database.

QUOTE(TG @ Oct 14 2007, 10:25 PM)

QUOTE

QUOTE

Just to let you guys know this is good stuff from where Im sitting..

I'm gonna use that technique for myself. These little tricks are quite impressive. I guess it would be great to somehow catagorize all this stuff

in Wiki but how?

Thanks anyway

Kudos LAVA!

QUOTE(TG @ Oct 12 2007, 03:19 AM)

Hi guys,

Concerning an excellent events messaging example from Mike awhile ago. blah blah...

I cant believe I was able to fix this ! It seems to be stable too, hallaluahh!

Share in my happiness and if you are really good explain me what I did to fix since I have no clear idea

PS: Sorry its in 8.2.1 I do not know if it would work with 8.0 since it uses clones.

It definately does not in 7.1

Hi guys,

Concerning an excellent events messaging example from Mike awhile ago. Here is a modified version renamed

Download File:post-2402-1192158504.llb

I fiddled with Mikes original example to launch vi:(clones) from the main VI.

This works fine. Anytime a clone is launched from Main the clone can communicate back to change the station ID or the command in Main.

No sweat there.

Now if Main wants to kill all the clones after creating them it appears as if

it is able to do so. (Pressing Kill Clones button)

However, If Main creates a second set of clones the Kill event is lost on them

(even though they can still fire events back as before.)

Another clue is that if two clones are created and Dynamic_VI.vi:1 (clone)

is closed by the user (while Main is running)

but vi:2 (clone) is kept open the kill event from Main

is also lost as in Main cannot close vi:2 (clone)

I gotta admit some of this event stuff really breaks my head.

How could this example be modified so that Main can kill any clones it creates at any time?

Is it (hopefully) a simple matter?

QUOTE(Tomi Maila @ Sep 30 2007, 10:03 PM)

True. But I would recommend normally not to pass event registration refnums around but instead pass user events around and register the events just before the execution of the actual event structure loop. This way you don't accidentally use the same event registration refnum multiple times. Don't forget to unregister the events so that they don't consume system resources when you don't use them anymore.

So the program flow I recommend would be something like:

Master: Create user event

Master: Start Receiver process

Master: Pass user event reference to Receiver for example using a named queue

Receiver: Register user event

Receiver: Send initialization status to Master (usually OK)

Master: Start Sender process

Master: Pass user event reference to Sender for example using a named queue

Sender: Send initialization status to Master (usually OK)

Sender: Generate user event

Receiver: Catch user event using event structure

Receiver: Before exiting unregister user event and exit

Master: Before exiting, destroy user event

And this program flow would allow you to have as many senders and as many receivers as you would like for the single user event reference. Then all the receivers would listen messages from all the senders. All the receivers would handle all the messages.

Excellent advice. Really appreciated.

QUOTE(Tomi Maila @ Sep 30 2007, 06:52 AM)

I use both queues and events for notifications. I've not encountered any problems with either of them

Thats encouraging!

QUOTE(Tomi Maila @ Sep 30 2007, 06:52 AM)

I think I understand.

Let me ask this quick Q : True or false?

[ When launching multiple re-entrant *instances* (lets call em Slaves) it is possible to use event registration for signaling a single *instance* in the group

as long as the registration refnum sent (from the Master) to each *instance* is unique. ]

QUOTE(Tomi Maila @ Sep 30 2007, 06:52 AM)

That is the best help answer for my plight. Thanks Tomi! Your answers are always the best ones.

PS: My bad for taking a chance with notifiers again. They seem to work so well at first.. and then.. missed notifications

out of nowhere - no easy way to track down the cause... I always think it is somehow my own mistake. Now I know better.

Your original example is a valid and reasonable use case and it simply does not work reliably with re-entrant vi's .

I won't use them anymore for fancy stuff. I don't care what the experts say.

TG

Thanks Tomi

I'm using 8.2.1

Let me look this link over.

I appreciate the quick response.

Edit1: So far I only looked at your excellent first example and in 8.21 It has problems if you make more than 5 or 6 iterations.

This seems to be almost if not exactly what I am experiencing. Your response has value to me thanks. At the very least least it seems to

illustrate a real problem with these creatures since your usage seems to be quite reasonable.

Edit2: Oh boy, As I read further and see where the discussion is heading I am appalled at the complexity of this issue.

This is going to take a month of Sundays to figure out what you guys are talking about in that thread.

Hi guys,

Im trying to get to the bottom of this notifier mystery I am encountering

to learn the tricks of the trade with them and (also) event structures which I view as being earily similar to notifiers.

Ive made an investment in using them for a messaging mechanism in my project

It involves re-entrant clone VIs launched with Vi server invoke nodes. It is not too easy to make an example.

A few Questions come to mind, most of them may be not specific enough

because Im not really super keen on notifiers yet. How they relate to re-entrant vis launched with Vi server

is new to me so here goes..

Is it a sensible 'use case' to send messages with notifiers

using a one way downstream channel 'cmd' and then using another notifier for

the upstream channel 'ack' for replies.

WHen creating a notifier reference and carting it around various VIs does the notifier reference sometimes go invalid?

What would be the condition for that happening (if any)?

If the VI that initialized the notifier (originally) was not idlie but sitting in an event structure timing out in a polling loop

and a notifier reference was 'obtained by name' in another re-entrant vi for messaging could the

Notifier reference (on a wire) in the original vi possible go idle? Is there any condition that could kill that

notifier on the wire in the original Vi?

Can notifiers and event polling run in parallel ok?

Example

In a section of code

A notifier 'A' awaits a message while a lower loop polls in parallel.

The lower loop will (before exiting) send a nofification to "A" letting it continue.

Notifier "A" can recieve a message from the lower loop or from an external section of code (another re-entrant Vi )

WHen notifier "A" triggers (gets msg) it enables code to shut down the lower loop should it still be executing (then other things)

Is it ok to do this when both vis are re-entrant?

(I'll try to make an example if it is not clear.)

I've noticed notifiers and event structures can sometimes give unpredictabe results even when the rules of use are (apparently)

being followed. For example, when connecting to a notifier input terminal on a subVI (a typedef'd notifier ref) in some cases there

is a coercion. I can create a typedef constant from the vi terminal then convert it to a control then conect it to the (same)

terminal and a coersion dot appears. I cannot explain this.

Another way to explain strange behavior is a usage where two re-entrant Vis are messaging in a master slave setup where Vi 'A' is sending cmds and the vi 'B' is setup to acknowledge the commands.

vi 'A' sends a notification on 'msg' channel to vi 'B'

vi 'B' replies with its own notification on 'ack' channel back to vi "A".

Each Vi obtains the proper notification "by name" 'msg' and 'ack' before then exchange messages.

Normally one would expect this to work flawlessly, however sometimes it doesn't and it drives me nuts why it isn't more stable.

(no significant change in code just stops working for unknown reasons) it is almosyt as if LabVIEW is losing track of things which i know is not the case

because it is far more likely to be me!

I wish I could be more specific but it is troubling me that I

cannot even pin down what is happening. :headbang:

How often must LabVIEW be restarted when developing and testing notification messaging with re-entrant vi's.

During development is it possible that one or two (non graceful)

aborts could trigger such odd behaviour with notifiers especially?

I do not see unstable behavior with queues, semaphores or any of the other functions and I assume we all hit the abort button during

development phase of untested code. I only see weird behavior with notifiers and event structures.

Anyway I was running into strange timeouts that i dont understand today and would appreciate

any second opinions.

Thank You

QUOTE(NormKirchner @ Aug 22 2007, 03:12 PM)

I think that he's looking for some more information on how to use the dynamic event registration also.

http://lavag.org/old_files/monthly_08_2007/post-208-1187795563.jpg' target="_blank">

Eugen Thats a nice simple example thx for posting it.

Hi Norm

I am just trying to get the mechanism for (hardware or visa) events ironed out a little more.

Could I ask you for a little more detail about what is happening in the example (pic) you posted using the event registration example?

PS: I guess serial interrupts would be supported in the same way or no? Could this technique be used to catch

incoming characters without constant polling of a serial device?

Thank You

QUOTE(Eugen Graf @ Sep 13 2007, 07:10 PM)

You are right, but I am not my own BOSS. I am an sole LV engineer in our company.

Eugen

I feel your pain Eugen.

No one here (where I work) really appreciates the skill it takes to use LabVIEW effectively.

QUOTE(ooth @ Sep 14 2007, 03:54 PM)

If you pass a control's reference to a subVI so you can edit its properties

1) should you close that reference in the subVI?

2) pass that reference back out of the subVI and close it in the main VI (even if you don't need to access it anymore)?

3) don't even worry about closing it because when the main VI exits the reference will be taken care of?

I know it's good practice to close references I just don't know where to close it or if I have to?

I guess the main thing is to close it before your APP exits.

Where it is done is up to you and depends on how you are using the resource.

Closing a ref releases resources(memory) so if memory usage is critical to your app then close it as soon as it is not needed.

I would not assume LabVIEW handles the closing for you although it does in some instances such as when the

VI that opened the reference goes idle.

QUOTE(Michael_Aivaliotis @ Sep 8 2007, 03:14 AM)

Everyone, the LAVA Forums will be going through upgrades, fixes, tweaks and a face lift. So please please please be patient as I work through this.

Great work Mike.

I can wait for the "View New Posts" to come back, No worries

QUOTE(Tomi Maila @ Sep 10 2007, 03:11 PM)

Same here... this is the functionality of LAVA I used to use daily.

Im also missing the view new posts feature

Feel kind of lost without it.

QUOTE(Tomi Maila @ Sep 4 2007, 10:25 AM)

When one drags and drops a project item from one project explorer into another project explorer, LabVIEW removes the items from the source project and adds the items to the target project. This is not the behaviour I'd expect. I'd expect LabVIEW to add the same items to the target project without removing the items from the source project. This is how most applications seem to work.

EDIT: According to local NI this is not a bug but a feature. One should use Ctrl + Drag & Drop to accomplish the functionality. I kind of disagree.

I agree with you Tomi.

I wouldnt agree to this being a feature, quite the contrary, since a thing like this can waste much time when

trying to figure out "what the heck just happened!"

Here is one I just recently designed for myself and am using a lot.

It's an extremely powerful yet relatively simple state machine design.

I'll put it into the code repository someday.

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

LV Version 8.2.1

It is based on techniques described in the reference below.

It has a lot of useful features.

1) It uses an elegant technique for dealing with automated systems,

where all attempts must be made to continue execution (if possible) before shutting down an application.

2) It is a LIFO (Last In First Out) Queued type state machine.

Instead of an array of enumerated types or a Queue the machine uses a multi line string of text states.

the new line char "\n" separates states.

This really helps with read-ability, and portability at the possible expense of execution speed and more attention to mispellings, etc.

However, most state machines do not need light speed execution over read-ability so this is

in my opinion not a real problem for a queue size of 50 states or less.

With this framework it is possible to handle errors within the VI or

escalate the error upwards to the caller. The framework provides an elegant mechanism to check if the error was handled correctly.

If the error is corrected the SM will retry the offending state and continue execution

normally (without ever telling you

In automation this means an error can be logged and handled privately to the SM while continuing execution of critical tasks.

ref:LabVIEW Advanced Programming Techniques Second Edition by Rick Bitter, Taqi Mohiuddin and Matt Nawrocki

QUOTE(Mindstormer @ Aug 31 2007, 09:06 AM)

How is it possible to find out at the server side which client pressed a button on a reentrant vi?

thank you

I too am unqualified to chime in but your problem got me thinking.

Is the server launchin the re-entrant Vi's?

Reason I ask is there may be a way to get at the name of the instance if it is set up as a clone.

Maybe that could be used to get at the status of the button. (With Vi server)

QUOTE(Michael_Aivaliotis @ Aug 25 2007, 09:02 PM)

Maybe NI should take an example from this marketing video for Windows 386 as an example of how to promote multicore processing. Be patient, it get freaky towards the middle.

Very enjoyable

Reminds me of those "good old days" when the Soviets were the enemy and LabVIEW was bigger on the Macintosh than on the PC.

QUOTE(Aristos Queue @ Aug 22 2007, 11:16 PM)

If you have comments about the *overall* nature of LabVIEW classes, please post them here. Please don't post feature requests here. I'm interested mostly in getting a feel for adoption rates. I'd like to know how secure everyone feels doing professional development with LabVIEW classes. If there is a particular sticking point (other than you haven't upgraded at all yet) that is keeping you from developing with classes, I'd be interested in that.

Im sorry to say I tried going head first into LVOOP (while training in OOP ) at its release 8.2 stage which was (in hindsight) bad combination luck timing

whatever..

I spent good part of 3 months trying to sort it out (at my own risk) and concluded finally that I could only use LVOOP for protecting

data in an elegant way. That is currently all the functionality I can manage (with any trust) and probably all I will attempt for the time being.

I do have one data structure I am very proud of designing. I wanted to do much more with that one but it is done now.

I am back to using Evdevo by ref objects and building many functioning classes in that toolkit. Main reason for switching.

1) It was stable as a rock and 2) all the crashing class breaking and VI breaking episodes ceased and 3)My work (value) began to increase linearly.

4) It can be converted to executable with no worries.

Like a lot of us here I cannot do much experimenting in LabVIEW. That is why this forum is so valuable to me. Nevertheless I really do think

native Classes are the way to go in LV. I too look forward to using LVCLasses when they are ready.

QUOTE(Gary Rubin @ Aug 20 2007, 06:40 PM)

I've heard it said that left-handed people tend to be more analytical. Based on that, I wonder how the LAVA community's left-handedness compares to that of the general population. According to the Wikipedia entry on handedness (linked in the original post), 8-15% of the population is left-handed.

I think the right side of my brain might be dead or at the very least incapable.

QUOTE(Harish @ Aug 20 2007, 06:27 AM)

Hi All,

I have joined this forum today.

I have been working with NI LabVIEW for quite some time now (more than 3.5 yrs).

I am here to learn more about object oriented techniques in LabVIEW.

Also i have interest in exploring design techniques for large application!

Hope that this forum provides an interactive platform!

Harish Kumar

You found good forum

Look at GOOP subforum for object oriented discussions. Many interesting topics and good examples for learning.

QUOTE(MK07 @ Jul 26 2007, 08:44 AM)

Hi Friends,

i am mk working as a software engineer...i am new to this forum and labview also..and i am really glad to meet you all and have a pleasure to share my knowledge with you all..

with regards,

mk

Welcome MK07

This is a nice place to hang out if you are a software engineer. (Look forward to hearing all views on LabVIEW especially those of the experts)

LabVIEW is really pretty cool language and most the guys here are hardcore LV architects er ..lovers.