Cat

QUOTE (crelf @ Apr 3 2009, 01:20 PM)

If you like that, then you'll love http://forums.lavag.org/LVSpeak-tell-LV-what-to-do-t13687.html' target="_blank">LVSpeak. I figure it would really help those without the dexterity to control a tactile input device.

Good point. Thanks!

QUOTE (Neville D @ Apr 3 2009, 12:42 PM)

Or you could make a nice neat state machine with 3 states: Init, Main, End. It would all fit nicely onto your laptop screen. Seriously, once you get out of the "bad habit" of using sequences, you never go back.

All right! I give! I'm not too old to change my paradigm and think about using a state machine for static states.

I suppose it would be useful if there's a lot of info that needs to be passed between the states/sequences. Often, tho, that's not the case (just starting up instruments or dynamically calling vis, for example), and I really think a sequence might be simpler.

QUOTE (shoneill @ Apr 3 2009, 11:56 AM)

Stacked sequences are bad.

Don't hold back Shane. Tell us what you *really* think.

I'm of the "Guns don't kill people; People kill people." philosophy. Or more to the point: it's really easy to use stacked sequences badly, but that doesn't mean they can't serve a useful purpose.

I haven't seen any actual technical reasons posted not to use stacked sequences (if you have a clue what you're doing). Both stacked sequences and state machines (as well as event structures) hide code, so that's not an issue. I'm also not sure what the point is of using a state machine to replace a sequence when the same states always get executed in the same order. That seems like extra code to do the same thing.

An aside: It suddenly struck me this morning -- of the 20 or so top level vis that are in my Big Project, there's only one vi that I haven't used my usual setup/main/cleanup sequence, keep it all to one screen design. And that's the vi that's blowing up on me after running for 8 hours. Hmm....

QUOTE (PaulG. @ Apr 3 2009, 09:16 AM)

If I need the functionality of a stacked sequence I'll use a queued message handler. A single frame of a sequence structure is quite handy sometimes to ensure data flow, but I can't imagine why anyone would want to use a stacked. They are inflexible and ugly.

Wow, I think I'm having a flashback. I'm pretty sure I was involved in this same conversation 15 years or so ago.

By far my major use of stacked sequences is to put setup code in seq#0, the main program in seq#1, and cleanup code in seq#2.

Along with wiring guidelines I am also anal retentive about making my code all fit on 1 screen (not always easy with my standard 1024x768 laptop screen). Sometimes that becomes problematic -- say for instance I'm initializing all the values in a 50 element structure I'll be using for a state machine. There's no nice way to pass all that into a subvi. So it might get its own sequence. I'd much rather have to click once to move to the next sequence than scroll all over the place to see what comes next.

So there you go. Reason(s) why someone might use a stacked sequence.

My first thought on reading the subject line was, "There's nothing sadder than an injured mouse."

But on a more practical note... Here in the US Fed Gov't there's a big push for only purchasing technology items if they are accessable to people with disabilities. We often have to submit lengthy justifications for an item if it's not compliant with Section 508. LabVIEW does not comply, mostly due to the "keyboard=good, mouse=bad" part of Section 508. You can read all about it at:

http://www.ni.com/pdf/gsa/en/labview-508-a...ance-matrix.pdf

Until 10 minutes ago I didn't even know about Quick Drop. Tools like this can definitely help answer some of the Section 508 issues (and reduce my justification paperwork!)

QUOTE (psychomanu @ Apr 3 2009, 05:54 AM)

I would love to see a shift register in a sequence structure

