JRys

Hey Bill, I misread your post. Email your device model and serial number to info@mccdaq.com and we will email you a PDF of the calibration certificate. Thanks, John

The EU Declaration of Conformity (ISO/IEC 17050-1:2010) is listed in the back of the user manual. Below is an example from the USB-1208FS-PLUS user manual. If you are looking for something else, email your request to info@mccdaq.com. Make sure to include your device model and serial number.

Hello, The USB-1208HS is a good device and will meet your requirements. Something to think about is that it uses multiplexing to switch the channels one at a time to the A/D converter. This mean there is a small time skew between each of the channels. Sampling four channels at 100k Hz (400k samples per second) would result in approximately 2.5uS between each channel. If you were to bump up the sample rate to 250k Hz per channel (1M samples per second), the channel-to-channel time would drop to 1uS. There is a scan option called BURST mode that forces the channel-to-channel time to the minimum, but it's not available in our ULx for LabVIEW support. If you wish to have virtually no time skew between channels, consider the USB-1608FS-Plus or the USB-1808X. These devices have a per channel A/D converter to read the inputs at the same time. Regards, John

your system pretty much matches mine. I check my /usr/local/lib folder and there should be a file named libuldaq.1.dylib (3.3M). Also, a file name libusb-1.0.0.dylib (192k). Here's what mine looks like:

Hi Fergal, You are correct, the buffer is maintained in the driver. This allows us to use a small hardware buffer and this is true for most of our devices. For many applications, a large buffer is unnecessary because it can be update during operation. In the following example, the buffer is update while running. It writes the same data (for simplicity) over-n-over - first updating the low half then the upper half of the buffer depending on the index location. https://kb.mccdaq.com/KnowledgebaseArticle50719.aspx Regards, John

We have uldaq running on a MacBook Pro with the M1 chip running the latest macOS 12.4 (Monterey). I can only speculate that maybe it is building to x86_64. What is the output from "gcc --version"

UPDATE: the attached make file builds to a 64-bit specification allowing files greater than 2GiB. Copy it to the following folder overwriting the existing file. daqhats/examples/c/mcc118/data_logger/logger. Use "make clean; make" to remake the executable and it will (should) create files larger than 2GiB. makefile

change directory --> \libuldaq-1.2.1\examples\ run the following ./AIn and ./AInScan if they run, then the driver is installed and it's the Python stuff giving you fits.

did you notice an error during the ./config && make, if so the following may help:

Hi Lorenzo, Do you get this error with the ULDaq python examples? What is the HW device and which example? Thanks John

the following was taken from a Stackoverflow forum thread: "On Linux, write() (and similar system calls) will transfer at most 0x7ffff000 (2,147,479,552) bytes, returning the number of bytes actually transferred. (This is true on both 32-bit and 64-bit systems.)" This answer more than likely includes functions like fprintf() used by the logger example. In other words, we use 32-bit c functions for the logging to file operation, which limits the size to 2GB.

Hello, The count variable is a Long number type, so it is a signed 32 bit number. A negative buffer size make no sense, so the maximum is half that or 2,147,483,647. But ultimately, it will depend on what your system will allow. John

Hello, I ran ULAI01 from our C# example library using the demo board and didn't have this problem. Hoping for a clue, I searched "NullReferenceException" in our support database and found that it could be caused by having multiple copy of our DLL's and CFG files. Search your hard drive starting at the root "C:\" for the following: cbw32.dll, cbw64.dll and cb.cfg. The correct locations are as follows: C:\Program Files (x86)\Measurement Computing\DAQ\ (for the two DLLs) C:\ProgramData\Measurement Computing\DAQ\ (for the CFG) delete any copies that are not in our folders. Thanks John

Hello, In general, to have a MCC product repaired or calibrated send an email to info@mccdaq.com. Please include your contact info as well as the model and serial number. If it's more than one year old, you will receive a sales quote to order the requested service. Best regards, John

Hi Bryan, The USB-3103 is not an item that can be sent in for repair. However, it is cover with our 1-year warranty, so you're eligible to get a new replacement. You're in our database so I have your contact info. I will reach out to you by email with an RMA number that isuse to return this unit. Best regards, John

Hello, The external clock input does not require a 10MHz signal. Use a square wave with the frequency you wish to collect data. Are you creating your program or using a software package? Thanks, John

Hello Marcel, Use the following https://www.mccdaq.com/downloads/LabVIEW2021_ULx/. The installation will find both of version of LabVIEW. My suggestion is to install to 2021 instead of letting the installer update both. I'm not sure which device of ours you have, but you will also need the InstaCal utility. Make sure it is in InstaCal's board list. Best regards, John

