Jump to content

Klompmans

Members
  • Content Count

    6
  • Joined

  • Last visited

    Never

Community Reputation

0

About Klompmans

  • Rank
    LAVA groupie
  1. O O It seems like I should Read The F***ing Manual. I've looked at quick drop before but never saw the `super quick drop' option or the shortcuts - and without those it's quite useless so I dismissed it without looking further. My bad, should've had faith in NI. Although quick drop is not exactly what I'm looking for (I'd like it to be always-on) it sure seems like a step in the right direction. Imma try the Darren way as well as Vugie's VI (I guess I'll have to adapt it to obtain the exact functionality I want). Thanks guys!
  2. Having been using LV for some time now, I start to get annoyed more and more by the incredible amount of mouse movements/clicks I have to make. For every component you need to move your mouse to the functions/controls box (or right-click), go through several submenus, find your desired function and place it on the diagram. I find that this is not only very (and needlessly) mouse-intensive, but also removes my focus from the code I'm producing, and thereby breaks my concentration and decreases the amount of code I could produce per hour. It would be much easier if this could be done with the k
  3. QUOTE (mesmith @ Jan 28 2009, 11:20 PM) Hi Mark, The core program should run in a separate thread indeed, the machine is using very delicate and expensive consumable items, and we'd like to protect this part as much as possible from any disruptions. In other words, if a user screws up and LabVIEW hangs, we need the core application to nicely put the system in a `safe state'. Therefore, we cannot make it into a library for it would still run under LabVIEW and crash along with it (I know that LabVIEW has different threads like UI, user1, user2 etc. but that still wouldn't do me any good if
  4. QUOTE (Paul_at_Lowell @ Jan 28 2009, 09:07 PM) Wow, you're fast. Thank you. Err no, the UI needs to be completely seperated so people can change it or use their own without changing the core application. Anyway, the Shared Variable or DataSocket option might work - I'll give it a try. The VIserver option doesn't work anymore as of LabVIEW 8.2 (if you try the example they give, it simply doesn't work). Thank you again!
  5. QUOTE (Paul_at_Lowell @ Jan 28 2009, 05:10 PM) Hi Paul, Indeed, it needs to run without the labview environment. We'll need to communicate with it from either a labview-build executable (stand alone user interface), or from the labview engine (customizable user interface). At the moment third party tools (other than other VIs/labview executables) dont need to be able to communicate with it. Would be a bonus though. Thank you, Klompmans QUOTE (mesmith @ Jan 28 2009, 05:16 PM) A couple of ideas 1) Build the core program as an actual DLL (using the option in the LabVIEW Build Specific
  6. Howdy all, I have the following problem: I need to design a program running a measurement setup, which needs to be separated in two parts: a core program running the hardware (and doing the actual measurements), and a user interface. So far it's not hard. However, the core program needs to be stand-alone/DLL, able to run without LabVIEW, while it should be able to receive its instructions from the user interface. It should be possible to run the user interface under LabVIEW as well as as a standalone. The reason for this is that some users just want to use a standard program (these users mi
×
×
  • Create New...

Important Information

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