All the Bad Things about stacked sequence structures aside... philosphically, I agree with this suggestion. I am very anal retentive about inputs coming in on the left side of a subvi and outputs going out the right side. This means when I use a sequence local as an input, I have to drag the wire all the way from the right side of the sequence and make a couple turns before I can put it into a lefthand terminal on a vi (or vice-versa if I've put the sequence local on the left side of the sequence). This definitely contributes to spaghetti looking code. Don't tell anyone, but I have been know to create a local variable for a later sequence instead, just to improve readability. A shift register-like terminal would solve this problem.

If you've made sure all the software and drivers are the same on the 2 computers, then what's left is hardware. Are the 2 computers exactly the same? If not, make sure you're accessing the same serial port on both. If you're using Windows, you can check the COM#s for your serial ports in Device Manager.

Cat

QUOTE (Neville D @ Mar 24 2009, 12:18 PM)

History and jokes aside, I was re-reading all the earlier posts (actually related to your issue..) and it seems to me there are a lot of good ideas there. Forget about the toolkit and the $ your boss spent to get it for you. Use those tried and true methods and I'm sure you can isolate where the memory leak is occuring.

Track the states, log them to file (like I pointed out), use WireShark to track TCP transactions to isolate if the communication is the cause (like someone else pointed out).

Build a "test harness" set of VI's that don't have parts of the code and run that (for example no TCP just reading from file).

Put case structures in suspect VI's run with certain parts of the code de-activated and see if it occurs.

Run test cases on multiple PC's to speed debugging up.

Good old-fashioned debugging is drudgery and fancy tools are all well and good, but basically it is "99% perspiration and 1% inspiration"..

PS I tried using the Real-time trace toolkit a few weeks ago, and I couldn't make head nor tail of the information, running a vision application on a quad-core RT target with multiple timed and regular while loops doing processing and TCP-IP communication via Gig-E. I gave that up and ran a series of tests with and without the timed loops to evaluate.

PS2 Post back with the results of your debugging for more help from the community.

Yes, sir!

Seriously now folks... I understand completely that debugging is drudgery. I've already started trying to divide and conquer. Unfortunately, there are at least 148 vis running when this problem has occurred. Plus the fact that if it's going to happen at all, it takes hours before the memory grab starts happening. And I have to closely monitor it, because if it starts happening, it only takes a minute or two before it chews thru all the memory on the computer. yadda yadda blah blah blah. I.e. it's a pain, but I'm going to have to do it.

I've got a test state where the data just comes from a file. I'll run that overnight tonight and see if it crashes. I'm going to need to automate some user actions to simulate actual use... anyway, I've already started the perspiration part of it. I was just hoping the Execution Trace Toolkit would do what I thought it said it would do and narrow things down a little for me. Oh well.

And if I can ever narrow it down myself to something less than 100 or so vis, I'll post here for more help.

Thanks,

Cat

QUOTE (neBulus @ Mar 24 2009, 12:34 PM)

1) I do have the SSP for LV, but that probably doesn't count. I'll try escalating, if necessary.

2) Thanks for the name. "It's not what you know, it's who you know."

3) Hmm, yes I could try that. I don't have a sense of his technical expertise, but he might have another name to contact.

Yes, maybe if I don't push the toolkit too hard, it can help at some point.

Frankly, right now it's more a matter of not having time to beta test NI's new software. If I had lots of time to play with it, it would be a different matter. But I've been tasked with 3 projects I estimated to take about 3 weeks each, and oh, BTW, I only have 1 month to get them all done. I was hoping the toolkit would help, not add to the load.

Thanks for your help, Ben (and everyone else)! Even if all these responses don't absolutely answer the problem, they get me thinking about different ways to attack it that maybe I haven't tried already.

QUOTE (mesmith @ Mar 23 2009, 02:24 PM)

Probably doesn't make you feel any better, but I was at the local NI Developer Day last week and they demoed the execution trace toolkit. The guy running the demo (who's a pretty sharp LabVIEW guy from the NI home office) managed to crash it and had a hell of a time to get it to do what it was supposed to. He admitted he wasn't very familiar with the tool, but I did get the distinct impression it may not be ready for prime time. When it did work you could see how useful it can be when it does work. NI generally makes good stuff, but they may have jumped the gun on release of this product.

Sorry I can't really help.

Actually, it *does* make me feel better, in a small small way. At least I'm not a complete idiot; it may be the software and not me. Maybe...

QUOTE (neBulus @ Mar 23 2009, 02:25 PM)

Well...... I have never had a lot of luck with NI support. Generally I've thrashed a problem up one side and down the other before I call them, and by that time I've tried everything they can suggest. Then it becomes a bug report...

My favorite hardware experience was with the GPIB/ENet converter box. I think my serial number for that thing was less than 10. I was all excited to put it in my system. After I did, my program that had been taking a few hundred milliseconds to respond to commands started taking many seconds, sometimes minutes. After persistently bugging NI support for several days, they finally came back with the infamous line: "It's just going to be slow." My cow-orkers actually put that on a t-shirt for me when I left that lab.

But, I guess I'll probably have to give NI support another try.

QUOTE (neBulus @ Mar 23 2009, 02:25 PM)

Great story! Now I understand the bump on my head!

