TG

Whats the simplest way to detect a possible memory leak in LabVIEW?

thx

QUOTE (jlokanis @ Jan 6 2009, 10:15 PM)

I'm just wondering what the 'best practices' approach is to passing references and if I am going in the right direction.

Thanks for your ideas and opinions...

-John

My 2c:

I am more inclined to create queues by name at the top then obtain the ref by name in the lower VI's delete each when done.

This is especially needed (I believe) when the VI is run using RUN method and waitfin set false.

I never create queues without names unless it is created and discarded inside the same VI.

ALthough it has not happened to me lately I do remember seeing behavior like you descrivbe in some of your earlier posts.

It seems to work fine as long as the top VI stays active.

As far as best practices I am not sure if it is or not.

end my 2c

QUOTE (NI Guy @ Jan 5 2009, 10:32 PM)

- policies and practices around support, upgrading, documentation, bug fixing, etc...

Mind if I enter a comment?

QUOTE (Ton @ Jan 6 2009, 06:52 AM)

First fix:

Place any dynamically called VI inside a Strict VI reference, this will force the builder to include the dynamic VIs inside the executable.

One question, were you able to build the executable inside 8.2?

Ton

Sorry, was away for a day or two. Actually I never tried the full executable in 8.2 but I do remember having better luck with portions of it.

I've read all the responses (Thx btw, u guys always impress with the level of expertise ) and I am thinking for now at least I should look mainly into the GIT toolkit as the most likely cause of severe problems as in not even seeing error dialogs yet.

I would guess dynamically called VI's without strict references would be the second suspect.

The divide and conquer approach is probably where I'll start. I am used to getting away with LV 7.1 where everything at least gave an error. It was tedious but at least there was an endpoint. We really do not need to make executables out of these programs for long time yet so I have option of looking into it a little at a time.

Ive got a number of GIT 3.05 classes made and it makes sense to me to start there, maybe try to remove dependencies

and encapsulate them a little better and try to make some executables out of them piecemeal first.

Boy I wish I had been keeping up with this when developing these two beasts. Hehe.

Might take awhile But I'll report my progress as it goes.

Thx again :beer:

Hi Guys

Paddling with my head above "lurksville" to ask of the wise ones

I have two relatively large and complex LabVIEW source code applications that we use internally with equips and sensors etc.

I just upgraded both of these applications to 8.5.1 from 8.2.1. ( and that was actually quite a ride but at least 8.5.1 seems more stable in certain areas.)

Both applications work in the LabVIEW environment however, When I try to use the build feature to get a preview, distribution or a build

I am sumarily (and rather quickly) booted out to windows on both apps, which are on different machines.

One app uses labVIEW classes the other does not yet they both crash so that notion is out.

Both apps have large number of VI's (800 to 1000+ (never counted))

Both apps were upgraded from 8.2.1 to 8.5.1 successfully, (howbeit not easily by any stretch of the imagination)

In both apps a number of VI calls are dynamic and many calls create independent instances to allow other processing dataflow(s) to continue yada yada

Both apps use dynamically called VI's, GOOP inheritance toolkit VIs , VISA and Field point resources however I am not thinking these in themselves pose any problems

that would cause the builder to crash. I just don't fully get it.

I'll admit building exe's is not something I do often yet I would have expected at least some error messages from the builder utility. Instead I cannot get a preview at all on either app.

I was wondering if anyone has

experience crashing into this proverbial wall with 8.5.1.

ANY clues would be appreciated :beer:

Thanks in advance.

QUOTE (brian @ Nov 21 2008, 11:46 PM)

Fixed in a future version of LabVIEW whose existence I can neither confirm nor deny.

The problem was the "reset to default value" caused by the unwired case structure's output in one case. The reset to default forgot to deallocate whatever was in the waveform before (the array and variant).

Wiring in an empty array of waveform constant doesn't relieve the problem; it still looks like a reset to default. However, if you allocate the array to contain one waveform (even if that waveform is empty), we stop leaking memory.

Brian

Oh boy good to know this and thanks for reporting!. Is it limited to waveform types only? (hopefully)

QUOTE (normandinf @ Nov 21 2008, 07:37 PM)

I've got a theoretical question on GOOP Classes.

I'm usually defining my object attributes for anything that could be different from one object to the other (ID, init parameters, position, speed, etc.) and, as I understand it, the class attributes are for everything that is class invariant (let's say supply voltage, material, dimensions, etc.). But I usually never use the class attributes and put all the fixed parameters in the object attributes, initialize them once with "Object_Create" and never change them in the course of my program. I think it's not optimal design but it works rather simply and it's more readable for colleagues less familiar with OOP.

I would like to know if it is good practice to simply ignore the class attributes? My concern is as to what would happen if in the future I were to create a sister-class and make these two classes inherit from a parent. Those sister classes will have different class attributes... How well does it scale up? Will I run into a wall one way or the other? Any comments?

thanks,

Francois.

I can only share my experience with class attributes.

I have learned to ignore them in the few limited GOOP designs I have attempted, however there must most assuredly be uses for them..

To me cLass attributes are those that do not vary and are common to the class, hence limited usage since everything that is designed will ultimately vary to some degree.

