From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Data Acquisition Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

In order to synchronize multiple cDAQ-9189 with a computer running Windows and DAQmx, may it be possible to get a PCIe card which can act as GranMasterClock for TSN networks?

DAQmx allows to register dynamic events , but how about NI-Scope, NI-Fgen , ....   if you have an event you can route to something in hardware it should be possible to register it also as an dynamic event in LabVIEW.

 

Hi,

 

it would be really nice to be able to set user defined scalings in MAX and daqmx-tasks.

It's possible to do this in common analogue input module like NI-9203, NI-9205 and so on, but I miss this option in NI-9212, NI-9217 and so on.

 

The goal is to set a calibrated scaling to several sensors to get best results and accuracy.

 

Thanks for upvoting my idea!

Yves

Hi,

 

I was suggested to post the issue with nidaqmx not supporting the upcoming version 3.9 of Python in this group. Here is my original post: https://forums.ni.com/t5/Multifunction-DAQ/Deprecation-warning-for-nidaqmx-using-Python/m-p/4051990/highlight/true#M99324

 

In short this is the warning currently seen:

DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.9 it will stop working

 

... it doesn't seem like an issue that would require a large effort to solve, so I hope this will be prioritized accordingly.

 

BR Jesper

 

 

Hello,

 

NI should provide input for DAQmx Create Virtual Channel.vi to set default value for output channel after task starts.

Also, Provide default value in NI-MAX task configuration panel.

 

BR & Stay Healthy, 

Hello,

 

Some of application needs voltage level of 3.3 V, 2.5 V & 1.8 V. (Low Voltage IC families).

In this case we need to operate digital/counter output at desire voltage level.

It will be good if NI provide it.

Also, with reference to following link,

https://forums.ni.com/t5/Data-Acquisition-Idea-Exchange/0-PWM-duty-cycle-with-DAQmx/idi-p/3819545

PWM output can be set to 0% duty cycle (Idle Low) & 100% duty cycle (Idle High).

 

BR & Stay Healthy

Hello All,

 

I would like to know that, why XNET sessions can not be configure in NI-MAX?

It will will be great, if developer can create session in MAX, and use in VI like DAQmx tasks.

 

BR,

Aniket Gadekar. 

After consulting the community and raising a ticket with NI’s support team, we have determined that there is no good way of programmatically removing old or disconnected remote systems.

DeleteDisconnectedSystems.png

I propose that Ni Sys Config pallet be expanded to include a “Delete Disconnected Systems”. This would clear MAX’s cache of disconnect remote systems. Just like the manual method available through MAX.

It would be great if NI offered something similar to the PLC world in the form of expandable IP20 I/O slices that don't require a chassis. It could offer the same kind of functionality in the modules that the CompactDAQ line offers, but without the need to lock into a chassis. I've found myself leaning towards using PLC I/O for some projects where the end-state is a bit murky, but the programming gets really awkward when using third-party APIs like PVI.

The interface to the PC could be similar to that of a cDAQ chassis: USB or Ethernet. Given the applications of most slice I/O users, 24 VDC would be the preferred way to power such a system.

The vi "DAQmx Tristate Output Terminal (VI)" lacks an input to toggle the drive state of the output.

Current version can only tristate - not enable the output. It is rare that you don't need both options.

 

Tri-state DAQmxTri-state DAQmx

 

Without the enable option, it is a superfluous VI which only does half the job.

 

A workaround is straightforward using the technique here https://forums.ni.com/t5/Example-Programs/DAQmx-Digital-I-O-Toggling-Tristate-on-Individual-Lines-in-the/ta-p/3528571?profile.language=en 

tri.png

I've been in many threads and seen many, many more where the root issue stems from confusion about the way DAQmx Timing and DAQmx Read interpret the meaning of "# samples" very differently for Finite Sampling vs. Continuous Sampling mode.   (For example, here's just one of the times I tried to address that confusion.)

 

