Jump to content


  • Content Count

  • Joined

  • Last visited


Posts posted by aledain

  1. Have you looked into using datasockets and "publishing" your data from your RT units? Depending on how much stuff you're looking at, this could be quick enough for you.

    Also, RT on FieldPoint Ethernet modules also allows you to configure 'Fieldpoint Tags' through MAX. These tags can be accessed as for any other FP tag (ie read, write or read/write) from both the RT and the host. This provides a simple comm's to embedded FP RT's.

  2. Every time I pass an array for one VI to another LV allocates memory from windows to make a copy of my data (buffer allocations is the slowest operation in LV after display updates).

    This doesn't happen under all circumstances. If you're careful about it you can reduce memory copy operations to just those at application start. IF the same wire (talking arrays here specifically) goes into and comes out of a sub-vi, then the memory is (sometimes) not copied within the sub-vi. The array is passed by reference (if you get my drift). Within that sub-vi, a copy is made only wherever a 'branch' occurs where that branch undergoes some transformation (eg branch 0, nothing; branch 1 * a constant) OR if the array is not manipulated in-place. So in the example, if you return branch 0 and branch 1 from the sub-vi then you have duplicated your data (and a copy will have been made). So if the sub-vi modifies the data, make sure that the change is done 'in-place'.

    Some array tools are specifically designed to be used in place, such as the replace array element. Using these in-place tools will not force a copy of the array. Think of it as processing the arry by substitution directly into the memory itself. If you need to allocate an array within a FOR loop (for versions prior to about 6.1, I believe) the only 'in-place' way to do it is to pre-allocate, use the replace array element and truncate the array post loop.

    Another thing to watch out for here is the use of indicators on the sub-vi's panel. If you run within the dev environ, then having a ~MB array branch to an indicator just for the sake of viewing the data, may mean a memory allocation, and will certainly slow your application (as you say) due to screen updates.

    Furthermore, when a wire goes through a case structure, make sure at least one case has nothing happen to the wire. This (IIRC) enforces the 'by reference' passage of the data.

    And while we're at it, did you realise that wiring your array into the top node of a multiple/add etc is NOT the same as wiring it from below. The top is best.

  3. If you drop the numeric constant from the numeric palette it is automatically selected but is 'blue' because it is an I32. Type your number while it's selected but finish with a '.' and the type changes to DBL. It works for any I32 on the BD that has never had its representation changed. Once it's been changed it's broken wrt of this funtionality.

    Only found this the other day after 7 years of RMB/Representation/DBL :headbang:

  4. Of course the last person to touch the code 'own's it' so this is another reason for being open about the situation and biting the bullet about doing a ground up recode.

    :yes: Ownership of the problem. Hmmm. Do you reckon this is unique to the software world? Perhaps its a 'fundamental' aspect of our development world.

    I always use the examples of telling the car mechanic to fix my flat tyre after he services my car. Similarly the builder extending my house doesn't believe the death of my wife's plants is his problem either. Another good one is the washing machine mechanic not getting my whites 'white and brighter' after a repair! :laugh:

    Imagine if other service industries 'owned' problems! When I use these examples, clients seem to appreciate why software I 'patched' at their request doesn't seem to work quite right anymore.

    cheers, Alex.

  5. Experiment with "Customise Control", you can change a slider into a codeless radio button with care.

    However do you really need a radio button? If there are 3 or 4 options, just use a slider set to I32, line up some text and you're set. The function is the same (selecting just one option).

  6. This brings up a pet peeve of mine. If you select the label to be visible on any structure, the label comes up with the less-than-useful information of 'For Loop" or "While Loop" and the label text is NOT highlighted to allow easy typeover, which is inconsistent with every other labelling function in LV.


    You're right, never noticed that ... how bizarre. It's like the labels on the LV functions themselves.

    As intuitive as graphical programming is,  the myth that LabVIEW is self-documenting is just that.


    :thumbup: It is a myth that any language is self documenting. Even a text based language where MyFunctionDoesThis = AllTheInputs(AreLabelledThus) won't help after the core code has been dumped from your brain. I am eagerly awaiting my brain upgrade but I think that the hardware might not be able to handle the new software :)

    cheers, Alex.

  7. First thing to do would be to contact NI if there is a chance that they may take it back. If you have a good relationship with your local sales rep this should not be a big problem, but don't wait to long. They have limits how long they may take back stuff and they will charge you a restocking fee of some percentage.


    This is mentioned in the license agreement. You cannot sell it without informing NI of the transfer of ownership. As follows:

    Transfer. If you have a single seat license or if the SOFTWARE is Multiple Access Software, you may transfer the SOFTWARE to a third party provided that you notify NI in writing of such transfer (including the name and location of such third party), such third party accepts the terms and conditions of this Agreement, and after such transfer you do not retain any copies of the SOFTWARE (including all Upgrades that you may have received) nor retain any of the written materials accompanying the SOFTWARE. NI may, in its discretion, charge you a fee for the transfer of the SOFTWARE. If you have a volume license, an academic license, a student edition license, a debug license, or an evaluation license, the license is non-transferable and you may not distribute or otherwise provide the SOFTWARE to any third party or (with respect to a volume license) to any of your sites or facilities not expressly identified in the applicable documents from NI.

  8. As a rule of thumb, and a very broad and nebulous thumb at that ... and I can say because I definitely DON'T know when it will be released, but it works out to about every 18 months* per release.

    As Jim indicates the bigger and better, the longer ...

    * Based upon a broad consideration of my dim recollection of things and not based AT ALL on any actual release dates.

  9. Mousing over with the wiring tool can get you a description, if you enter it. If the wire is connected to a control, you will even get the name of the data but that is usually self-evident anyway. It's the intermediate data that really needs labels, even if you chose not to have the labels visible due to space constraints.


    So you can enter a description of the wire and you can triple click and get it's source and destination ... so do you need a label? I used to think so and used to paste the clear type text over my wires but over the years have let that go. You're right its a pain the &%&^%& to move them whenever you change the diagram and the new auto-wiring is sure to help ...NOT. But, I how many people show and label their FOR and WHILE loops? I would guess close to 0.01 %, as most people wouldn't even know that the labels are there!

    Not to start a slanging match (I agree a nice flowing label such as you get with VISIO (or other such sw) connectors would be nice), but comments are WHY not WHAT and with an intrinsically visual medium such as LV I think a well placed comment will serve much better that labelling a wire, and for that purpose the desciption suits.

    What would be a thing to wish for is having that description "visible" or not, at the flick of a preference switch. Now that is what I'd wish for!

    cheers, Alex.

  10. A good way of getting around this is to flatten the image using the Flatten to String.vi and send the bit string over the DataSocket Write. On the receiving end, the string must be unflattened with the Unflatten from String.vi before being displayed in the image indicator.


    Be carfeul using FlattenToString with Datasocket. In the LV 6.02 version (and perhaps higher versions but I've never checked), DS recognises \00 as the terminator of the string (ie DS is a 'C' API and resolves 'C' style terminated strings). Flattened strings sometimes carry the \00 within them and the decode on the other end doesn't work because the entire string is never received by the DS Reader. You will need to bypass this with some smarts to make it a truly robust transfer.

    cheers, Alex.

  11. A more general approach to this problem can be overcome with Datasocket. You can setup the DS Server and have a common socket eg dstp://localhost/myglobals that the two exes Write and Read (easier for beginners than TCPIP because you can link these direct to a control on your panel[1]). There are other issues that you WILL want to address such as synchro at start, race conditions while running, etc.

    cheers, Alex.

    [1] Of course even easier is to use a file stored in a common area but if your exe's will ultimately live on separate networked machines then DS could serve your needs.

  12. Not an answer but a suggestion, but their are two types of tab containers in Stanf=dard LV. One is from LV, the other is OS. They are found in the "Array & Cluster Controls" and the "Dialog Controls" palettes respectively. Perhaps try the other one?

    Hang on! :lightbulb: Doesn't the PDA module give you a new set of controls? Are you starting from a "New PDA VI" or just building it from scratch? Perhaps this might explain it?

    cheers, Alex.

  13. In this VI, the DLL doesn't have the 'size of the array' as separate parameter.

    What are the 'problems' using this VI in a while loop?


    Cannot view your code because I don't have 7.1. If you post the DLL function call someone may be able to suggest more relevant information. I don't think in general there' any issues with calling a DLL function within a loop, provided your inputs and outputs are setup correctly.

    Otherwise with DLL's you must (usually) preallocate your array before passing it to the DLL (if it takes an array as input). Use the array initialisation tool for this (see attached).

    If the DLL returns a single value then use a replace array element after the call and a shift register the store the array (see attached).



  14. But how do you then react on a button-press without having to decode the position for each control (on your panel that is then behind the picture control) and manually react on the mouse press (then again you are without the event-structure)?


    Don't know other than to have a picture control "customised" into each control (ie multiple controls). I think when I used it before it didn't matter if the picture control was behind another control (but I might be wrong). Alternatively place as many picture controls under as many controls as you need to react to. I have used this technique with a cluster before, but it was a long time ago.

    What exactly are you after? A flyover or drag and drop. The picture control works for flyovers. For the drag and drop there was an article in LTR about 2000, 2001 ? On creating a drag and drop interface. Pretty sure that predated UI events.

    For a clickable interface you could cutomise the picture control to have an image the same size as the pic control and "hide" the other bits of the control itself. The property node would then return True if the mouse is pressed (left or right). You could pass this into a data change VI (ie returns T only on F->T) and poll for "clicks".

    cheers, Alex.

  15. Thanks, Alessandro.

    I was kinda looking for something like a read-only attribute.


    Under Options\Miscellaneous you can check "Treat Read Only as Locked". Could that help? If the file is read-only then the user cannot edit it.

    cheers, Alex

  16. Yes, I know I should have said: to avoid the need to install/download OpenG(1), and if you don't need/want OS independent code, and you're not interested in mixed EOL characters, and, and, and, ... but I thought I had covered that with "smooch" :)

    1. although you should've done this as the first step after purchasing LV, IMHO.

    P.S. Michael, I will always welcome corrections! That's how you learn! In this case however, the code was just using the tool with the EOL as delimter as a quick solution.

  17. Jim, I was under the impression that LabVIEW PDA will run on any device with PalmOS 3.5 or higher, as NI's PDA Page seems to indicate.


    That's correct, LabVIEW applications can be built to download to Palm and PocketPC. I am not sure, however, whether you need two separate licenses for the two different platforms :question:

    cheers, Alex.

  18. I recommend to use the chart and set the chart history length to a value that probably won't ever be reached. For actual computer with 256MB and more memory this is not a problem. Chart updates are done much more efficient when LV handles it internally than when written in LV.


    That's true, but by changing your if you can change the "function requirements" you can/may gain speed and avoid the hang. For example, don't, allow the user the use of the hand, but instead add a new control (slider) to control the scrolling. Next, if the update rate is slow, set the viewed portion to some fixed subset and "max/min" the intervening points (say by an enum {All points {Slow}, Last 2048, Last 1024, Last 356, Last 218, etc}). This will mean a quasi-decimation of your data, but will be faster to update.

    Combining controls to appear to create a "control" can be powerful; of course RAM is also sooooooo cheap too :D

    cheers, Alex.

  19. In general the core data that is relevent to a function - should be contained in that function - and no where else. For instance the GPIB address of the device does not need to be a global, its only important to the GPIB Read and Write core functions know the address.


    Yes. This is one of the "achievements" of an Object Oriented Programming (OOP) approach (regardless of language). It's all about the "data hiding". By specifying the object's interface you can control how the object is utilised.

    Interestingly enough a functional global (LV2 style global) by implication becomes an "object", albeit a singleton (single instance). At its simplest it will be just a container, but at it most complex can be a functional component. There was a LabVIEW book written using this componentisation. Personally I prefer OOP (ie GOOP) because when I start a project I never know when the client goes from wanting "one is all we'll ever need" to "can we have four of those". Usually its at commission time :D

    cheers, Alex.

  • Create New...

Important Information

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