The concept "find what varies and encapsulate it" is not served well by class attributes (at least to me they are not).

Anyway, Ive never been able to use them much..

QUOTE (Dan DeFriese @ Nov 21 2008, 05:51 AM)

Yes, this works fine. I put together a little example.

Dan Thanks for showing me how its done.

I thought it would not work but you prove it does and it seems to work just fine.

Very simple too.

I especially like the remote stop shutting down the subVI from the caller.

Question for anyone who might remember.

On the topic of subpanels

Can a subpanel work normally if it has a static event handler in it and the events

generated within the subVI are only triggered by using property value(signaling) within the subvi itself not by user interface clicking of buttons?

said another way..

Will ValueChange events signaled within the subVi (by using Value(signaling) property only )

work normally if the subvi is placed within a subpanel?

Or rather, are all events going to be relayed to the calling VI?

I think I know the answer but just want to see if anyone tried this out and perhaps may know some useful trickery here?

Thanks in advance

Question for anyone who might remember.

On the topic of subpanels

Can a subpanel work normally if it has a static event handler in it and the events

generated within the subVI are only triggered by using property value(signaling) within the subvi itself not by user interface clicking of buttons?

said another way..

Will ValueChange events signaled within the subVi (by using Value(signaling) property only )

work normally if the subvi is placed within a subpanel?

Or rather, are all events going to be relayed to the calling VI?

I think I know the answer but just want to see if anyone tried this out and perhaps may know some useful trickery here?

Thanks in advance

QUOTE (jdunham @ Nov 12 2008, 01:10 AM)

