Jump to content

LAVA 1.0 Content

Members
  • Posts

    2,739
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by LAVA 1.0 Content

  1. QUOTE (PaulG. @ Jan 30 2009, 09:59 AM)

    Same idea as Paul G, but write the time of the first run into the registry (assuming you are running on Windows). Every time the application starts, check the registry location. If the entry is not there you assume that it is the first run and you write the time/date to the registry. If the entry is already there then check to see how much time has passed, and if it is more than 15 days, exit the application.

    To make the registry entry harder to find manually, do not use an obvious name for the key and encode the value (time/date) using some simple algorithm.

  2. QUOTE (crelf @ Jan 29 2009, 10:05 PM)

    But doesn't that just create a new control with the value of the existing control? I want to save the control itself so I get to keep all the attributes (caption, colors, size, etc).

    Yep, I get what you want.

    I don't think this can be done in a truly fully generic way programmitically.

    The routine 'Right Click->Advanced->Customize->{(Strict)TypeDef}->Save' is what you need.

    I've got a feeling that this is not possible.

    One could write xml/ini based solutions but they are tight to control types. Would make a wonderful class routine.

    Ton

    PS, learn how to ask questions on twitter in 160 characters...your initial question seemed so much simpler

  3. ok, i just read on this page: http://www.dotnet247.com/247reference/msgs/57/285549.aspx

    that Control.FromHandle only works on windows in the current process (for .NET). Now the .NET code that you call should be running in a different process than your LabVIEW process, so Windows Security finally takes effect.... I guess we may have to do this the old-fashioned way - with windows hooks.

    I will have to do some reading first for this one. My app had all its windows running in the same process, but apparently that is not the case for LabVIEW.

    Take a look at this NI example:

    http://zone.ni.com/devzone/cda/epd/p/id/4394

    You want to intercept messages that go into your LabVIEW window, and you want to listen for the WM_MOVE message. (Too bad we can't do this in .NET)

    anyway, have to go get some food now.

  4. This is what I came to conclude:

    The int to IntPtr VI works perfectly fine, I verified this by getting the actual handle to my window by using Winspector, and by calling the "ToInt()" function of the resultant IntPtr .NET object.

    Now, after calling the Control.FromHandle function, I tried accessing any property of the resultant .NET object (of type Control), and none of the properties were coming back! I fear this may be because of some sort of Security feature of .NET. I will try to replicate this similar behavior on my computer by creating a non-.NET (aka unmanaged) C++ program that would represent LabVIEW, and then call the same .NET functions.

    Real quick, what version of .NET are you running?

    Another thing we can do is to write our own custom .NET Assembly that would implement the desired behavior and to then call our own custom .NET Assembly to do what we want.

  5. QUOTE (vultac @ Jan 28 2009, 11:26 PM)

    Hi guys, ive attached a flow chart of what im supposed to design with labview...im stuck at the looping part... some advise would be appreciated thx guys!

    Try to get your hands on the NI State Diagram Toolkit (not the statechart module). It is obsolete but perfect for what you want.

    Another (good) option is using a statue machine, for instance the JKI statemachine (after how many plugs do I get a VIPM license?)

    Ton

  6. I just saw something quite interesting in the MSDN....

    You can easily hook into the events of another window/form/control by using the Control.FromHandle(IntPtr Handle) static member to create a new Control type.

    All you need is the window Handle, see if LabVIEW exposes that for you, otherwise we will have to look for an alternative way of retrieving it.

    private static IntPtr _handle = IntPtr.Zero;        static void MyThread()        {            Control testForm = Control.FromHandle(_handle);            testForm.Move += testForm_Move;        }        static void testForm_Move(object sender, EventArgs e)        {            Control myControl = (Control) sender;            System.Diagnostics.Debug.WriteLine("Location: " + myControl.Location + ", Size: " + myControl.Size);        }

    So what you have to do from LabVIEW is call the .NET 2.0 static method "Control.FromHandle(IntPtr)", and then you have to listen to its "Move" event. (http://zone.ni.com/reference/en-XX/help/37..._hndl_ax_evnts/) Each Move event callback will have a sender parameter which is simply the Control object, and once you cast it to Control you can get that windows properties.

    I am attaching a Visual Studio .NET 2005 C# solution with this example. (I do not have LabVIEW installed here but I can do it when I get home)

  7. Is this what you are trying to do:

    Display:

    Show a main window

    Show one or more child windows relative to main window

    Event Responses:

    Whenever the main window moves, you want each child window to follow the main window with a certain offset.

    Whenever one or more child windows move, you want the parent window to move the same way.

    (I guess you are looking for behavior similar to WinAmp 3.0? where your playlist would snap to the player...etc)

    Well, I have done something very similar - and many people like to call it "snapping".

    Basically what I did was start sniffing the Windows Messages of the main window from each child window, and whenever a move was detected I would set a local boolean variable to "true", and move that corresponding child window. And the boolean variable would disable the sniffing of windows messages until the move was finished.

    And I did the opposite for the main window listening to each child window.

    This shouldn't scare you to implement in LabVIEW, but I do recommend using an iterative approach, let me know if this is what you intend to do.

  8. QUOTE (NeilA @ Jan 28 2009, 06:39 PM)

    QUOTE (normandinf @ Jan 28 2009, 06:56 PM)

    There are many properties and methods to allow you to control exactly what you're describing.

    Check out these to start:

    VI.FrontPanel.Open (Property node)

    VI.RunVI (Method)

    And I suggest you command the spawned VI with Queues or Notifiers (to instruct it to close for example...)

    And VI.Abort (method).

    Pausing a VI is afaik not possible.

    Ton

  9. QUOTE (Dave Graybeal @ Jan 27 2009, 01:56 PM)

    I recommend taking a look at the "Fit VI Window To Largest Decoration.vi" Found in the OpenG Tools under the Application Control Tools. This VI works great for keeping the run size and position the same. You simply put a Frame Decoration (or any decoration that you like) around the area that you would like to be viewed when running. When the VI is called (typically I use it as my first VI in my startup) it will reposition the VI Window to show only the contents of the decoration regardless of where the front panel was last saved.

    Be aware this only works on single pane VIs!

    Ton

  10. QUOTE (john@aleconsultants.com @ Jan 23 2009, 12:31 PM)

    Do you know if the latest PXI FPGA solutions that use Xilinx Virtex-5 chips make any improvements on this?

    Yes, the Virtex-5 based boards are able to run code at significantly higher loop rates then the older R series cards using the Virtex-2.

    I tested one example to get some numbers. The example is a SPI generator based on a state machine in a SCTL. For the Virtex-2 board (7833R) the maximum rate (according to the simulation in the compiler) is 116 MHz, while for the Virtex-5 board (7842R) The maximum rate is 159 MHz.

  11. QUOTE (LV_FPGA_SE @ Jan 23 2009, 01:15 PM)

    A little more detail:

    The derived clock (e.g. 200 MHz) can only be used to drive a single cycle timed loop (SCTL) in the LV FPGA diagram. Anything that you put inside the SCTL needs to be able to run within the derived clock period of the loop, e.g. 5 ns for a 200 MHz clock rate. Therefore if you put more code into a SCTL, the maximum rate at which that SCTL can run will be lower.

    A 200 MHz SCTL will in fact be able to run very little code, which will most likely be limited to Boolean logic. Doing any kind of numeric data processing will be limited to significantly lower rates with a maximum loop rate in the range of 40 -100 MHz depending on the complexity of the code. In fact, if your longest code path in the SCTL increases, the maxium loop rate may be less than 40 MHz.

    Note that there are certain functions that are not supported in the SCTL at all as they take more than one clock cycle to execute.

    Very nice response, nevertheless, I have been very impressed with what speed improvements I have gotten using LabVIEW and FPGA's versus my dual-core 3.0GHz Intel machine.

    Do you know if the latest PXI FPGA solutions that use Xilinx Virtex-5 chips make any improvements on this?

  12. QUOTE (john@aleconsultants.com @ Jan 23 2009, 11:50 AM)

    Yeah, but I don't think you can run complicated algorithms on anything higher than 40MHz

    A little more detail:

    The derived clock (e.g. 200 MHz) can only be used to drive a single cycle timed loop (SCTL) in the LV FPGA diagram. Anything that you put inside the SCTL needs to be able to run within the derived clock period of the loop, e.g. 5 ns for a 200 MHz clock rate. Therefore if you put more code into a SCTL, the maximum rate at which that SCTL can run will be lower.

    A 200 MHz SCTL will in fact be able to run very little code, which will most likely be limited to Boolean logic. Doing any kind of numeric data processing will be limited to significantly lower rates with a maximum loop rate in the range of 40 -100 MHz depending on the complexity of the code. In fact, if your longest code path in the SCTL increases, the maxium loop rate may be less than 40 MHz.

    Note that there are certain functions that are not supported in the SCTL at all as they take more than one clock cycle to execute.

  13. QUOTE (njg @ Nov 13 2007, 10:21 AM)

    The base clock is 40 MHz. Other clock frequencies (2.5 - 210 MHz) can be generated via PLL in the FPGA. Clock options are (40 x num / denom) within the afore mentioned range, where num and denom are integers between 1 and 32.

    Yeah, but I don't think you can run complicated algorithms on anything higher than 40MHz

×
×
  • Create New...

Important Information

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