QUOTE (neBulus @ Mar 3 2009, 11:46 AM)

The http://sine.ni.com/nips/cds/view/p/lang/en/nid/206790' target="_blank">execution trace toolkit should help to nail that issue.

It works with exe's and should "lift the hood" to let you peek in at what is happening while the memory is being goobled.

So I have my new toy (Desktop Execution Trace Toolkit), and I'm having all sorts of problems running it. The example project they send along is trivial, to say the least. My project has a lot of vis doing a lot of things, and the trace runs out of space (999999 event limit) very quickly. I know there's filtering, but it seems to work only intermittantly, or not at all. You maybe able to run it with executables, but you don't know what vi is generating the event in that mode, so it's not really very helpful. And as far as I can tell in executable mode you can only start it up once (at least when running source code, if your event queue fills up you can stop and start it again). Oh, and I manage to crash it once or twice an hour.

I've searched around the NI site and can't find anything more useful than what little online help the software comes with. I've spent 2 days trying to get it configured for what I need to do and keep running into road blocks. I'm kinda frustrated, because this is the first time my team leader has actually cracked open the wallet to pay for something like this, and if I can't figure out how to use it, it may be the last time. I must admit, I'm expecting a lot from something we just paid $999 for. Maybe I shouldn't be expecting so much...

I know this is a relatively new product, but does anyone out there have experience with it and wouldn't mind answering a few questions?

(As a side note, is there some way I can change this topic to "Desktop Execution Trace Toolkit" or something else more pertinent?)

QUOTE (mesmith @ Mar 20 2009, 11:37 AM)

Closing the front panel won't stop a VI that's been loaded dynamically - you can close and then re-open the panel and the VI will still be running. Closing all refs will. As long as the VI is running some sort of blocking process (loop, wait to dequeue, something) and there's a ref around, it will continue to run. Sounds like your VI panel gets closed but it never actually stops except when all refs go dead, so you may want to look at how you command the VI to actually stop.

You are, unfortunately, right. :-) I just rechecked the loops in the vi and found one that wasn't getting stopped correctly on exit. I didn't notice it when it was running normally; the vi would just stop after the front panel and the reference were closed. That explains why it kept running with another reference open. Thanks!

QUOTE (djolivet @ Mar 20 2009, 11:43 AM)

Between learning more about references, and finding my programming boo-boo, this has been very educational. Thanks for your help!

QUOTE (djolivet @ Mar 20 2009, 10:35 AM)

The rule is that a VI will be unloaded from memory when its front panel is not visible and no references to it are open.

When you run your code WITHOUT the Big Top open and the VI that opened the dynamic VI closes its reference, there is no longer any references to the dynamic VI, so LabVIEW unloads the VI from memery (essentially aborting it)

When you run your code WITH Big Top open and the VI that opened the dynamic VI closes its reference, there is still a reference to the dynamic VI on Big Top's block diagram, therefore the dynamic VI continues executing.

Now I'm really confused.

Maybe the problem is semantics, and I don't understand what you mean by "there is still a reference to the dynamic VI on Big Top's block diagram". Do you mean that just having the icon for the vi on the BD (that never gets run) creates a reference to that vi (as opposed to loading it into memory), and that's the one that's not getting closed??

After I've closed the front panel and exited the dynamic vi, I expect the vi to still be in memory because it's sitting in Big Top. I *don't* expect it to still be running, tho. Maybe I should be using "abort", but that seemed like overkill.

QUOTE (SULLutions @ Mar 20 2009, 06:23 AM)

Looks like things have wandered far from your original question. I can't answer the part about how the NI course is taught, but I have (long ago) had a formal course in Object Oriented Programming in C++ and I also own Conway and Watts "A Software Engineering Approach to LabVIEW". I found the book to be much more helpful in easing me into the OOP world. It doesn't get you all the way there, but it does show you why you should explore OOP and teaches you how small modifications to your current coding practices can give you many of the advantages of OOP.

The book sounded familiar. It just so happens I have it on my bookshelf (I pulled it out and noticed one of my cow-orkers had put a sticky note under the title with "A Graphical Comedy!" written on it. No respect... ). I'll take another look at it. Thanks!

QUOTE (neBulus @ Mar 20 2009, 09:51 AM)

If the dynamic open a ref to itself, it can keep itself open.

I looked all over for other calls before I realized the problem only happened when Big Top was loaded. So no, I don't think it's calling itself.

