Jump to content

Question

Posted

I am using the OMB-DAQ-2416 to measure using (9) thermocouples and (11) analog voltages. The thermocouples are on Diff channels 0 - 8 the analog inputs are on SE channels 11 - 15 and 26 - 31. Programming is done using Python.

I am able to configure all channels with no indicated errors. Also everything seems to be fine when I take measurements using ul.v_in_32 and ul.t_in methods from the ul.py library. However, when scanning using the ul.a_in_scan method (to read from a continuous background scan) my SE analog voltage values no longer read correctly (they seem to clip at the minimum voltage range (BIPT078VOLTS). If I remove the TC channels then scan the clipping issue no longer seems to be present, but only one SE input reads correctly. I am having trouble understanding why this would be (that one method of reading data is correct and the other isn't with the same configuration).

This seems like a lot to convey through a forum, but could I get some assistance on troubleshooting this? I will try to clarify if needed.

 

Thank you, TB

ul_a_in_scan.png

ul_t_in_v_in_32.png

4 answers to this question

Recommended Posts

  • 0
Posted

Hello @tycbrown32.

Please test the attached MCCULW Python example, usb_2408_2416.py, with your OMB-DAQ-2416 daq device.  usb_2408_2416.py

The example configures four analog input channels.  Make the necessary code changes to match the first four channels wired on your device.

Regards,

Fausto

  • 0
Posted

Hello @tycbrown32.

MCCULW is the MCC Universal Library Python API for Windows.  Did you configure the channels in MCC's InstaCal utility first?  Which version of InstaCal are you using?

BIPT078VOLTS is the input voltage range for thermocouples.  What is your analog input data rate?  As mentioned in the USB-2416 User's Guide, "since thermocouples can pick up noise in your environment, select a data rate based on the primary noise frequency. For example, to reduce the effect of 60 Hz noise, select a data rate of 60 (or a sub-multiple of 60, such as 10 or 20)."

Can you share your code to review?

Regards,

Fausto

  • 0
Posted (edited)

Appreciate your quick response!

I did try configuring in InstaCal (v6.74 for Windows) thinking that might be my fix, however that caused me to not be able set up at all (program could not find an eligible range). Should I not have to run configuration in my program if I use InstaCal?

I attached a snip of my code for setting up my channels, the code used to configure the channels that calls the channel setup, and how I am defining the channels.

My SE channels are configured first, then the TC channels. It is interesting to me that the already-configured SE channels seem to be overwritten when the TC channels are configured. I have observed it in Debug mode where the eligible range for the SEs is selected to be BIP10VOLTS (expected). I have not been able to see that they change when the TCs are configured (I haven't figured out how to pull that info after the configuration stage), but they do seem to clip or be limited to the TC range.

Possibly related, if you see the comment in line 220 of the set_up_channel code. I am unable to explicitly tell the channel input mode to be SE unless the channel number is less than the maximum number of differential channels (in other words: I cannot explicitly tell the AnalogInputMode of channels 17 - 31 to be SE).

 

Thank you, TB

 

Edited by tycbrown32
  • 0
Posted (edited)

Thank you for that, @Fausto.

After looking at that example I was able to discover my issue. My understanding of how to set up the channels was incorrect. Instead of configuring them individually you configure the differential channel which consequently configures the pair of SE channels that make up that differential.

Once I reconfigured your example program I was able to establish the appropriate methods for configuration and was able to troubleshoot my program. It only took me about 30 minutes to find and fix from that point.

It turns out that my issue was in the a_in_scan of my start_analog_input_scan function. I was using a variable for my range that got redefined when configuring each channel. The last input channel configured was a TC type so that was the range being used for my scan.

- TB

 

Edited by tycbrown32

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...