Idea Exchange "Idea Declined for lack of measurable Kudo rate" policy needs to be amended

[Intaris]

I think we need an "Endangered" grouping of Ideas for, say a month before they are declined.

That way we have a last chance to give the ideas a look-over before they get sent to the glue factory.

[Bob_Schor]

A number of years ago, I discovered that NI's Query Input Devices, used to find Joysticks so you could use the Joystick VIs with LabVIEW, would, in some cases, fail to "show" a Joystick that was visible in Window's Device Manager, and showed up in DxDiag's listing of DirectInput devices (usually toward the end of the list).  In discussing this with an NI AE (on a Support call), he surmised that this function was written to only return the first eight entries, and suggested that I write an Idea Exchange to request this be "fixed".

I did, and I believe it was declined.  In May, responding to a Post on the LabVIEW Forums from someone who couldn't "see" his Joystick using Query Input Devices, I posted again on the Idea Exchange, and invited the Original Poster to Kudo my idea in the hopes of getting this remedied.  There have been several other related posts related to "gaming" inputs (most recently, a Logitech Streering Wheel), and I've now gotten 4 (wow, four!) Kudos.

This is clearly not a Hot Topic, nor one that is going to result in increased productivity for LabVIEW Programmers.  But it does seem like an "oversight" on NI's part in a "dark corner" of the Windows landscape they may have overlooked, thus less likely to be noticed.  It is also possible that there is an inherent reason why Query Input Devices is limited to returning only the first 8 non-mouse, non-keyboard DirectInput devices under the "Joystick" array-of-devices.  If this is the case, it might be nice if the Help message says something like "This function can only return the first 10 DirectInput Devices, the first two being Keyboard and Mouse, and the rest classified as "Joystick".  If your PC has more than 10 such devices and your Joystick is at the end of the list, you are Out of Luck, tant pis" (pardon my French).

So, is the Idea Exchange an appropriate instrument to bring a possible "short-coming", maybe even a "flaw", in an NI Function to NI's attention (as suggested by NI Support)?  If the only way to get an Idea "elevated" is to have numerous Kudos (and, conversely, if Ideas are declined for lack of Kudos), this seems to be a not-so-good mechanimsl to get things fixed.

Bob Schor

[altenbach]

For reference, a link to Bob's idea is here and I voted for it even though it is unlikely that I will ever bump into the problem. I hate artificial limitations!

I agree that artificial limits are not good and there are several cases where limiting decisions were made early on and never revised. For example it is often a problem that boolean to 0,1 returns a I16 instead of a I32, but it probably was a reasonable decision on the original Mac where memory was at a premium. Other things got fixed, e.g. the flattened representation of boolean arrays increase 8 fold in LabVIEW 5, but made a lot of things easier.

Currently, the maximum number of parallel FOR loop instances is 256 (default is 64, higher requires a configuration change). However, Intel just released a Xeon processor with 24 hyperthreaded cores (48 virtual cores!) that allows up to 8 CPUs to be combined (192 real cores or 384 vitual cores), so we are obvioulsy hitting another wall in a few years once all this trickles down to the typical system. ( $7k+ per chip is a bit prohibitive at the moment :D). A while ago I had to recompile my program so it could scale to a 48(96) core system. I cranked the limit to 256 which should last a few years. 😉

Maybe back in Windows 95 only 8 input devices were possible?

NI itself bumped into artificial (windows in this case) limitations early on. For example the AT-MIO-16-E1 ISA card required to be shown as two devices in the W95 device manager because it needed more resources than can be allocated to a single device.

[Intaris]

Oh, speaking of artificial limits, try allocating more than 1048576 named queue references without closing them.

Bang, LabVIEW hangs.  Apparently the Queue manager in the background somewhere is limited to 2^20 references (apparently shared across all queues) and will hang LV if you try to allocate one reference too many.

We found this out via a bug in our software but the find was surprising to us.  A standard error out of the "obtain Queue" would have been nice....

[X.]

I don't believe there is a limit on the number of kudos a post can get, so feel free to raise awareness of artificial limitations (hmm, sounds a lot like artificial intelligence, doesn't it?).