First, here's what causes the confusion:

 

  • The 'samples per channel' input to DAQmx Timing is *crucial* for Finite Sampling tasks and usually *ignored* for Continuous Sampling tasks.
  • The 'number of samples per channel' input to DAQmx Read has a default value of -1 when left unwired.  However, the *meaning* of this default value is *VERY* different,  resulting in very different behavior depending on whether the the task is configured for Finite or Continuous sampling.  (See the first link I referenced.)

While the relevant info is findable in the help, it also often clearly remains unfound.  I got to wondering whether some changes in the DAQmx API could help.

 

I'll describe one approach, but would definitely be open to better solutions.  The goal is simply to find *some* way to reduce the likelihood of confusion for rookie DAQmx users.

 

I picture adding more polymorphic instances to both the DAQmx Timing and DAQmx Read vi's, so there can be distinct instances for FInite vs Continuous sampling.

 

Further, I picture that the task refnum would carry sufficient type info related to this timing config, such that that downstream DAQmx functions can "know" what kind of Timing was set up -- Finite, Continuous, on-demand (the default if DAQmx Timing was never called at all), etc.

 

Then when that task refnum is wired into DAQmx Read, the most appropriate instance of DAQmx Read would show up.  And the corresponding input parameter names, help, default values, and default value *behavior* can all be tailored to that particular instance of DAQmx Read.  For example, perhaps the "# samples" input should become a *required* input for Continuous Sampling tasks, to force a decision and encourage further inspection of the advanced help.

 

Don't know how feasible something like this is, but it's definitely something that regularly trips up newcomers to DAQmx.

 

 

-Kevin P

Basically, FlexLogger limits the range of readings to the values used in the 2 point calibration.  For example, if your sensor has a range of -10 to 10 PSI, and the 2-point cal is done at +/- 10 PSI, FlexLogger will only display values within +/- 10 PSI (and will saturate otherwise).

 

I totally understand why this is done, but sensors in fact DO read above (and sometimes below) their stated ranges and have documented accuracy (i.e. 1% above 95% full scale) , so clipping the value to the scaling settings in the cal page is the wrong thing to do...the sensor can still be measuring correctly, but FlexLogger will only show the saturated value.

 

The scaling, however it is done, probably result in a Y=mX + b equation, and FlexLogger should display Y, whatever Y is, regardless of stated sensor range or 2-point cal/scaling.

 

A worse case is if the sensor has a range of +/- 10 PSI but your cal/verification system is only capable of +/- 5 PSI, you will be limited to +/- 5 PSI with the FlexLogger 2-point cal implementation.

 

Yes, there are way around this, but why should the user, usually technicians who don't necessarily understand the math or ins/outs of software, have to figure out a way around FlexLogger?

Since version 19, NI stopped distributing the "run time only "installer of DAQ MX. This is a terrible idea.

Here is the thread where no good solution was given.

https://forums.ni.com/t5/Multifunction-DAQ/DaqMX-19-0-runtime/m-p/3994378#M98483

 

Please, NI, if you find it easy enough for the user to build an installer, do it yourself, like you did before.

NI offers some Oscilloscope Devices (see here) but they come with PCI or USB interface only.

These interfaces are good enough for a laboratory device, but they have some limitations if you want to use it in a custom product.

 

