Jump to content

Cat

Members
  • Posts

    815
  • Joined

  • Last visited

  • Days Won

    15

Posts posted by Cat

  1. 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.

  2. 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

  3. 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

  4. QUOTE (TobyD @ Mar 11 2009, 10:08 AM)

    Would a viewer really help anyway? If you can't install software...

    Well... hypothetically speaking, I could copy an unobtrusive stand-alone executable to this machine and run it. It's just when there's a "setup.exe", "*.msi", or other file of that sort involved that I get instantaneous permissions errors. And even if I did put an unauthorized *.exe file on here there's a good chance the Computer Police would spot it and wipe it off. But that takes awhile and I could just recopy it. Hypothetically speaking, of course...

  5. Well, the title says it all. I'm in need of a LV Viewer, something that allows me to look just at vis but not edit/save/execute. I did a search on the topic and found some posts from a year or two ago, with no luck. I was hoping there might be a chance something had become available since then.

    Here's the situation: You all post all sorts of interesting sounding code on LAVA. I can't see it because I don't have LV on this computer. It is, in essence, good for nothing more than reading email and browsing what few websites the fed gov't allows (I'm at a .mil site). I am not allowed to install software on this computer. So to see your code, I have to copy it to a thumb drive, and then walk over to the lab where my development computers are. But wait, in the latest flail of government paranoia, we're not allowed to use thumb drives anymore (don't get me started... :headbang: ).

    So, it would be nice if there was a viewer available for LV. And in the meantime, let me add a sincere thanks to those of you who post screenshots of your code. That at least I can see.

    Cat

  6. QUOTE (neBulus @ Mar 3 2009, 10: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.

    Coolio!! (as my 13 yr old daughter would say)

    I got about 10 words into the description of it to my normally tightfisted team leader, and he said "Buy it!!"

    I'm getting a new toy! I mean, I'm getting an important tool to help make my software more efficient and bug-free...

    Thanks for the suggestion!

    Cat (I think I just used up my exclamation point quota for the day! :D )

  7. QUOTE (Antoine Châlons @ Mar 3 2009, 10:40 AM)

    Well.. How big is you code ? I mean how many VIs more or less.. Have you identified which VI in your code is chewing up your memory ?

    It's hard to have an intelligent guess without seeing the code.. can you post it ?

    The whole executable has around 2000 vis in it, give or take a few. The section of the code where the problem occurs is around 100 vis. I can tell you that the Out of Memory error occurs when buffering the data, however, I can't tell if that's actually what's *causing* the problem. As I said I can run this for days with no problem, so it's hard to troubleshoot. I've never known it to fail in less than 2 or 3 hours, tho, if it was going to fail (which makes it very time consuming to troubleshoot). If I run the VI metrics tool that comes with LV, nothing stands out as a problem. But then again, maybe it just wasn't going to fail those times I tested it, or maybe it only occurs in the executable.

    I know this is a tough one, especially since I have so few details to give. I guess I'm hoping someone out there has seen something like this happen before and can point me to something to fix, or at least commiserate. :-)

    Cat

  8. Hi all,

    I need a LAVA category of "Strange behaviour that I can't explain!"

    Here's the problem: I dynamically call a vi that, in essence, reads in data via TCP (64kS/s), buffers that data if needed, performs an FFT on it, and displays the results on a waveform graph. This program will run just fine for hours, when all of the sudden it starts chewing up memory, at the rate of about 200k per second (as reported in the "Processes" tab of Task Manager), until the machine runs out of memory and crashes. If I close the vi in the midst of the memory grab and reopen it, it's fine again (until the next time it happens). This bug doesn't always occur (I've run it for days with no problem) but it happens often enough that it's more than just an annoyance.

    This has happened in both 7.1.1 and 8.5.1, on a variety of computers, all running WinXP. The code has been built into an executable. I've never had the source code show this behaviour, but it hasn't been used as much as the exe.

    Any thoughts?

    Cat

  9. Hopefully the cross-posting police don't get me. After not getting very far here, and still being plagued by this issue, I posted this Q to the NI forum. I got help, but all of it was a dead-end. THEN...

    -----

    I got a new laptop in yesterday and loaded LV on it (isn't that what everyone does as soon as they get a new computer?) Just for grins, before I loaded any of my source code on it I did some tests to see if LV would hang.

    It worked just fine.

    I've spent the morning incrementally adding my source code and various settings files I've tweaked over the years. It took awhile, but I finally found the culprit: buried in my 1200+ vi user.lib was a link to a vi that no longer existed. I took that one link out and LV no longer hangs after startup.

    Why disconnecting from the network changes the behavior, I can't say -- maybe LV is trying to search the web for the missing vi (even tho it pointed to my c: drive). But whatever, it's all working fine, now.

    -----

    Since there were a few of you out there with this problem, too, I thought I'd post my solution here in hopes it would help.

    Cat

  10. I'm harsh. :-) I've already disabled labview.exe access since my development laptop only runs in the lab (or under the Deep Blue Sea). It seems the problem is that LV is still trying to get out, anyway, so I'm guessing you're right; there is some ini setting or something I need to turn off.

    QUOTE (Neville D @ Jul 14 2008, 05:57 PM)

    Are you sure you have activated your version of LabVIEW?

    Have you mass compiled your application to update all your VI's to 8.5.1?

    I'm definitely activated. LV is one of the few software packages I'm anal-retentive about licensing and activating.

    This slow-down happens on both old mass compiled code and brand new vis. And whether I've got a couple vis up or my 1800+ vi monster project loaded.

    For the moment I'm just running with my network cable unplugged. But that's obviously not a long-term solution.

  11. 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.

    A cow-orker recently brought some of his LV code to me to look at. When it was running, he commented on how much slower it seemed to run on my computer, especially right after we pulled up the vi. He ran the same code on his laptop, and sure enough, the code ran faster.

    I started paying attention to what was going on when I started up LV and then subsequent vis. It looks like, in addition to a whole lot of disk thrashing, my network gets accessed every time I open up a new vi. So I pulled the network cable out of my computer, and sure enough, everything runs fine; no hang-ups.

    I'm guessing LV is trying to do some sort of network access. My lab intranet is not connected to the Outside World, so this may be problematic. If this is the problem, is there some way to disable whatever network access LV is doing?

    Cat

  12. I did a search of the the NI site on "tulip VISA" and came up with the following link:

    http://digital.ni.com/public.nsf/allkb/3B3...625694200791AD7

    Basically, you can add passports to MAX and it will see different classes of instruments. Of the long list in MAX, the only one that wasn't configured was NiVisaTulip.dll Go figure...

    Anyway, I configured it, and now I can run both the USB and Agilent boards at the same time

    Thanks for all the help!

    Cat

  13. QUOTE (Rio C. @ May 23 2008, 12:32 PM)

    I didn't try to make them live together, but I found that I could re-enable the NI-VISA without reinstalling it. In the \windows\system32 directory there should be a file named visa32.dll. What the Agilent installation does is rename it to something like visa32.dll.old or something. Simply rename the file and you should be up and running :D . I don't remember if I had to restart the system.

    I found the NI file (visa32.bak), reloaded it, and everything was happy again. Except for the Agilent boards, of course. But at least I have a workaround now.

    Thanks!

  14. Hi all,

    I have several boards hanging off a USB hub that I control. When I open up MAX they happily appear at whatever COM port Windows has assigned to them. No problem.

    Recently, I've started a diferent project where I am controlling some VXI cards (8491B/1432B). After much flailing about, I finally figured out that to talk the driver that came with the 1432 card (CVI) I had to install Agilent VISA, and during that installation set the default VISA to Agilent VISA. So I did that and it's working fine.

    But now I can't talk to the boards on my USB hub. MAX doesn't "see" them.

    Are there really different "flavors" of VISA? If so, is it possible that's what's causing my current problem? And if so, how do I get back to NI VISA so I can read the cards hooked up to the USB hub again?

    Cat

  15. QUOTE (crelf @ Apr 29 2008, 06:34 PM)

    :unsure: Ahhh - you're right - I should have said my sister-in-law...

    You guys are cracking me up! :laugh:

    Thanks, I needed a laugh this morning. I moved on monday and the past week has been hectic, to say the least.

  16. Guys, guys! Are we being just a tad bit sexist here?!? :rolleyes:

    On the flip side of the coin, my ex-husband and I were travelling across country and he was driving. I took a little nap and when I woke up he was on the completely wrong highway. I did some quick remapping (this was pre-GPS days) and got us going in the right (but now much longer) direction. When asked why he didn't stop when he thought he might be going the wrong way, his response was, "I was making really good time."

    As I said, he's my "ex" now... :)

  17. QUOTE (Yen @ Apr 24 2008, 01:35 PM)

    I think they had one of those games at the last NIWeek, but I didn't participate.

    I saw that when I did a search on "geocaching" on the lava website. Yet another reason to try to make it to NIWeek sometime. My team leader is a geocacher; maybe he'll break some $ loose for it now. :)

    It's a lot of fun. I've found over 100 geocaches in 17 states. This is nothing compared to Real Geocachers. They have find counts in the thousands. Most geocachers tend to be in the tech professions (or families thereof).

    There are more than 600,000 caches hidden in over 100 countries.

    It's a great way to see places you never would have gone otherwise. A fun way to get out of doors and get a little exercise (or a lot, depending on the cache).

  18. QUOTE (TobyD @ Apr 22 2008, 12:04 PM)

    Wouldn't that be nice! No, we are not allowed to do email forwarding from work. I have a ".mil" address, if that makes things any clearer...

    QUOTE (Michael_Aivaliotis @ Apr 22 2008, 01:17 PM)

    There are many ways to do what you want without adding yet another feature to the forums. Try opening a gmail account. Use that for the forums. Then you can use it at home. You can then setup your gmail to forward copies of your LAVA mail to your work account with a filter.

    Hmm, yes, this *should* work. Thanks!

    Sorry, I wasn't really requesting a feature be added to the forum, more like asking if it could already be done. Is there a better place for me to have posted this thread?

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.