LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Damir

Build/Index array element index tip

Status: New
Tip strip on build array should show the index of input when you connect wire/probe - element[i]. The same on index array when index inputs are not wired. It's wery annoying to find element[27] on build/index array.
10 Comments
RavensFan
Knight of NI
Can you give an example of why you need this such as a screenshot of the current problem?  I don't understand what you mean by "element[27] on build/index array".
Damir
Member

Build_array1.jpg

 

 Counting of index is best when you use touchpad or low cost mouse, when probe

is jumping up and down.

 

Index_array1.jpgxx? Perhaps 27.

 

 

RavensFan
Knight of NI

If you need to stretch out an array that far, well, maybe the architecture needs to be rethought.  You have a lot of elements that are coming out that aren't being used at all.  Are they there just to allow you to get to #27?  You do know that the left hand input allows you to enter a constant for which element gets called?  So for your right hand example where you are getting 0, 1, 2, 3,, 10 (that wire needs to be cleaned up), and let's say 27, you only need 6 elements shown,  0 through 3 can be left blank on the left, the next can have a 10 to the left and the last would be 27.

 

One other problem is that if you have anything other than a constant wired to any element above it, the actual element number is undefined at edit time.  For example if one of the elements above, or that element itself, has a wire going in that is the result of a calculation where the actual element indexed is programmatically defined, then you don't know if that is element 27 or any other element during edit time.

 

Beyond that, I think your idea has some merit has long has the caveats I mentioned are considered.  If any element number is not statically determined, then it can be element [27] but would have to show up as element [??].

 

Message Edited by Ravens Fan on 09-20-2009 11:55 AM
Damir
Member

In fact, I need them all. I just wanted to ilustrate that I'm forced to count outputs every

time I connect wire or wire them consequently. In fact, the idea is only to know which element from top to bottom I'm connecting on. For my sake, it can be even 1 based. Or even function block could have small numbers beside/in place off small squares.

 

 Graphic1.jpg

 

 

I've missconected wire on Index array with only 7 elements.  My typical app has 250 I/O points (cRIO), and I must be able to probe any vire/data fast all over application, so I use very "flat" design. Named vires would be also great. Debugging methods in LV are somethimes not adequate, when you have industrial app with large number of I/O.

In ladder diagram, you can watch complete diagram states. My other post on status of loops also comes out of the same problem. I do polling of several inputs in flat sequence because I'm just to slow to navigate trough state machine with case structure. On one machine I have manual override of complete system. It is crucial to be fast if something goes wrong and do manual override/stop. But in general, I must say that LabVIEW is realy great for ultrafast developing. It is fine you can adapt programming style to specific needs of every day wider scope of programming in LV.

Intaris
Proven Zealot
I' not going to say if I'm for or against this but surely the numbers must begin at zero.....
Chris_Koci
Member
This numbering of indices would also be very useful for the Decimate 1D Array and Interleave 1D Array primitives.
Sam_Sharp
Trusted Enthusiast

I was just about to post this idea and then found it through a search. I can't believe it doesn't have more Kudos - it's such a simple idea and from a usability point of view, humans can only mentally 'count' anything up to about 5 or 6, so if you have more terminals than this you need to count them one-by-one.

 

This is what prompted me to post the idea:

2015-12-21_16-53-23.png

 

Showing the element index in the context help and tip-strip (if not on the primitive itself) would be exceptionally useful!

 

This is especially useful when you're combining wired/unwired indexes.

 

In this use case, I'm picking out binary data bytes from a serial message.


LabVIEW Champion, CLA, CLED, CTD
(blog)
tst
Knight of NI Knight of NI
Knight of NI

> I can't believe it doesn't have more Kudos

 

I agree that it's tempting, but I think the main issue I have with this is that the index value can be confusing, as here it's clearly referring to the index in the node, but logically, the important index is the one in the array, and that's not something which can be guaranteed, as sometimes the index comes on a wire which is set at runtime. There are possible solutions for this (such as "show the actual index when possible and show nothing otherwise", which actually seems reasonable), but I'm not sure how badly I want them.


___________________
Try to take over the world!
Sam_Sharp
Trusted Enthusiast

Yeah, to be useful it would absolutely have to be the index of the element being indexed out (e.g. Element[x]) and not the 'terminal number' of the primitive - which is pretty useless. I don't particularly like the idea of displaying the numbers on the primitive (and I'm sure it would add a lot to the complexity of the primitive). Just displaying in the context help / tip-strip would be sufficient for me.

 

If the indexes are dynamically determined, e.g. from a wire, then show the original tip-strip as it currently stands (or something like Element[??]). In my case, I'm taking arrays of a fixed/known length and picking out individual bytes for parsing binary data packets, they are statically defined - in this case it would be useful to know the byte number I'm pulling out.


LabVIEW Champion, CLA, CLED, CTD
(blog)
jordankuehnsef
Member

Not having to count which index I've placed this wire on would be great. Just add it to the tooltip. On the index array it would be awesome to show on the output side what index was wired in or auto-indexed.

qAA5nrjIpc.png