Filename are different in Embedded Data Logger and Waveform Logging (VeriStand 2014) :
Embedded Data Logger : <Hour>_<Minute>_<Second>__<Day>_<Month>_<TwoDigitY
Waveform Logging : <FourDigitYear>-<Month>-<Day>_<Hour>-<Minute>-<Sec
Why timestamps are differents?
The format of Waveform Logging should be prefered, with year on four digit, month and day first (sorting file is immediate), hour in 24 format.
The Update Service supposedly already checked in the background and found I needed updates.
Yet when I say “view updates” it makes me wait on a progress bar while it checks for updates.
And then when I click “Upgrades and Service Packs” it has to check AGAIN with another, extra-slow progress bar.
It should just do all the checking in the background, retrieve the full list of updates, and stop interrupting our work to wait on progress bars.
[Edited on 8/28/2014 by moderator Diego Carvajal (dcarvaja)] [Image included in original post as requested] To help debug medium and large real-time test sequences, it would be very useful if there was a sequence step that allowed the user to specify a console message.
Much like the Print Debug String VI helps debug issues when building custom devices, this step would allow the developer to insert specific console flags and see what part of his/her real-time sequence is executing.
Dear NI community,
let me describe you one of my ideas.
It would be good to have a feature of "copy-paste" simulated devices in NI MAX. One creates a device, setups it, selects it, copy Ctrl+C and paste Ctrl+V - and device will appear below in the list of hardware.
For example, I was now adding four 1-slot cDAQ chassis, with measurement module. Chassis are the same, modules also - we have such setup (don't tell, if something, that we could use 4-slot chassis, b/c it was requirement to have 4 separate chassis). So, I had to do the same operations (create chassis, add device, rename) four times, and it took like 2 minutes approx. But in case of copy-paste feature, it would take 30 seconds, no more.
The current Device Driver Installer dialog is not obvious to use. First of all you have to figure out which drivers that you need for your products and then you would probably prefer to remove other unnecessary drivers. However, this is a tedious process with a lot of dependencies.
I have seen many people just installing everything (with its drawbacks) to be safe, eventhough they only needed the NI RIO driver.
I'd like to see a more user friendly dialog where drivers are automatically selected.
My suggestion is that the user instead filters out the drivers on a product level like this:
Let say you choose Modular Instruments. Then next page could let you filter on what type of instrument you have; Scopes, FlexRIO, DMMs, RF, Switching etc...
One of the buttons in the bottom would be something like "Add more products?" so you could iterate this process and finally all needed drivers would be filtered out.
What do you think?
/Pelle - NI Sweden
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..
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.
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 ...
I/O Trace is extremely useful when debugging system-level text-based applications. Error handling for systems involving multiple drivers + software packages (RF toolkits, for example) is very difficult. After recognizing there was an error, we still have to determine which device threw the error and then query the appropriate driver/toolkit with the correct handle to determine what the error was. NI I/O Trace is a great way to quickly determine which device threw an error and at which function call. Unfortunately, the error reporting returned by I/OTrace is pretty limited. For example, consider the I/O Trace shown below of an application synchronizing two waveform generators. A property is not configured correctly for one of the generators. I/O Trace clearly indicates there is an error, however the exact cause of the error is difficult to discern from the message:
The actual error message is: “The Sample Rate property can not be configured if OSP Enabled is VI_TRUE. “. It would be great if I/O trace could provide the entire error description. Compare this to the LabVIEW error handler:
the company I work for designs automotive infotainment products, and we used products from NI extensively in product validation an testing, including TestStand, Labview, DIAdem, FPGA, RT. etc...
In order to simplify license management, we chose to used the NI Volume License Manager (VLM). This provides centralized managment of licenses, including easy addition and removal of licenses, as well as license recovery from PCs no longer in service (broken or decomissioned by IT).
Since I am the technical lead for test system development, it falls to me to perform license capacity planning, request disconnected licenses, manage license groups, and all the other administrative things that go with license management. I am not, however, in the IT department, and since the VLM runs on a Virtual Machine inside the VM park, I always have to request license changes from our IT specialists.
I would very much appreciate it if there were a tool to remotely administer the VLM. This would allow the IT department to give me access to just the VLM to perform administrative duties there, sort of like the MMC in Microsoft Windows Server lets users administer remote servers.
The custom Device allows to include in the name of generated files a timestamp, with this format: %<%I_%M_%S_%p_%d_%m_%y>T
Today, my customer prefer something like %<Y%m%d_%H%M%S>
Tomorrow? I don't know.
Having a format string configurable from System Exlorer would be really convenient.
For security reasons, many customers using Volume License Manager to administer licenses to client machines do not authorize users to download and install anything from the web. Therefore, if a critical patch is released, the client machines are unable to download this unless it is distributed by the administrator. It would be useful for the VLM administrator to be able to configure the Update Service such that all Users can run the Update Service but the service has been configured to point to an internal network share rather than an internet location outside the firewall. This way, the administrator could make critical updates and patches available for the client machines and the clients can be notified and install them.
The only way to edit the order of VeriStand workspace screen pages once they're created is to edit the cryptic XML file where screen pages are referred to by numbers. I'd like to be able to reorder the screen pages from within the workspace. Thank you.
VeriStand suppot 32 and 64-bit aligned fixed point data: http://zone.ni.com/reference/en-XX/help/372846G-01
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.
In LabVIEW, we have a lot of options for saving our projects as seen below:
In VeriStand, currently, you only have the option for a normal save (as shown below). I think it would be nice to have a "Save As" for saving a copy of the project and, if possible, a "Save for Previous Version".
Mapping in VeriStand 2011 consists of only text, but user could grasp the whole mapping if the number of connections is increasing. So, visualized mapping tool like dSPACE ConfigurationDesk as below image must be good user interface for users.
I have many procedures that check for certain conditions before completing its intended function. If a precondition is not met, the procedure exits. It'd be nice to be able to pop up dialogs as necessary. Right now, in order to do so, I have to have the procedure call other alarms if I want any sort of feedback/popup which gets convoluted pretty quickly. Thanks.
If you want to exchange a model you have to reconfigure many things. You could use Aliases to reduce the effort for the Workspace and Workspace Tools.
But in the System Explorer you can only use Aliases for Calculated Channels.
Please make it possible to use Aliases also for Mappings, Alarms and Procedures.
As the Idea : Controls for macros , it would be nice to add screen controls in order to handle with procedures !
For the moment, VeriStand RT procedures are only launched using alarms !
It could be usefull to be able to launch or stop procedures using screen objects. (Like the Model controller !)
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).