Invisible dynamic array...

[RSibagatullin]

I know the number of columns but don't know the number of rows of a 2D array. In addition I don't want the user to see this array. I want it to use this array for internal purposes only.  How should I do about creatin this array? Should I create it via formula node or there is a way via LV. Thanks.

[altenbach]

You probably would need to provide a bit more details, but typically you can keep a 2D array in a shift register. Initilize it with a 2D array with the desired number of colums and then append new rows as needed using "built array", for example.

[RSibagatullin]

For some reason it is very hard for me to deal with the arrays located in the shift registers since to me it seems thery unnatural way of working with arrays. I think I can't break my C thinking.
Will it be OK to create a regular array and make it invisible programmatically and  operate it via property in the code?

[altenbach]

---

RSibagatullin wrote:
For some reason it is very hard for me to deal with the arrays located in the shift registers since to me it seems thery unnatural way of working with arrays. I think I can't break my C thinking.

---

If you want to program in LabVIEW, you need to become familiar with shift registers. There are one of the most efficient way to operate on data in-place and usually provide a very elegant solution if done right.

---

RSibagatullin wrote:
Will it be OK to create a regular array and make it invisible programmatically and  operate it via property in the code?

---

You need to change your thinking. Operating on arrays via value properties is one of the least efficient ways to do things and will be literally ordes of magnitude slower and less efficient.

For a related discussion, see the following posts and the links in it:

http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=327057#M327057

If you would be a it more specific on what you are trying to do, we might be able to get you started. 🙂

[tst]

---

RSibagatullin wrote:
I think I can't break my C thinking.

---

To work efficiently in LabVIEW, you need to stop thinking of "the variable" and try thinking about "which data is flowing through that specific wire". Wires are not variables, but they are the closest thing you have in that they are used to transfer data from one point to another. Using controls as variables is tempting (especially once you discover local variables) and on some occasions may even be legitimate (cue rotten tomatoes now), but it's not natural to LabVIEW and is definitely not efficient. It also has the potential of creating race conditions, which in a parallel language like LabVIEW can be very easy to create and very hard to find if you're not aware of how things work.

Incidentally, you can do what you want (by right clicking the control's terminal), but I would advise against it.

[RSibagatullin]

Here it is. I did not use any properties. I only used local variable to shift data from frame to frame. Please criticise my code  frame2, subframe 4.:-) Basically I form the power spectrum measurement table.  I think auto-indexing started to make sense to me.

[Captain_Kirby]

One quick comment.

I noticed a number of "Coercion Dots" within your code (pictured below.)



Coercion Dots are generally a bad idea to have in your code. Its usually a much better solution to explicitly convert you data types (see below.)



Coercion dots add unnecessary memory overhead. In simple applications, its not a problem, but its not a good habit to get into. Just a friendly tip. By using the explicit conversions, you also get tighter control over how the conversion is done (through the properties of the conversion VI.)


Message Edited by Captain Kirby on 06-04-2008 09:03 PM

[altenbach]

---

Captain Kirby wrote:
One quick comment.

---

Well, you don't really want to add more code 🙂 Simply righ-click the diagram constant and select the desired representation.

To the posted VIs....I'll look at them later.

Message Edited by altenbach on 06-04-2008 08:31 PM

[TCPlomp]

Here's a little improvement of your array handling:

The code is not optimal but should execute a lot faster.
I would store the GPIB port as an integer number.
I would use enums to store the X, Y, units and measurement mode options

Ton


Message Edited by TonP on 06-05-2008 07:48 AM

[altenbach]

See also my old answer here: http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=326824#M326824

I really don't quite understand what the issues is on this new thread. Somehow wer're not getting anithing new.

• How is this VI supposed to be used?
• What is the purpose of these long 20 second delays?
• How is the operator supposed to interact with the controls?
• Which are used as controls and which as indicators?