Data Acquisition Idea Exchange

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

I need to frequently check the existence of an overtemperature or any health parameters of the NI card PICe-6323 for my application.

I am using the DAQmx ANSI C library for my application.

 

I have tried using the DAQmxGetReadOvertemperatureChansExist function but found that's for C Series Devices.

 

Please help me out.

Note: this might only be relevant & useful for multiplexing AI devices.

 

It was an important technique used to investigate channel-to-channel ghosting influence on a multiplexing device.  For example, suppose you had a large signal A and a small signal B.  You could set up a channel list to read "A,B,B,B,B", and thereby *investigate* the trend of these successive readings of the same channel and use *evidence* to determine when the ghosting influence had dissipated.   THIS WAS IMPORTANT!

 

I recall hearing of others use the capability to be able to get faster sampling for one of their fast-changing channels, using a channel list along the lines of "A,B, C,B, D,B, E,B".

 

The feature that used to be supported on multiplexing MIO devices as far back as I could remember working with NI DAQ products.  I only recently discovered that such support was inexplicably removed from DAQmx sometime in the last few years, now producing a fatal task error.   I tested a few available systems and found that it was still supported under DAQmx 16.0, not supported by DAQmx 18.1, and not yet restored as of DAQmx 20.1.  (All verifications were done with desktop or PXI X-series devices.)

 

Why was this ability taken away?   Stop being so overzealous trying to protect us from ourselves!  Multiple readings of the same channel is a legitimate and sometimes almost necessary technique.  Maybe you lacked the imagination to understand why we'd want this, but guess what?  We knew what we were doing.  So stop stopping us.

 

 

-Kevin P

Attempting to add a channel (Ch8) to an existing task which already uses that channel as a result of having already assigned its paired differential channel (Ch0) results in that channel correctly not being added to the task but also does not generate a warning or error.  Thus when attempting to configure a task with 2 channels as Ch0 differential and Ch8 RSE, the resulting task only contains 1 channel.  This may be not be apparent because the channels 0 and 8 appear as different from each other.  Having a warning could give notification of this fact. 

 

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019KxoSAE&l=en-US

 

While using NI USB-6008/6009, I am encountering a strange error which I have failed to find the source of it. As you can see, there are 2 types of outputs. When I comment out one of the outputs, other one works fine. However, when I use them both, it gives me an error as shown below in the picture. What could be the problem?
Error : Invalid data format for digital channel
However, error direct to analog output.Error.JPG

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,

 

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

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

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.

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.

