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.
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".
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
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.
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.
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:
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.
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.
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.
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.
