aledain

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.

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.

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:

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.

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).

Having just received the list of LabVIEW champions (http://www.ni.com/devzone/lvzone/champions.htm), I realise my name was omitted from the list ;-) I think my original idea (http://forums.lavausergroup.org/index.php?showtopic=76&hl=) has been subverted somewhat. I still believe our own comunity based recognition would serve the community better than a corporation led one.

You're right, never noticed that ... how bizarre. It's like the labels on the LV functions themselves. :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.

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.

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.

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.

See this for starters: here and there is a set of utilities called lvwinutil32.zip or smowthing smiilar floating around that has all the hard work done for you.

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.

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.

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! 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.

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).