TG

Hi Guys, Quick Q for those who are familiar with VISA serial functions. My device sometimes returns error after long periods of perfect operation −1073807253 A framing error occurred during transfer I have seen this error before but never could figure out why it happens randomly after many thousands of perfect exchanges. There is not too much I can do about it regarding the connections or the fact that it is going through a USB- Serial converter (Its on a laptop) I am attempting to deal with this by putting in exception handling code that will catch the error then Close the port then Open it again for a retry of the operation. The Q is once an error like this occurs would an approach like this save me from further issues does anyone have experience doing something similar to recover from a VISA error and will it work long term? Thanks in advance

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

QUOTE (jlokanis @ Jan 6 2009, 10:15 PM) 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) Mind if I enter a comment?

QUOTE (Ton @ Jan 6 2009, 06:52 AM) 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) 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 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) 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) 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) 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) 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) 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) 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 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) 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) 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) 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) \ 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) That workaround looks familiar to me. (keep looping until you get what you were expecting)

QUOTE (DiDi @ Mar 10 2008, 09:44 PM) 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) I love frame 2 That's my ultimate goal from now on ..