Hello, Could you start up InstaCal and view the Help-->About InstaCal page. Does it report version 6.73? If not, download our latest CD and install it from it. (uninstall is not necessary) Use the following URL: https://www.mccdaq.com/downloads/MCCDaqCD/mccdaq.exe This is a self extracting image of our CD. Follow the unpacking instruction to get the opening screen. Let me know if I can be of more assistance. Regards, John

Hello, Two installations are required to get the PersonalDaq/50 series to work in DASYLab. The first one is the Personal DaqView software, which installs the drivers. Here’s the installation for that: https://www.mccdaq.com/downloads/iotech_software/PersonalDaq50_Series/pdaqviewsetup_x86_x64.exe After installing the above application, Plug the PersonalDaq/55 into the USB port and wait at least 30 seconds and check the green power LED next to the USB connector – it must be on. If it is not, then it is not compatible with your Windows 10 system. A few customers were able to fix their systems by updating the BIOS drivers. My new Dell laptop didn’t work at first until I updated it. I was surprised to find 14 critical updates. Next, copy the attached file to C:\Program Files (x86)\DASYLab 2020\pool\packages\. Run DASYLab’s Configurator 2020 utility and select the Packages page. Locate & open Unsupported Drivers and enable IOtech PersonalDAQ/5x Series. Restart the computer and you should be all set. You will find the PersonalDaq/55 inputs on the following menu: ModulesInputs/OutputsPersonal DAQ5x Best regards, Measurement Computing

Posted on behalf of a customer Hardware: DAQ 56 Software: Dasylabs 2020 Operating System: Windows 10 Problem Description: We are using the DAQ 55/56 data acquisition interface. I've installed all of the driver recommended for the device and Dasylabs but it will not recognize the IOtech DAQ 56. Please advise. Best Regards

Hello, The WebDAQ 316 channels are not electrically isolated, and each has a reference resistor connected to ground (COM). The design is such that an accurate temperature measurement is not possible if the grounded thermocouple tip exceeds ±1.2 vdc. This is the common mode specification for its ±78vdc input range. Because the temperature is not extremely high, you could investigate using temperature conducting epoxy to attach the thermocouples. If used correctly, the epoxy can also isolate the tip from the metal surface. Another possible solution is Kapton© high temperature tape as an insulator. John Rys Measurement Computing

Posted on behalf of a customer We are trying to measure the surface temperature on a water-cooled stainless-steel shell that is heated by a DC current from 0 to 8 vdc. Our test lasts for 4 seconds with the temperature peaking at 150 C°. The instrument we chose is the WebDAQ 316 thermocouple data logger because of its 75 Hz maximum sample rate. When heating the shell, the data results give us an unwanted jump in the temperatures. When the DC current source is turned off, the temperatures seem behave correctly. We have tried both unshielded and shielded thermocouples and the results are the same. We use K-type thermocouples that have the weld exposed and we attach it to locations on the shell in the attached picture. The WebDAQ 316 input channels are specified to be differential so we believe 0.0 to 8.0 vdc should not be a problem. Could you provide guidance as to how to correct this behavior?

Hello, To measure the thermocouple voltage, the MCC 134 uses a differential input connection. However, it is not known if the thermocouple will be in contact with a ground metal surface or if it will be isolated – perhaps suspended in a tank. Because of this dilemma, we use a reference resistor to the Raspberry Pi ground. The reference resistor allows the converter to make the measurement in either situation – grounded and ungrounded. However, this exposes you to the possibility of a ground loop. A ground loop can happen between two grounded thermocouples or with another system ground connection. Depending on the ground currents, you may not get an error until sometime later in your process. Maybe something nearby is powered on or a process starts. Debugging this situation is difficult. First, you can test the MCC 134 operation by replacing the thermocouple connections with a wire short across the channel inputs. A wire is a zero volts thermocouple and will produce a stable temperature that is close to ambient. If you have multiple thermocouples, replace all but one with a wire short. If it works, you have a ground loop between the other thermocouples. Another trick is to isolate the thermocouple ground end using a piece of mica or Kapton© high temperature tape. Kind Regards, John Rys

Posted on behalf of a customer Hello, We are experiencing an ongoing problem that comes in and out and is somewhat of a headscratcher for us. We ae using the MCC134 Thermocouple Measurement HAT for the Raspberry Pi, and what we experience from time to time is a drop in signal, and get the error code -7777 reading. We know that means return value is outside the common-mode range, and were wondering what advice you can provide to help mitigate this problem. Like I said this error seems to come in and out, and we know the thermocouples are working and isolated the problem to either the thermocouple wire or the mcc134 board. I read online that it is advised to make a connection to the device you are measuring to any pi GPIO ground terminal, is that something you can advise? Are there any other actions we can try to take? Thank you,