Additional NI Software Idea Exchange

Dear NI R&D folks.

It is wrong the time zone for Caracas at the Time Settings configuration (MAX 14.0) . Since december 30, 2007 has been changed to -4.5 UTC. I will appreciate if you correct this bug in future LabVIEW versions.

Best regards.

Jesús Hidalgo.

This is a bit of a feature request for the service request manager and/or as a stand-alone (my NI web) tool!  

It is needed because the NI webpage makes it terribly hard to search for CAR#'s and a CAR# is only listed when solved, and only listed for the one version where it was resolved, making it nigh-on impossible to check lists of (new) CAR#s and get notified when they are resolved.

For example, I know this CAR exists, but I'm not sure if it has been resolved and the NI search just didn't find it, or if does not exist (user input error for example) or anything..

1. The tool should reside on "my NI" but it should be possible to export/share the list of monitored CAR's (so colleageus/companies can maintain one master list of company relevant CAR's).
2. The tool should connect/check against NI (ideally directly to a back-end database) and return any "public" information related to a CAR, such as "in progress", "known work-around", "details" etc. along with driver/software version where it was resolved (if any).
3. The tool should present a clear list (ideally with green checkmarks / red cross icons) showing the status of each CAR and maybe a synopsis/one-liner from the description to indicate what problem the number is for.
4. wish-list added feature:  allow (on a per user basis) the user to add personal notes to a CAR (e.g. this affects projects x, y and z, once resolved, refactor those projects to remove performance intensive work-arounds!) or similar.
5. e-mail notification (optional/configurable) when the status changes on any of the tracked CAR's.

As far as how it relates to the service request manager, I would prefer a separate tool but that it also can link to the service request manager as outlined below:

A small but significant number of tickets either relate to, or create one or more CAR#'s (or at least mine seem to create a large amount of CAR's).

When a support tech adds / associates a ticket# with a CAR#, ideally this CAR# would be automatically added to the user's CAR Tracking list..

In addition it would be great if the back-end database tracked CAR#'s and offered up a list of these numbers in the webpage overview, for example next to the "status" column. Taking it a step further, it would be very nice if NI could make it simpler to check if a CAR has been resolved and if so, what version of LabVIEW it was resolved in/with. This information could be displayed in the same web page table, or a new page to itself. The "Status" column could then also be expanded with a green check-mark if (all) associated CAR#'s have been resolved..

Tracking CAR's and manually trying to search and check them off lists locally is labor intensive, especially since the web-page "search" does not do even a passable job when you enter CAR numbers.

Hello,

I got a cDAQ 9184 connected to a PC running Vision Builder. The IO-Channels on the 9184 are connected via global virtual DAQmx channels. These channels are available on Vision Builder.

When power is cycled on the 9184, Vision Builder does not reconnect to it. You have to close and restart Vision Builder to get it running again.

My Wish is that Vision Builder is able to reconnect automatically.

Best regards,

Klaus

I was thinking for very large systems that use the same channel configuration for multiple channels on the system configuration can be very tedious. A work around for this is the API to build a system definition file but for those customer's with limited or no LabVIEW or .NET experience this isn't valid. 

Since we can test the IO channels in MAX by creating tasks for all of our hardware I would like to add the ability to pull the configuration information from a task we've created in MAX and apply them to our channels in VeriStand. So in stead of setting MIN, MAX, input configuration, shunt resistor location and value for 100 channels I can configure it in one location (MAX) and apply the settings to all my Current Channels. 

The other issue is if the channel doesn't support all the configurations from each page then we need to contact NI support to add functionality. Recently I worked with a LVDT sensor for a SCXI chassis. This allows customers to have an instant workaround rather than having for NI to allocate resources to update the page.

By adding MAX task to act as the template for our channels we can edit the parameters for all channels of the same setup from one location (MAX) vs each individual page. This also allows you to test individual channels instantly in MAX to make sure the configuration is valid without resolving other errors across the whole system definition.

Again this is more for deployments where they have 100s of channel similarly configured where configurating each channel is tedious but they are not unique.

Hello,

It would be nice to add a tool like RAD (NI Replication And Deployement utility) directly into MAX.

But a RAD compatible with all Targets LabVIEW Runtimes.

... a kind ok target cloner, saver , restorer ... 

Manu.

I was asked to post this here instead of in the VLM forum:

Every time there is a new update of LabVIEW we typically hunt down the installation disks from ni.com as soon as they are available, and start the process of making volume license installers...(Or, if the update seems less exciting, we wait patiently for the shipped DVDs). 

I wish it the whole provcess could be made smoother. Based on the volume license installers we have, the VLM could simply subscribe to newer versions.

When 2014 comes out, the package would automatically go out to all the VLMs out there, and new volume license installers would pop up on our local VLM as soon as the software was ready...OR, alternatively, the VLM could be hosted by NI instead (possibly supported by a local VLM for offline use), so that the process of creating new installers were really done by NI (or automatically by NI hardware that is) based on whatever setup we as VLM admins had chosen...and the source material from NI.

(This idea came about as a side note to this related discussion about LabVIEW cloud services).