I have a main program that calls a lot of subvis dynamically. When the user selects a particular function, I open a reference for the corresponding vi and run the vi. When the user exits the vi, I close the front panel and close the reference.

This works fine, except... I have a vi I call "Big Top.vi" that doesn't do anything but hold all those dynamically called vis on its BD, basically for debugging and organizing (this was originally developed in the pre-LVproject days). If I have Big Top open (not running, of course), and I call a vi dynamically with the main program, after the dynamically called vi exits and the reference is closed, the vi is still running. I can't see it (the front panel is closed), but if I open Error List, that vi is in there as "already running". Even after the main program is exited, the dynamically called vi is still running. I've checked, and the reference is indeed closed when it's supposed to be.

This isn't a huge deal, since the code will be really run as an executable. And now that I know what's causing the problem I'll just manually clean everything up when I'm working with the source code, or not open Big Top in the first place.

But my question is what's going on?? I'm assuming it has this issue because the vis aren't normally in memory when they're called, but when Big Top is open they are in memory since they're parked on the BD. But I don't get how this keeps the called vi running even after its reference has been closed. Or is there some other step for *really* closing the vi that I'm missing?

Cat

QUOTE (bsvingen @ Mar 18 2009, 08:25 PM)

I have no idea who you are working for, or what tests are being done. But since this has not popped up before the application was finished, you should be 100% certain of what they actually mean. To "stop" the tests is usually not the same as "aborting" the tests. If it involves powerful/dangerous/(costly and easely breakable) equipment there could be a world of difference between those two concepts.

Yes, I'm looking ahead to the difference between "abort" and "exit". Thanks for the warning!

QUOTE (Michael Aivaliotis @ Mar 18 2009, 06:04 PM)

I also use a similar stop functional global concept to trap aborts from parallel processes. Mine also has a reset input so you can clear the abort after you've acted upon it.

I'd like to address the use of cases to "case-out" code after an abort. Depending on the granularity of your state machine, you may be able to get away with handling the abort up front and avoiding the need to place the abort checking too deeply in your code. here's how I handle it using the JKI state machine.

I try to avoid putting looping code inside subVIs where I have to later abort them. Instead I use the natural looping of the state machine to repeat test tasks.

Due to code reuse, the code's not as granular in a couple places as I'd like it to be. And I agree completely about the loops, but there was one case where it just had to happen. So I have to tie the abort to that condition.

Thanks for your code example!

QUOTE (Aristos Queue @ Mar 18 2009, 06:07 PM)

I have a clean-up state that it really needs to go thru before exiting the state machine. Otherwise that would probably be okay since there's not much else going on in the program.

QUOTE (Mark Yedinak @ Mar 18 2009, 02:24 PM)

What we do to handle this is use a traditional producer/consumer model and allow the producer (event structure) to catch the abort request. Our state machine is a queued state machine so when we catch the abort we can inject an abort state into the running state machine and exit gracefully. This works very nicely and we don't need to use any global variables or references to controls in the state machine. In addition, we don't have to check the abort state after/before every state change.

I was just thinking about queued state machines this morning. I'm expecting the next request to be a "suspend" button... I was having a hard time wrapping my brain around a good way to do that with my current design. But a queued state machine (that keeps track of where it needs to go back to after the "suspend") seems to make more sense. Thanks for the suggestion.

QUOTE (SULLutions @ Mar 18 2009, 02:31 PM)

I appreciate the dispensation.

Also, thanks for the code sample. You're right, if I use a LV2 global, I'll probably feel a lot better.

QUOTE (neBulus @ Mar 18 2009, 02:35 PM)

Wow! After your experience, I can hardly blame you.

QUOTE (Yair @ Mar 18 2009, 02:38 PM)

Yes, as I think I've mentioned, I'm already anticipating a "suspend". And then there's going to be the inevitable "exit". The FGV is probably a good way to go. Thanks!

I'm thinking about taking the NI OOP class. It appears I've missed the cruise, so I'll have to settle for a regular ole office building.

I stopped programming in C about the time C++ was getting popular, so I don't know much about object-oriented programming in general. Every time my cow-orker who is a C#.NET, etc whiz tries to explain it to me, it sounds like he's talking about ways of accessing typeDef-ed clusters with data and their associated info. It must be more complicated than that. I looked at the LV OOP stuff back when it came out in 8.2, but it seemed like it was adding code on top of what I was already doing. Once again, I assume my lack of knowledge is the problem.