Counter tasks can only take 1 channel, due to the nature of timed signals, obviously. When setting up a system with 16 DUTs with counter outputs, this requires 16 tasks. Every single one has to be painstakingly created and configured. (As an aside: Defining a tabulator sequence still seems a mystery to NI's programmers, even though LabVIEW supports this)

Wouldn't it be nice to have a Ctrl+c,Ctrl+v sequence for tasks and then only modify physical channel? IMHO: yes.

 

KR

nimic

The DAQmx API is extremely useful; one especially useful part of the API is the automatic logging feature. This part of the API is efficient, easy to set-up, and largely bug free, well-done NI.

 

One problem with the automatic logging feature is the value of the t0. This value is determined by the system clock, which is the clock onboard the controller. A lot of PXI systems have the ability to use GPS modules or other timing modules. It would be good to use this clock instead.

 

In NI-Sync we can create an event at a specific time and use this to trigger the DAQmx data acquisition. It would be nice to use this "event time" instead of the system clock. There is a property in the DAQmx Timing Property Node, under Advanced, called First Sample Timestamp:Value Property. However, this property is read only, please change it to writable also. In this case we can then write an exact GPS time start to the data acquisition.

 

Below is one simple use case of the property node.

 

mcduff

snip.png

 

 

 

When doing PWM with DAQmx, error -200684 is thrown if a 0% duty cycle is attempted.  For situations where a true 0% is needed, this is problematic. There are a few workarounds available, but some are less than ideal.  

 

The suggestion here is to pause the output if a 0% duty cycle is attempted.

This Topic is base on other topic in PXI Forum (Link).

The main problem is the Range passing the Min/Max limitation.

 

I would like to simulate a channels in "Nominal" Case.

1. The range should be based on the Min/Max limitation.

2. I could select input style (Sin Wave, Triple Wave, Random in sub range, DC with error range, based on external data,...)

3. Near to Real timing simulation include cases of sync between different channel rates.

 

Currently,

1. The range is limited to the Min/Max Values. Excluded the cases show below.

2. Only Sin Wave. Excluded an Odd Case show below.

3. I tried case of sync between 2 channel with different rates. the simulation is not close to the real DAQ case. 

 

 

Here are the cases from the PXI Forum (Link😞

1st problematic case

1. Define a Simulated Device - PXIe-4353 in MAX.

2. Open "Test Panel"

3. Use the default parameters of the test:

  a. Measurement type - thermocouple

  b. Max Input Limit - 100

  c. Min Input Limit - 0

  d. Units - Deg C

  e. Thermocouple type - J

  f. CJC Source - Built In

4. Click Start.

 

The result is Sin Wave.

The sample values range ~[-1030,-74.7], out of the Max/Min Limits.

=> BAD sample results, values lower than -273 C ?!?!?!?!

 

2nd Problematic Case

If I change the Max/Min Limits to other valid range like [-200,1200]

The sample values range is BAD

And, the result is some kind of Non-Sin Wave

 

3rd Non-temperature Case

If I change the Measurement type to Voltage.

The sample values range is based on the Max/Min Limits.

=> So it is OK

 

Tnx,

Raz

 

 

In NI MAX, mV/(m/s^2) should be added to the available choice in the dropdown menu for accelerometer sensitivity units.

 

(Currently avaliable choice is only mV/g and V/g)

When a DI change detection task runs, the first sample shows the DI state *after* the first detected change.  There's not a clear way to know what the DI state was just *before* the first detected change, i.e. it's *initial* state.

 

This idea has some overlap with one found here, but this one isn't restricted to usage via DAQmx Events and an Event Structure.  Forum discussions that prompted this suggestion can be seen here and here.

 

The proposal is to provide an addition to the API such that an app programmer can determine both initial state just before the first detected change and final state resulting from each detected change.  The present API provides only the latter.

 

Full state knowledge before and after each change can be used to identify the changed lines.  (Similarly, initial state and change knowledge could be used to identify post-change states.)

 

My preferred approach in the linked discussions is to expose the initial state through a queryable property node.  The original poster preferred to have a distinct task type in which initial state would be the first returned sample.  A couple good workarounds were proposed in those threads by a contributor from NI, but I continue to think direct API support would be appropriate.

 

 

-Kevin P

Today, we can create a DAQmx custom scale in MAX or Labview via the "DAQmx Create Scale" VI. This VI changes a pre-scaled value, e.g. 5Volts, to a scaled value in a physical unit, e.g. 100Newtons. This scale can be Linear, Map Ranges, Polynomial or Table.

For all of these four options, only a mono-channel sensor can be used.

 

However, multi-channel sensors are not so rare and there is actually no way to scale a 6-components load-cell, for instance. For this kind of transducer, F = M*U where F is a 6-components vector including the 3 forces in Newtons and the 3 moments in Newtons*meters, U is a 6-components pre-scaled vector including the 6 input channels in Volts and M is a 6*6 matrix. M is never diagonal, because the forces affect the moments.

 

Finally, what I'd like to have is an extension of the "DAQmx Create Scale" VI which could enable a multi-channel pre-scaled input to be scaled in physical units through a matrix.

 

Thanks.

Hi,

     i need to create a vi with 16 bit channel output to show a waveform graph and my point is i need to display a list and the user should select which channel they want to display in a graph.

For example, if the user wants to see a graph for the channel 1 & channel 2, whatever it is, up to 16 channel, is anybody got a idea? that what i was telling actually.

The term "Incomplete Sample Detection" comes from DAQmx Help.  It affects buffered time measurement tasks on X-series boards, the 661x counter/timers, and many 91xx series cDAQ chassis.  It is meant to be a feature, but it can also be a real obstacle.

 

How the feature works ideally: Suppose you want to configure a counter task to measure buffered periods of a 1-channel encoder.  You use implicit timing because the signal being measured *is* the sample clock.  The 1st "sample clock" occurs on the 1st encoder edge after task start, but the time period it measures won't represent a complete encoder interval.  Reporting this 1st sample could be misleading as it measures the arbitrary time from the software call to start the task until the next encoder edge.

   On newer hardware with the "Incomplete Sample Detection" feature, this meaningless 1st sample is discarded by DAQmx.  On older hardware, this 1st sample was returned to the app, and it was up to the app programmer to deal with it.

 

Problem 1: Now suppose I'm also using this same encoder signal as an external sample clock for an AI task that I want to sync with my period measurement task.  Since DAQmx is going to discard the counter sample that came from the 1st edge, my first 5 samples will correspond to edges 2-6.  Over on the AI task, my first 5 samples will correspond to edges 1-5.

   My efforts to sync my tasks are now thwarted because their data streams start out misaligned.  The problem and workaround I'm left with are at least as troublesome as the one that was "solved" by this feature.

 

Problem 2:  Suppose I had a system where my period measurement task also had an arm-start trigger, and I depended on a cumulative sum of periods to be my master time for the entire system.  In this case, the 1st sample is the time from the arm-start trigger to the 1st encoder edge, and it is *entirely* meaningful.  On newer hardware, DAQmx will discard it and I'll have *no way* to know my timing relative to this trigger. 

   Older boards (M-series, 660x counter/timers) could handle this situation just fine. On newer boards, I'm stuck with a much bigger problem than the one that the feature was meant to solve.

 

So can we please have a DAQmx property that allows us to turn this "feature" OFF?  I understand that it'd have to be ON by default so as not to break existing code.

 

 

-Kevin P