Cat

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) 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) 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) If you don't make any good progress (if you do not have premier support that could be an issue) use the phrase "I understand that it should be possible to ESCALATE this call, could you do that please?" Mnay AE's (particularly the rookies) will fight that thinking that they have failed if they do so. 2) I believe it is Elijah Kerry form NI who is pushing those new tools. Since he is in the marketing side you can just ask for him when you call NI. Tell him that "Ben NI" said that "he (Elijah) can make recomendations on who to talk to to get the tool working the way it has to." Have your service request handy when you call for him since he can use that to escalate the call. 3) Talk to your local NI person. They picked-up a little extra in their pay-check when you bought that software, let them help out. I aggre with Neville that traditional approach may hel pnarrow down the issue to a point where can invoke the toolkit to get that extra info you require. Still trying to help, Ben 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) 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) Please tell me you have been talking with NI Support to address those issues (please). That is one of the new widgets NI is pushing so you should be able to get some decent support. 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) PS After you have your issues solved and you become our expert on this tool, you may want to take a look http://forums.ni.com/ni/board/message?board.id=BreakPoint&view=by_date_ascending&message.id=409#M409' target="_blank">at this Sea Story I posted over on the Dark-Side. Great story! Now I understand the bump on my head!

QUOTE (neBulus @ Mar 3 2009, 11:46 AM) 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) 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) Just because you close the panel of a VI doesn't mean it stops running (as you are seeing). 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) 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) 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) 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) 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) 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) Another solution would be having the UI be VI A and the state machine be VI B and instead of calling VI B as a subVI, call it using a VI Reference and the Run method, then when user hits the STOP button, you call the Abort method of the VI reference. Your app as a whole keeps running, but that state machine stops. Is that more or less dirty? Can it be made acceptable somehow? 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) 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) On the other hand, one little global does not merit sack cloth and ashes, even during Lent. 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) How could I fault you when I have been guilty of the same sin. I have been global free for almost two years at this point. Wow! After your experience, I can hardly blame you. QUOTE (Yair @ Mar 18 2009, 02:38 PM) One point, though, is to consider whether you want a global. Currently, you have a single writer. In the future, you may have more (e.g. maybe you have an E-stop button). One simple way of working around this is creating a simple functional global with two inputs - Stop and Reset (both default to F) and one output (Stop?). When stop is T, you raise the stop flag. On first call or if Reset is T, you reset the stop flag. You can then stop the code from several locations. 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) 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) 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) 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) 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) 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. :-)

I'll be hoisting a Guinness or 3 tonite. Or better yet, some Magner's. There's something to look forward to to get me thru the day! Cat

QUOTE (Yair @ Mar 11 2009, 02:44 PM) I'll give the online evaluation a try and see how that goes. Thanks for the suggestion. P.S. LAVA is *not* on the list of *unapproved* sites. Once Big Brother discovers how much time I spend here, however, all bets are off. :-) P.P.S. Thumb drive security risks are a *training* issue. I'm well trained not to walk out of here with classified documents. I'm well trained not to send classified email. My much-missed thumb drive is both encrypted and has a physical write lock on it. I know how to use it securely. People just need to be educated on how to use a thumb drive safely, just like they had to be educated 15 years ago on how to use a floppy disk safely. I'm stopping now, before this turns into a full-fledged rant. I said not to get me started on this topic! QUOTE (Michael Aivaliotis @ Mar 11 2009, 07:28 PM) I think we should all make an effort to post screenshots. Nowadays I prefer video. It's so easy with Screencast.com and Jing (is screencast.com blocked Cat?). Not yet... I'm not sure what would happen if I started downloading a lot of content from there. It might get Someone's attention. But it works, for the moment.

QUOTE (jzoller @ Mar 11 2009, 03:34 PM) Where was this wiki page 10 or 15 years ago when a day rarely went by that LV wasn't throwing an "Insane Object" error? :-) Thanks for the link! And no it's not a big deal, except when this control is in a bundle that I use to feed a state machine thru 15 states and the error appears in Error List 30 times. Then it's a bit annoying. QUOTE (Aristos Queue @ Mar 11 2009, 06:26 PM) Here's a far simpler explanation: Pop up on the Refnum control and select "Show Control". That's the control that is being talked about. Thru process of elimination I figured out what control was throwing the error. What I don't understand is the difference in behaviour related to 1) how the reference is created, and 2) whether it's a reference to an array or a scalar. That's the Reader's Digest version of my previous page-long post. :-) Cat

Puzzle of the day: Open a new vi and drop an array on the front panel. Fill array with a dbl. On the BD, create a reference to the array. Then right-click on the reference and create a control of the reference. Up to this point there should be no errors reported. Now induce an error. For example, make a local variable from the array but don't attach it to anything. Check the Error List. Along with the expected "local variable not connected to anything..." is another error: "Front Panel Terminal 'Array': hidden front panel control has undefined type" Delete the local variable and once again, there are no errors reported. Where did this come from? If there was an error, why didn't it show up until there was another completely unrelated error? What don't I understand about references (well, a whole lot, probably, but in this case specifically)? A few notes: 1) It doesn't seem to matter what the array is filled with, it still breaks 2) A cluster breaks it, too 3) If you right-click on the reference control on the FP and select "Show Control", it shows an empty array 4) If you delete the created FP reference control and re-create a FP reference control by dragging the BD reference to the FP, it does *not* show the extra "hidden front panel control has undefined type" error (behaving correctly, I assume) 5) The FP reference created in #4 shows a dbl array when you select "Show Control" (behaving correctly, I assume) 6) If you do the above exercise with a plain numeric, it does *not* show the extra "hidden front panel control has undefined type" error (also behaving correctly, I assume) My conclusions: 1) creating a FP control reference of an array/cluster by directly creating a control on the BD isn't working right (but scalars are fine), or 2) It's working exactly how it should be working, but when the error gets reported (after something else goes wrong) isn't working right, or 3) I don't have a clue about references Can anyone replicate this or let me know what it is I'm missing? I'm using v8.5.1. Cat