My question is this: Do I need to learn C++ before I take the NI OOP course? I've read thru all the doc links I can find on this site and they've managed to underscore how little I know about the basic language of OOP. If they teach the class in that language (ie, here's how you all did it in C++ and now here's how we'll do it in LV) I'm sure I'll manage to stumble along, but won't get as much out of the course as I possibly could.

Any thoughts?

QUOTE (Michael Aivaliotis @ Mar 18 2009, 07:01 PM)

If some of you see the "loading VIs" dialog popup when you are opening a project, this is because you are using LV classes.

Ohhh, that explains it. I wonder about that everytime it pops up. I'm not using classes (which I have a Q about but will post on another subforum), but I guess something I'm calling does. Thanks for the info!

I've got my current piece of code pretty much done. The users love it, since I've taken what used to be a manual, 6 hour long test, filled with all sorts of room to make mistakes in data taking, and turned it into a 22 minute completely automated, push a button, walk away, come back and see your neatly tabulated results sort of test.

Then they say, "We'd like to be able to abort the test in the middle of running it."

Hmm. I've got your typical state machine built. TypeDef Cluster of all the needed variables going into and out of each of the 10 or so states. It's all very neat and tidy. Now I've got to put a reference to the abort button in the cluster, unbundle it, get a property node for it, read it, feed it into a case statement for each of the states and their various subvis. This adds all sorts of bundles and big references and wires cluttering up the screen. Things are no longer neat and tidy. Some of my BDs that were just under one screen are now bigger than one screen. Eek!

So I was a bad girl. I used a global variable. I still have case statements, but there's no unbundle wire, and no unbundle box, and no big value property node. Just one little tiny global called "stop!".

Please don't hate me!

Cat (too upset to count)

QUOTE (crelf @ Mar 15 2009, 05:56 PM)

As a thank you for their great support here on LAVA, a lot of members have been promising each other to buy them a beer at NI-Week. This thread is to try to keep track of those.

Oh great. Yet another reason to be irked my employer is never going to cough up the $$ for me to go to NI Week. It would be worth it even if I had to hold my own kegger for you guyze.

Cat

QUOTE (zmarcoz @ Mar 17 2009, 11:48 AM)

Btw, how will you pronounce UI?? Do you just call it U-I or call the long form user interface?

Now this is an interesting question. I find that if I'm going to abbreviate it, I say GUI (gooey), but if I'm going to say it all out, I say "User Interface". So I personally would not say UI (you-eye) or "graphical user interface".

Most of the folks I program with are C programmers and wouldn't know a GUI if one smacked them upside the head, no matter how I pronounce it. :-)

Cat (42/1000! Well on my way!)

QUOTE (zmarcoz @ Mar 15 2009, 11:42 PM)

After I fail in my LV job interview, I really want to know what knowledge should a LV programmer should know? I understand that the answer may depend on the company, but any general knowledge that I should know?

Maybe I should give an example, I would expect a webpage developer knows about Photoshop, Dreamwaver, php, frontpage, etc

Substitute "C++ programmer" for "LV programmer" and ask the question again. Your analogy implies that LabVIEW is a specialized language. Or maybe isn't really a language at all, but a tool for some specialized purpose. That may have been the case back in the Bad Ole Days, but some of us use it for a general purpose programming language. Yes, I can control instruments with it. Yes, I can automate tests with it. But over the years I've used it for a lot more than that.

So as some other folks have said, if you're hunting for a job, it's important to know exactly what you're applying for, and just like with any other language it's important to know your particular strengths and weaknesses.

Good luck with the job hunt!

Cat

QUOTE (shoneill @ Mar 17 2009, 07:07 AM)

Happy St. Patrick's day.

Funny thing, being Irish, is that neither myself or any of my friends or family bother wishing each other happy St. Patrick's day. Seems to have a life of its own.....

Either way, enjoy your beers (or Stout to be more accurate re: Guinness). I prefer Murphy's myself though.....

Shane.

We just like an excuse to have a party and drink to excess. Usually we have to do it with without an excuse.

It is interesting how it's ingrained at an early age. My daughter (13yrs) was getting all perturbed last night that she didn't have anything green to wear. We dug up an old green soccer shirt and everything was right again with the world. I remember going thru that exercise when I was a kid, too.

And I don't drink beer. It's much too wimpy. :-)