Additional NI Software Idea Exchange

In the everyday life of a SW developer, it comes again and again to the fact that problems arise, and must be solved.

It must be weighed again and again whether a problem resulted from own errors or whether the cause of a problem is to be found by errors in the development environment or in used modules such as xNET, DAQmx etc.

It happened to me several times in the past that I looked for errors in my own LabVIEW source code, but afterwards I realized that the cause of the problem was a malfunction in LabVIEW or in one of the used drivers.

In order to become aware of possible problems as early as possible during this troubleshooting process, it is important to be actively informed about possible problems inside of the NI Modules.

For example, it would be helpful to be notified with an email in the following cases.

- A new entry in the Known Issues and Bugs list

- The new possibility of a workaround

- Availability of a bugfix in a new LabVIEW or driver version

My suggestion would be the following:

Would it be possible to provide within the NI account settings a list of modules in which you can choose the notifications for the different Modules?

Whenever something in the known issues has changed the NI account member would get a notification via E-Mail.

It would also be possible to make entire subgroups or subject areas selectable.

The technical implementation is certainly possible in different ways. Crucial is that there is the possibility of an active notification for changes in the different known issue lists.

Hi,

We try to connect on "EXTERNAL" opc ua server (like injection press, data acquisition systems, ..) that generate custom notifiers.

The weakness on OPC UA toolkit is that it is a closed environment.

I am able to connect the toolkit on the notifier and catch the event with actual tool, but all data of the event (plots, values, ...) are unreachable (UA expert show them).

A very simple Python code is able to retrieve these data, but there are out of the labview environment, and as it has to create a thread on the notifier, I am unable to run such structure through the Python tools in LabView.

Some example:

A shortcut of ENGEL structure

Event registration need filtering, ENGEL

Event registration need filtering, Kistler COMO Neo

Data in each event, Kistler COMO Neo

Thanks in advance.

When testing, the beauty of automation is, that we can do the same test on many instances just by copy & pasting the code and modify the in-/outputs. Unfortunately, the stimulus profile editor is not know for it's usability when it comes to copy & paste or even applying changes to multiple lines at once.

Now what would be a great addition here, would be to actually rely on the hierarchy of channels (the prime example are CAN Frames). I want to perform the same test, using different CAN Frames that contain some signals for a motor.

MotorLeft_Status/Position

MotorLeft_Status/Speed

MotorLeft_Status/ErrorBit

MotorRight_Status/Position

MotorRight_Status/Speed

MotorRight_Status/ErrorBit

To perform the same test on these signals, I'd have to call a realtime sequence with all of the above as parameters. What I want to do, is just give the Top-Level Path (MotorRight_Status and on the next call MotorLeft_Status) to the sequence and then within the sequence, read the actual signals that I need from this CAN Frame.

The same could be done for the physical signals of the motor if they're organised nicely.

RT time is not the same as PC time unless you:

1) manually set PC and RT time so the y match

2) configuring the PC and RT Linux to sync to an internet NTP time server (requires a special configuration on the RT target)

3) configuring the PC and RT Linux to sync to a NTP time server on the local LAN (requires a special configuration on the RT target)

Why is it important for the computer time to match or at least be within a few seconds? Because the logfile name is based off of PC time and the data timestamps are based off of RT time.  If the time between the computers don't match, confusion exists as to why there are different times.

A very simple solution is to sync the PXI time clock to the PC time when the Veristand project is deployed.  At least for a few days the timestamps will be within a few seconds of each other.