Well I think it's a lame way for VISA to give you that information. It would be better to have a boolean output for "TermChar found?", but that's what you get with an API developed by an industry committee. I guess it's fine if you use RS-232 just like GPIB (which is the intention behind VISA) but if you use RS-232 for other devices, you frequently don't get termination characters, and you have to jump through some hoops to get that working with VISA (NI: If you don't believe me just look at the forum topics on this).

I agree with that.

I have never been able to get away with using termination character on any serial instrument I had to make a driver and having it be 100% reliable

and I have done plenty of them on all kinds of instruments, very few of which give a short consistant response that you can count on.

QUOTE (jdunham @ Oct 9 2008, 07:13 AM)

Well NI can tell me until they are blue in the face that VISA is awesome, but I will keep my opinions to myself.

Yes, it seems like asynchronous should help.

No, in fact it doesn't. Putting the calls in separate LabVIEW execution systems (threads) doesn't help either.

But, yes, you can get what you want.

The trick is (courtesy of NI's Dan Mondrik, who at least tries to atone for NI's sins by helping us)...

You have to open separate VISA references to your serial port, one for the write thread and one for the read thread. That's the only non-stupid way to keep them from blocking each other while timing out (the stupid way is to poll each side in a really fast loop with a short timeout).

http://lavag.org/old_files/monthly_10_2008/post-1764-1223532516.png' target="_blank">

I did suggest to Dan that this useful nugget be put on the NI Developers' Zone, but a quick search turns up nothing.

Let me know if it works for you.

Jdunham

I work with Rs232 and I had no idea this would work. Thanks for the important tip and the illustration regarding duplicate session !

:worship:

QUOTE (Daklu @ Oct 8 2008, 06:17 AM)

Grrrr... If Jim Trouchard were here right now I'd poke his eyes out and feed them to my cat. WHY DO I HAVE TO SAVE MY PROJECT TO SCC EVERY FRIGGIN' 5 MINUTES TO PROTECT MYSELF AGAINST LABVIEW CRASHES!?

Some days I spend more time fixing problems from crashes than working on code. It certainly doesn't help my efforts to promote Labview when I have to tell my manager I spent the entire day trying to recover and rebuild code I had already finished... again.

The latest crash left me with the error, "This class is missing one or more member vis." Yeah? Thanks for noticing, but how about if you tell me something useful, like WHAT THE NAME OF THE MISSING VI IS! Telling me a class of 150+ vis is missing one vi is enough to make me... want to feed JT's eyes to my cat.

Words simply cannot express how &%*()# mad I am right now. But since I can't start yelling and throwing things this is about as good as I can do right now. (And it's woefully inadequate.)

I wonder if you are using version 8.20. Seems very familier territoy.

If so Gotta fix it 8.2.1 at the very least.

QUOTE (normandinf @ Oct 10 2008, 09:54 PM)

If you launch your VI with a subVI call, then use Ben's solution.

If you use Invoke Node, you can transfer the reference owner to the subvi by setting AutoDispose Ref = TRUE.

http://lavag.org/old_files/monthly_10_2008/post-10515-1223671959.png' target="_blank">

Thanks Norm. that just cleared up something I was trying to get my head around regarding this topic.

Good answer.

QUOTE (Cat @ Jul 14 2008, 08:48 PM)

Hi all,

I recently upgraded to LV 8.5.1, pretty much straight from 7.1. Especially right after startup it seemed to take longer to do things like access items on the menu bar, move a vi fp/bd, make a wire appear -- simple stuff. This often also happened when I opened up a new vi. It looks like LV hangs, I click on a window, and get a "Not responding" message in the title bar. This lasts 5 or 10 seconds, then everything is fine. For awhile.

Cat

Same thing here. I hope you find the ultimate cause.

I been just living with it since I have no clue how to find something that would cause LV to report "Not responding"

It does seem to settle down after awhile. (my guess) . I always thought it was because of the relatively large number of VI's in the project but after reading some of the replies maybe not.

PS I am using 8.2.1 on this project.

QUOTE (crelf @ Jun 22 2008, 11:11 PM)

I don't think he could see the forrest for the trees

I remember when LV was only on Mac I tried to explain data flow to my Supervisor and he was amazed that I could figure out

the execution simply by looking at the connections of the wires.

To this day they still think LV is about electrical signals traveling down wires.

I guess in a way they are right.

QUOTE (Michael_Aivaliotis @ Jun 20 2008, 09:40 PM)

Has anyone been through one of these yet?

Not yet. At least not in Newark International Airport.

Looks creepy though.

I don't believe the image is erased immediately as they claim. No one ever deletes anything these days.

QUOTE (hooovahh @ Jun 14 2007, 02:29 PM)

I have never discovered a programming language that can do what I need it to do, and be as quick, and easy to use as LabVIEW. No language is perfect, but for me and what I need from a programming language, LabVIEW is the only choice.

And when ever any one questions LabVIEW's abilities, I always ask them to write a Hello World program, in LabVIEW it takes me less than 15 seconds to create and run a hello world program. Some languages would take longer than 15 seconds just to compile it. Also it's troubleshooting abilities are amazing. I learned to program with LabVIEW, then when I went to Java I had a huge difficulty in finding where problems were. With LabVIEW just highlight execution and you can see exactly what is happening.

For me in my little world LV debugging is excellent but I have always been impressed with Visual Basics ability to trace through execution flow and change code >while its running!<. I aint seen nothing since that impressed me quite like that (When I worked with it) although LV is still very excellent in debugging and I would (am) definately use LV over VB.

my 2c ;

QUOTE (hma @ Apr 17 2008, 11:12 AM)

Well I added 100msec delays after each VISA vi, even after the Flush buffer VI it was necessary. Now all is working.

Thank you all!

Hugo

Most devices return a End Of Transmission (EOT) or similar characyter to inform the caller that the data is sent out.

Its usually a CR (ascii 13) but sometimes it can be a combo of several chars.

I usually tru to read in a loop until the EOT is found or the required number of characters are received etc.

Makes for more robust code. Ill use my own timeout code rather than rely on VISA's

Ive had many cases where it appears to work nicely until .....

and then it has to be re-visited

thats why I would not put too much reliability in using delays.

IF you are just trying to make a quick hackthen the code shoud be fine.

If you need to design a permanent solution then consider making the receiving end a bit more intelligent.

QUOTE (hepman @ Mar 31 2008, 08:30 PM)

Dear All,

is it somehow possible to find out with code if a terminal in a Sub-Vi Connector pane is connected or not.

Best Regards

Hepman

\

A trick I sometimes use is to set the default to zero or some other number that is useless to the Vi then test for it in the VI.

The assumption is that the caller would never send in a zero or a -99999999.000000001 etc..

I know it isn't perfect but it will get you moving on at least.

Oddly enough

Installing 8.5 on my machine already disables it.

I checked and its set to Manual startup.

QUOTE (Jim Kring @ Mar 11 2008, 11:22 PM)

[status: CAR# 96951]

I'll bet a dollar that someone from NI says that this is not a bug, but it's really bugging me, nonetheless...

That workaround looks familiar to me.

(keep looping until you get what you were expecting)

QUOTE (DiDi @ Mar 10 2008, 09:44 PM)

... Sorry, needed to vent a little, but mainly I am looking for a solution….

Thats OK DiDi. Using LV long enough can do that sometimes. All the features can be perceived as annoying when they are not used or considered.

But I will say this if I may. If you begin having tendonitis issues from all the repetitive clicking. (most of you LV freaks will eventually discover this

depending on your age ) It would help to force yourself to get used to the tool as early as possible.

I resisted for many years only to be forced to consider it, I actually like it better now. Stupid me all these years; that tool was sitting there and all I could think of was " get out of my way stupid little tool."

At least consider slowing down on the lightspeed TAB TAB click drag drop connect way of coding long enough to consider how the tool works. Fast coding with extreme focus can damage your hand and that is a serious issue!

It's your hand... your decision.

QUOTE(Michael_Aivaliotis @ Mar 5 2008, 04:06 AM)

http://lavag.org/old_files/monthly_03_2008/post-2-1204689954.gif' target="_blank">

I love frame 2

That's my ultimate goal from now on ..

QUOTE(crelf @ Mar 4 2008, 03:42 PM)

Here here - to all of those comments. Also, you might want to make the comments section open - at the moment, users have to register to leave a comment, whereas I suggest you change it to accept anyone's comment (and then you can moderate them).

I think Ben is (rightly) not using RSS feed because he wants to get content out to the widest possible audience. That includes professionals who are stuck behind secure firewalls and other such blockades.