In certain circumstances it would be helpful to see exactly what license file ties to each piece of activated software within NI License Manager. This would be an additional field in the right hand pane of License Manager as shown below.
The Embeded Data Logger and Waveform Data Logger could have some sort of array (either two 1D array or one 2D array) allowing to create custom parameters to the TDMS file. The array could be defined in the SDF or during operation using a LabVIEW VI to pass data to it.
If your project performs data acquisition of channels as Waveform data type(instead of single point), you can't associate this channel to a Aliases. Since the waveform data type receives a buffer of data, you could choose some common options for that channels, such as max buffer value, mean among others.
Since it does not exist, I had to create an workaround by acquiring data as single point and logged them using embedded data logger, then had to use Diadem to create the waveform channel.
In addition, it would also allow to acquire data in higher rates because the waveform acquisition loop runs ins parallel to the PCL.
This feature would be extrememly handy for those who are using waveform acquisition and logging, and would save me some months of work.
I have detected a small but cumbersome problem witch at the end of the day can grow to a problem with heavy impact related to security updates.
In the actual release, the NI Volume License Manager can disable the NI Update Service on the client machines if the Administrator of the Volume License Manager sets the option “Disable NI Update Service on all client machines”.
Now, for example, there is a scenario on witch clients get the License for a DIAdem installation from the NI Volume License Server and get the License for a LabVIEW installation from the local License Manager.
The problem is, that the user cannot update his LabVIEW application using the NI Update Service because it is blocked by the administrator of the NI Volume License Manager for the DIAdem installations.
There should be the possibility to disallow the Updates by Products instead of disallow the whole NI Update Service.
With best regards
Please check the following thread for additional info:
Specifically, the last entry includes a couple of ideas:
he last comment seems to support the observation that having to register the instruments manually in MAX could be done away with. seeing how coding is complex enough as it is, removing this step makes sense because it is manual and redundant.
i'd be most grateful is this could be implemented in a future release of NI VISA.
and, while at it, could you guys look into implementing VXI11.2? I believe Keysight has had that as part of their VISA implementation for some time now. with VXI11.2 GPIB control over TCPIP is virtually complete. granted, HISLIP might do just that but because it takes time for new hardware to materialize supporting this new flavor of LXI, implementing VXI11.2 might provide value for some time.
Let's say, a LIN scheduler is running with 5 different entries.
One frame will be sent completely with payload by the master, this frame is visible on the bus monitor, and if I create a Frame In Stream session.
For the other 4 frames in the scheduler, the master sends only the header to the bus, and expects a slave to fill its payload. If there is no response from the slave, the frame header is not "visible" for the Frame In Stream session.
In this case, upon calling the XNET Read.vi I would see at least the frame ID without payload (empty payload).
In our test cases, we want to see and log all activities on the LIN bus. Currently we see only completed frames. So if we don't see a frame expected from slave, we don't know:
- whether the master does not send the header
- or the slave does not send its payload
I was made aware of the System Configuration VIs a while back and tried to use them to help manage a fleet of PXI stations at our facility. I was working with renaming of cards to common names, calibration of cards, and self testing of cards. For some reason these functions were not made to work with PXI hardware, most of them only work with Real Time hardware. Which doesn't make sense.
The kinds of tasks mentioned are important for managing the PXI chassis. And I'm sure there are a few other functions that could be added to make managing them a lot easier also.
IDEA Summary: Please make all System Configuration VIs usable for PXI hardware. Also please keep in mind any other functionality that would be good for a person that has to manage a large number of chassis that are over a large area.
I am using MAX in all projects to define channels and create tasks.
Functionality that I think should be added:
- Drag and drop channels to reorder them ( there is no way to do that now...)
- Ability to create subfolders and group channels inside them like Ai AO DI DO CO.
- Ability to sort and search
- When i import channels from ini file to max, order of globl virtual channels should be equal to what is defined in ini file.
I have multiple workstations which are all offline on purpose on a standalone network. They never see the internet, and this is where I do all my LabVIEW development and utilize whatever tools I build.
To keep up with software update requirements as dictated by the Government organization I work under, I have to keep software updates as close as possible to an up-to-date condition. For some reason when I finally decided to update to LV2014 DS2 disk set, something went wrong and the first thing I thought of was the update directory I copied off anotether machine which was on the internet and had received online NI LabVIEW updates. I have found that far too much time is spent finding, sorting through NI download files having inconsistant naming conventions, doing whatever research is possible to assure an update won't breaks oemthing else, downloading , and then manually executing these updates in the correct as NI Update Service tool would. (And hopefully in the correct order)
So after some thought, I came to the conclusion that there is an easy way to manage this, the NI Update Service tool could manage this with the addition of a monthly or bi-monthly update configuration file. A file similar to what other software tools use out there to manage what the recent pataches are for let's say Microsoft as an example, or McAfee's A/V definitions. Belarc Advisor is really the tool that led me to this moment in time and thought. They have update config files which contain the latest versions of MS patches and security updates listed so when you run the tool it tells you what needs to be executed to get MS back up to date. Of course this is really useful if off line and one doesn't have the MS update service running.
So my idea is to modify the NI Update Service tool providing a version that has a switchable user mode to run the tool in an offline condition. It would need to have the tool look at a default location where the new u[pdate files would be placed by the user. The initial tool config file would need downloading or a basic get started config file could initially be installed off the DVD set. Then the user could execute the tool which would dump out a detailed desription of what the current installed LabVIEW version is, all modules, any patches, and where to of course find the latest version NI Update Service tool config file. In addition, the output file would provide a detailed list of all available patches, updates, and up[grades along with download links for each so the user knows where to retrieve them from saving even more user time. This to me would eliminate the current method of user uncertainty and allow updates to be applied in a more timely fashion with consitancy across multiple machines and completeness.
That will be SUPER, if you can add extra option till pop-up menu "Create/duplicate Device as Simulated".
And reversed option (to create Device from simulated one) when you will like to test software with real hardware.
That will be also necessary to do check box to select, which you will like to use. For Tasks purpose, they have to also know which one they have to use.
there is my question\ suggestion - I am using MS 13 - and have to use a lot of bus connections in my design.
when I do connect wire to bus , MS opens for bus entry connection window.
so far so good.
but some how I can see only 6 top lines in that window directly and the rest with scrolling down.
the window could be re sized to show more \all lines, but after I click OK button and have to open that window again - it again appears with 6 top lines shown - it means that window does not remember it was re sized a moment ago.
and it becoming really annoying if I have to connect a lot of wires to the bus.
bus vector connection window does remember resizing instead .
the problem is I can not use vector connections for separate wires (not IC leads)
could it be reconfigured?
could it be fixed in next version please?
thanks a lot
We have more than one full-time LabVIEW developer. Each developer may work on several projects per year. Each project may include several pieces of NI hardware. Currently (2015) the NI Product Registration Wizard doesn't provide the options needed to make effective use of the features that NI's HW registration system provides. At the very least, one additional field for string metadata could be added. The back-end wouldn't have to change much, just keep the e-mails flowing to the primary Username in the wizard. As long as we keep our metadata string consistent, we could handle the other fields when our general account gets an e-mail. Please refer to the picture below:
Thanks for your consideration,
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.
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.
Right now, Update Service will not update the current installation of LabWindows/CVI but install the new version in parallel.
An option to choose if I would like to upgrade or keep the old software would be much more convenient.
i would like to propose the idea to apply labview in raspberry pi
you have a robot lego called mind storm can you use labview in raspberry?
raspberry is a bery fast growing community it would be very interresting to apply labview in it
When we have to develop add-ons for Veristand, we need to search into examples and existing add-ons to find how to implement some basic or advanced functionalities.
For example : using the node browser control in a labview dialog box, or finding the list of the optional inputs for custom workspace.
This is really time consuming !
Veristand is missing documentation for add-ons developpers. It would be good to have a Reference Manual like in TestStand.
Just in order to know if an operator deployment license (no editor nor stimulus profile editor) is schedule for the next releases of VeriStand ?
This would be helpful for users who don't need these functionnalities on the the deployment computer.
Thanks in advance,
It would be really nice to have the ability to create groupings for the Remote Systems in MAX. Below is the list of my current targets. While I'm sure there are many people that have a longer lists of targets, I find this list a little bit unmanagable already. Additionally, we are either planning or working on projects that will about double this list.
Please add the ability to group the remote systems so that they can be managed in their own tree (or somthing similar)
right now, if I invoke nivlm.exe /exportClientPermissions C:\foo\bar.txt, I don't get any information about disconnected licenses.
It would be great if it had a column for disconnected license expiration date associated with each item (that would be empty/null if no disconnected license was assigned).
Would also be helpful if there was also information about home use licenses grated against a user.