I think that an ethernet interface would be a great improvement (it allows a longer cable and it's much more flexible).

For me it is very hard to spot channel that is connected on MAX schematic below:

 

image.png

 

By changing the color of connected channel it is way easier to spot:

 

image.png

On our 845X user manual (http://www.ni.com/pdf/manuals/371746e.pdf ), most of the the minimum timeout can be set to 1000 ms (1 sec). We hope that this timeout can be set to even smaller, less than 1 sec.

Or perhaps there is a workaround to further reduce timeout on 8451?

Howdy!

 

I am trying to use a data acquisition system using python. There are thermocouple  modules and voltage modules that I would like to read from. It is set up and ran in 2013 LabVIEW and I am trying to put the test system into python for easy changing of the test and user control. 

 

I am wondering if the NI-DAQmx python library is kept up-to-date and if this is possible. I have been doing a lot of nitty gritty reading through the documentation on this library because there are not many examples of data collection using python to talk to the NI sensors. After trial and error attempts I have gone back to the basics to try and see if I can even change settings in the configuration of thermocouple channels. All I am trying to do is to take measurements from the thermocouple and I am changing the units from Fahrenheit to Celsius in separate runs. I can't even get this to work, even looking at example of this from Stackoverflow and the documentation where it specifically says how to configure the thermocouple channel (https://nidaqmx-python.readthedocs.io/en/latest/ai_channel.html and Ctrl-F to find thermocouples). 

 

Here is a snippet of the code I'm writing:

try:
    with ni.Task() as task:
        
        #Add the thermocouple channels to read from NI-9214's
        task.ai_channels.add_ai_thrmcpl_chan("cDAQ1Mod1/ai0:11", name_to_assign_to_channel='',
                                             min_val=0.0, max_val=100.0, units=ni.constants.TemperatureUnits.DEG_F, 
                                             thermocouple_type=ni.constants.ThermocoupleType.T)
        task.ai_channels.add_ai_thrmcpl_chan("cDAQ1Mod2/ai0:7", name_to_assign_to_channel='',
                                             min_val=0.0, max_val=100.0, units=ni.constants.TemperatureUnits.DEG_F,
                                             thermocouple_type=ni.constants.ThermocoupleType.T)
        
        #Set the thermocouple type to T
        #task.ai_thrmcpl_type = ThermocoupleType.T
        
        #Add the voltage channels to read from NI 9209
        task.ai_channels.add_ai_voltage_chan("cDAQ1Mod3/ai0:7")
        task.ai_channels.add_ai_voltage_chan("cDAQ1Mod3/ai9:12")
        task.ai_channels.add_ai_voltage_chan("cDAQ1Mod3/ai19:27")
        task.ai_channels.add_ai_voltage_chan("cDAQ1Mod3/ai29:31")
        
        #Set the rate of the Sample Clock and samples to aquire
        task.timing.cfg_samp_clk_timing(rate=Hz, sample_mode=AcquisitionType.CONTINUOUS)
        
        #Set the ADC Timing Mode to speed up the collection
        #task.ai_channels.ai_adc_timing_mode =  ADCTimingMode.HIGH_SPEED 
        task.ai_channels.ai_adc_timing_mode = ADCTimingMode.AUTOMATIC

 

This is a little frustrating to filter through the problems because there is not much out there that has the python use for help. If you search in the documentation search, the links of the results that you can click on are broken so that is another pitfall to this method.

 

Any help is greatly appreciated but I am curious if NI will keep the python library updated and running for future use.

 

NI-DAQmx python documentation: https://nidaqmx-python.readthedocs.io/en/latest/index.html 

Stackoverflow example help: https://stackoverflow.com/questions/47479913/python-nidaqmx-to-read-k-thermocouple-value

Thermocouple example: https://www.youtube.com/watch?v=NMMRbPvkzFs

As documented in a previous post, it is currently impossible to install the nidaqmx-python library into a Docker container. Enabling this functionality would create an opportunity for software teams to build cutting edge big data pipelines for measurement instruments using container technology. This could also optimize development time by including custom DAQ code in continuous integration pipelines.

Not sure if this should be in another category, but here is the idea.

 

In DAQmx you  can register for events like Change Detection Event, Sample Complete Event, etc. These events occur in the Event structure.

 

Idea: Extend this capability to NI-Sync.

For example allow a future time event to occur in an event structure, instead of firing a TTL pulse. The steps would be:

1. Create a new NI-Sync instrument driver session;
2. Read the current time of the clock;
3. Define when the event will be generated by introducing a delay to the current 1588 time;
4. Program when the event will occur at the specified time;
5. Register for Event
6. Event Occurs - do something.
7. Clean Up

See below for diagram.

mcduff

FutTimeEvent2.jpg