Jump to content

Dan DeFriese

Members
  • Posts

    201
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by Dan DeFriese

  1. No I've never done it but you should be able to iterate through your VIs using the LockState.Set Invoke Node. There is also a setting for applying a password to source in Source Distribution build spec.

     

     

    Okay just created and example which will set a password on all VIs in a directory recursively - BE CAREFUL what you point it at :)

    Batch Password Example.vi

  2. Can anyone imagine why it is missing from the standard palette?

    It's in LV since version 8.0 ...

    My imagination is limited so I selected the context help - it sends you to '(Incomplete) Beta Function'. So I'd guess that either it dropped off someone's radar at NI or there was a problem with the implementation and someone forgot to remove it (and dropped off the radar ever since!).

  3. I've never seen the lvlib resort to absolute paths, but if it is modified while in the LabVIEW directories (vi.lib, instr.lib, user.lib, etc...) it may get saved with symbolic paths instead of relative paths. As in this example from my instr.lib folder:

     

     

    <Item Name="Aardvark Convert Error.vi" Type="VI" URL="/<instrlib>/aardvark/aardvaru.llb/Aardvark Convert Error.vi"/>
    <Item Name="Aardvark GPIO Set.vi" Type="VI" URL="/<instrlib>/aardvark/aardvark.llb/Aardvark GPIO Set.vi"/>
    <Item Name="Aardvark GPIO Direction.vi" Type="VI" URL="/<instrlib>/aardvark/aardvark.llb/Aardvark GPIO Direction.vi"/>
     

    Could your source have been in these LabVIEW directories?

     

    ~Dan

  4. The simple answer it that clock speed is the only contributing factor to performance.

    In either case, it appears your application needs some attention with regard to efficient programming techniques. My first step would be to run the program in your development environment and use the Profiler (Tools -> Profile -> Performance and Memory) to find which parts of the program are consuming the most resources.

    ~Dan

  5. honestly i have never read about chunks, could you give me some details please

    i have built successfully an aplication that transfer files using TCP, however it is really slow, this is why i need to use a faster protocol like the UDP

    ok you can ask my teacher about that, he insist on building a new application!!

    thanks for the link, i have already tried it and actually it can't give a transfer rate more than 2Mb/s, which is far from my goals!!

    Sorry I didn't realize this is a homework assignment. In that case, you can learn about TFTP and implement your own solution by reading RFC 783 and RFC 1350. This will also give you an understanding of what chunks are.

    Good Luck!

    ~Dan

    • Like 1
  6. However. If people feel the architecture for these fairly simple systems require a tool-chain just to realise it. Then perhaps the proposed architecture is over-complicated for the task (KISS).

    I couldn't agree more. The best thing I took away from the CLD is that my approach was way too complicated for what I was being asked to do. My submission was good-enough to pass, but I didn't complete all the features. I've really concentrated on the KISS principle ever since. Thanks NI!

  7. Eric,

    Yep, still working on it. I actually went a different route. I'm using a MAX created task as the input to the DAQmx nodes and I've given them access to MAX so that they can configure the channels, scales, etc. It seems to be working so far, I haven't encountered any issues yet. Any hiccups you see in this logic?

    -Ian

    Have you looked into to pointing the user(s) to Signal Express? It sounds like you're reinventing the wheel here.

  8. The situation you described really sucks, Crystal, but let's not vilify a feature that isn't being forced on the user in any way by LabVIEW itself, but instead was improperly used in a special circumstance.

    The Resolve Confict dialog(s) are forced upon me occasionally when I move stuff around intentionally. That feature upsets me so much I have to go get a cup of coffee after 1-10 minutes of arrow-enter . Can we vilify that feature?:P

  9. I see what you mean, but they're run-time settings, the BDC is an edit time thing. I'm not saying it's an unreasonable request, but saying that you want to be able to disbale BDC is like saying that you want to disable undo or align right - where does it stop?

    Why should we have to stop? I don't know about "disabling" a feature (except that damn conflict dialog), but being able to configure which toolbar buttons are visible seems very reasonable to me. MS Office has provided this capability since as long as I can remember.

    I don't care for the BD Clean-up either so I deleted the CTRL + U menu shortcut in the options to prevent inadvertant use on my system.

  10. sir i m doin a small project whr i need to count the breathing rate frm a recorded wave file but dont kno how to proceed

    plz plz help me i m a newbi and dont kno much abt labview

    You don't need code for this. I read the Snapple Fact the other day: The average person take 28800 breaths per day!

    But seriously, we can't do homework for you. Show us what you've done and where you think you need help.

    ~Dan

  11. If I load in the main vi a subVI with its graphics functio on control pannel the graphics windows of the subVI does not appear on the control panel of the main VI.

    How can I do?

    thanks

    Sounds like you could use a subpanel control on your main VI (top-level front panel) to select between your 3 subVIs. Look at the "Subpanel Viewer.vi" in the Example Finder. (Help -> Find Examples...).

    ~Dan

  12. Thanks CAT,

    Ok, i can install external drivers manually. But the "imaq_usb_installer_setup.exe" and "imaqUSB.llb" and all how can i add with installer? Is there any options to make it in installer itself otherwise i have to install it seperately.....

    Thanks in Advance,

    Kalanga

    The 'Advanced' page of the installer properties allows you to specify an executable to run after the installer completes. In the past I've used this feature to lauch the 3rd party installers. (I create a small .exe in my project which gets placed in the TempFolder by the installer. After the NI stuff gets installed this temp.exe runs and calls the 3rd party installers located on my install CD.)

    It's certainly not perfect but it usually works for me.

  13. At bets, you must define a standard messaging architecture that will be shared in all of your applications. By decoupling the subVI from the messaging scheme via an automatic event you significantly increase the reusability of your code.

    Thanks for expaining.

    Personally, I'd prefer a standard messaging architecture. When a VI exits unexpectedly (assuming this is what your trying to catch) I'd want to no why. That is, the error value on exit.

    While I can see how a built in event would be easier, I'm not sure if it would be more useful than queues and notifiers to my typical usage.

    ~Dan

  14. However, I was hoping that LabVIEW would already provide a general method to allow calling VIs the ability to catch when a VI it spawned closed. This seems to be something missing which would be very useful for managing spawned tasks.

    The caller can use the method "FP.Close" to cause the called subVI to exit. However, the reverse it not supported since it appears without extra effort the top level VI is unable to detect when a subVI closes.

    How would this event be more useful in managing spawned tasks? (As opposed to using and messaging primative queue, notifier, user event.) If the Dymamic Asynchronous VI (Daemon VI) is running in its own call stack and exits autonomously, wouldn't the VI Reference of that VI become invalid? If so, I'd suspect that the VI Ref terminal in the "VI Exit" case of event structure on the top-level (spawner) would be invalid and otherwise useless.

    I don't mean to knock your idea. I'm just missing how this would be useful.

  15. Well, even though it’s not true. I sometimes pretend it is.

    I certainly take no offence since NI hardware just seems to work better and more reliably than the cheaper crap people bring into the lab. Even those poor C\C++ programmers down the hall agree, eventually.

×
×
  • Create New...

Important Information

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