Jump to content


  • Posts

  • Joined

  • Last visited

Posts posted by SuperS_5

  1. The property node can be set to "ignore errors." This stops this propagating the error down to the other properties. (Incoming errors still cause the node to skip execution though.) In this mode, the first error is outputted, while execution continues.

    P.S. - moreover, you can't call a property node of the same class from within a member access vi of the same class that has a property node.

    I believe we have done this in LV2010. The same code works in LV2011, but I don't think I have tried creating this scenario in LV2011. (Property node>property node of the same class.)

  2. I assume that you are using LV2010. (From your profile) We just recently upgraded to LV2011, and it a lot more stable. We had a lot of problems where LV would become very flaky when editing classes. (particularly if you tried to click faster then LV could finish loading screens, or had a lot of windows open. I never tried too hard to isolate the problems) Of course, there may be limitations, but if it is possible, I recommend upgrading.

    • Like 1
  3. I have to agree with Daklu. I only start to use any kind of flow-charts/Pseudocode for very large programs. I usually define these when the program must be split up so that multiple developers can work simultaneously. On one project, I used the state chart module fairly effectively for a single developer.

  4. I you use the "separate compiled code from source" option, clearing the object cache may help. It is in some where in "my documents/LabVIEW data/". If the VI uses any ctl files, I would check them first. I have found that corruptions in type-defs to occur way too often. We now use 2010 SP1, while being a little more stable, we still see this kind of crash often.

    Good luck

  5. There are several white papers and various forum threads on the use of parallelized for loops. I believe it is not very useful to nest parallelized for loop. Not wiring the P terminal, will yield a number of threads equal to the logical processors. I think the way you have nested these for loops will cause twice the thread count, and not be more efficient then a single parallelized for loop, nested with another regular for loop.

    If you can reproduce the issue, you could submit it to NI on their forums.

  6. You can get the classic windows theme, which is settable globally for your whole system. It is included with Windows 7. Several WinXP themes are also available, again settable globally. It is also possible to "disable visual themes" for LV. (or any application) This is accessible via the application properties pop-up from the context right click. As for LabVIEW only, WinXP theme, you would have to make customized buttons.

  7. As mentioned, a daemon always polling for updates is the most robust method. This allows for the updater app to make significant changes, without user interaction. The main app can update the updater whenever necessary. (Would eventually be very infrequent) Either by the updater sending an "update me" message, or the main app polling.

    A simplistic approach is to use batch files. Your app will poll for updates. When found, create a batch file that completes the copy, and restarts your app. In the most sloppy method, running the batch file (without waiting for the return) and immediately exiting can work. This is also the fastest to create, but harder to maintain over time.

  8. Hi,

    I am still learning about LVOOP, but here is the little I do know.

    A static dispatch VI is mostly a regular VI that is owned by the class.

    A dynamic dispatch VI is sort of "similar" to a polymorphic VI. For each of these VIs, a replacement can be made for each child class. (A class can be a child of a class, of a class, ... etc) If the child class is used instead of the parent class, the "replacement" VI would be used instead of the original dynamic dispatch VI.

    These replacements are defined by the same connector pane, and VI name. (The owning class name will be different)

    The connector pane specifies if the VI is a dynamic or static dispatch VI. Right click on the class input/output connectors on the connector pane > "This connection is", and you may choose [required, recommended, optional, dynamic dispatch(required)]. If the dynamic dispatch option is chosen, the VI is a dynamic dispatch VI. If any of the other 3 are chosen, then it is a static dispatch VI. (Both input/output connectors for the class have to agree)

    An accessor VI is a template for accessing the data from the class wire. This VIs are used as "gate-keepers" to the data. Making them dynamic dispatch allows for different behavior depending on the input class.

    The dynamic dispatch VIs have a noticeable overhead during execution, and loading. It is always better to use a static dispatch VI unless your really need the dynamic dispatch.

    PS. Darn....Paul replied first.....lol

    • Like 1
  9. Definitely reproducible. It does not crash if only the cluster is inputted, only for the array. Adding a label to the array did not help either. (I had seen that be a problem before.) I originally thought it might be a corrupt cluster, but recreating it from scratch did not help.

    I have LV2010sp1 -32bit on 64win7

  10. Hi,

    I have been looking at your VI. I would completely remove the "plant.vi" simulator. That is where your DAQ calls could go. (That's the simple approach) The LabVIEW example finder will help you with the DAQ calls. You need to output your pid value. and get the level. I wouldn't personally use this single loop approach because it is not scalable, and would not be responsive enough if the output valves have to be driven more slowly. There are a lot of examples in LabVIEW, and on Google to get you started there.

  11. If you want to manually pick where each of the measurement areas are, cursors may be a good start. It would be easier once you have the cursor positions, to calculate the periods. Trying to pick those measurement points automatically would be a whole lot harder. The signal processing toolkit may help there....and a whole lot of work. Manually, your main challenge would be to make a UI that is fairly intuitive.

  12. Hello,

    If I had custom drivers for an instrument/device, how can I "import" them to Labview so that I can use it to communicate with the device and acquire data?

    Thank you in advance

    It depends on the driver. For DLLs you can use the "Call Library Function Node." You have to know the function calls, the node will try to guess only the function names. Each function prototype must be entered. .Net stuff can also be used as well to communicate to the driver.

  • Create New...

Important Information

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