JRys

DAQami is newer than TracerDAQ Pro, but they both have their place. TracerDAQ supports most MCC devices, including PCI boards, while DAQami primarily supports USB devices, but not all of them. DAQami has support for Analog & Digital Input/Output. TracerDAQ Pro has no Analog or Digital output - only input. However, TracerDAQ Pro has more triggering options and you can schedule when to acquire data.

Could you provide more information, like what software you used to enter 7A and what it is for? Many customers use the DAQami program to ensure their devices are working. You can request a free activation code or use it as is for 30 days.

Your Windows 7 64-bit system uses the old way of driver signing. So, the solution is to use an older version of InstaCal before the signature upgrade. Uninstall InstaCal, and once this is done, use the following link to install version 6.55: https://files.digilent.com/archive/InstaCal/Archive_6.55/icalsetup.exe

It is impossible to connect both to appear as a device with twice the number of channels. However, you can use both in the same program, which means there will be two buffers to manage. The data buffers can be synchronized if you use the clock from one device to clock the other device. Configure both using the AInScan function. Information about this function is in the UL Help document. Configure the first device to scan the channels, and when it begins, the scan clock will appear on AICLKO. Configure the second device to use the external clock scan option. It will wait until the clock appears before it begins. You'll need to configure the second device first; otherwise, the clock could run before it is ready. Using a short wire, connect AICLKO on the first device to AICLKI on the second.

It is easier to use d_bit_out instead. When using d_bit_out or d_bit_in, use FirstPortA exclusively. These functions write or read individual channels. I modified digital_out.py to use d_bit_out and attached it below. It configures both ports as output and sets each bit individually. Notice the bit numbers are 0 - 15. PortB are bits 8-15. Configuring the ports resets their state, so configure them early in your program before you read or write them. digital_out.py

I have attached the UL Redistribution PDF, and the minimum InstaCal installation program is https://files.digilent.com/downloads/InstaCal/icalsetup.exe. The PDF lists the necessary files for a custom installer program. Use a program like 7-Zip to extract icalsetup.exe to gain access to the driver folders and other necessary files described in ULRedistribution.pdf. Ignore the download links, as they are outdated. The attached VB6 DaqDevDiscovery01 example program will demonstrate how to programmatically discover the device (without InstaCal) and get the serial number (UniqueID). For additional information about the UL API, refer to the UL Help document. ULRedistribution.pdf DaqDevDiscovery01.FRM DaqDevDiscovery01.vbp

If you previously added the miniLabs to InstaCal's board list, its configuration file contains all the required information to run the C# program. If you were to rename InstaCal, it may give you a clue. InstaCal is located in C:\Program Files (x86)\Measurement Computing\DAQ\. Rename inscal32.exe to inscal32.bak. If the results are the same, search your C drive for the following: cbw32.dll => The correct location is C:\Program Files (x86)\Measurement Computing\DAQ\ cbw64.dll => The correct location is C:\Program Files (x86)\Measurement Computing\DAQ\ cb.cfg => The correct location is C:\ProgramData\Measurement Computing\DAQ\ (usually a hidden location) inscal32.exe => The correct location is C:\Program Files (x86)\Measurement Computing\DAQ\ If the search turns up multiple copies of the above files, delete those not in the above location.

The MCC 172 is a non-serviceable item. If it's less than 30 days old, contact your distributor for a replacement.

You could contact Advantech regarding how their utility program works. They should be able to tell you the register/value that must be written to reset the latch. It might be that the inputs are mirrored on the output side (coils), and writing 0 to the corresponding output resets the latch.

It works best if the read request size is set to READ_ALL_AVAILABLE. The inverse of scan_rate is the time for each sample and is very accurate. Keep track of the number of scans read and multiply each by the sample time to generate the timestamps. When read_request_size is set to a positive number, the mcc172_a_in_scan_read function blocks your program and won't return until it fulfills the amount. Depending on the state of the internal buffer, execution times can vary. For instance, when it reaches the end of the internal buffer, it performs an extra read so that the next one starts at index zero. This is all behind the scenes but results in different execution times. There are also unread samples left behind after each read. These slowly build up to an extra read that takes less time.

WER8353.tmp.csv appears to list the programs running at the time of the crash. Looking down the first column toward the bottom, you will see InstaCal listed twice. Somehow, someone or something is starting InstaCal, and therein lies the problem. Would you share how your code? Just the minilab part, mainly how it establishes communication.

Immediately after starting the analog output, the driver copies a portion of the buffer. The amount it copies depends on the update rate and samples per channel. For example, if the buffer is 10000 and the index initially indicates 50000, half the buffer was duplicated and used to feed the device. You can still update that section of the buffer, but the update will only happen once it rolls over and copies that section of the buffer again. If you reduce samples per channel so that the buffer is smaller, the driver copies less, and updates to the buffer happen quickly. The device was not intended to be operated like a controller. There is no buffer on the device other than a 2k sample USB FIFO, and updating the portion of the buffer being fed to the device is impossible.

Use the Test->Analog feature in InstaCal utility on a Windows 10 or Windows 11 computer to test it. If it works but not on the Raspberry PI, try another USB port or another Raspberry PI.

Version 6.73 added LabVIEW 2022 support and was never archived. If you need support for LabVIEW 2012, you must use 6.72 or an earlier version.

Update the InstaCal utility to version 6.74 using the following download: https://files.digilent.com/downloads/InstaCal/icalsetup.exe

The MCC 172 has an onboard micro that precisely controls the A/D circuitry. Data from the A/Ds is placed into the 48k FIFO for the driver to read it. Because the driver is a thread running in the background of your program, it is at the mercy of the operating system (and your program) as to when it runs. So, data from the A/Ds to the FIFO is precise but not necessarily the data from the FIFO to your program.

The electrical specification lists the GPIO assignments in the Interface section. We don't provide support for this, but you could review mcc134.c and mcc134_adc.c in the driver library to get an idea of how to read the board. https://github.com/mccdaq/daqhats/tree/master/lib For a different approach, a board based on the MAX31855 IC may be easier to adapt to a pico. Check out the following: https://www.playingwithfusion.com/productview.php?pdid=75 https://www.adafruit.com/product/3263

Please understand that Digilent/MCC did not create the driver support for Matlab; instead, Mathworks did. Refer to the following page for support information. https://www.mathworks.com/hardware-support/measurement-computing.html Specifically, this note: The support package does not support counter/timer subsystems, digital I/O subsystems, triggered acquisition, specialized voltage measurements (thermocouple, etc.), or the use of Simulink data acquisition blocks for Measurement Computing DAQ hardware. There's no support for encoder inputs (counter/timer). There's no support for the USB-3114 because it is not a waveform-capable device. You should be able to use the analog output on the USB-2637. The USB-3101FS should also work. Check out the following app note regarding analog I/O. https://dev-wiki.digilent.com/daq-and-datalogging/documents/matlab-analog-output-video-script If all else fails, you could bypass the Matlab's toolbox driver and access the MCC API directly. Check out the following:https://dev-wiki.digilent.com/daq-and-datalogging/documents/using-ul-for-dotnet-with-matlab. API documentation can be downloaded from https://digilent.com/reference/software/universal-library/windows/start

The DAQami installation program installs a slightly older copy of InstaCal that isn't compatible with Windows 11. The fix is easy: install the latest version to up your system. InstaCal 6.74: https://files.digilent.com/downloads/InstaCal/icalsetup.exe

The MCC 134 will not work with either board because the driver requires the Raspbian operating system.

Use the forum's private message to send design details. Include spec sheets for the analog input sensors and the rotary/switch values you wish to control.

The USB-2416 requires external +5 volt power. Connect the power supply, plug it into the USB, and start InstaCal. Add it to the board list and double-click it to bring up the configuration dialog. Configure the channels for Temperature, thermocouple type, and data rate. For thermocouples, it is essential to set the data rate to 60Hz. Close InstaCal and start LabVIEW. Do not run both at the same time. This is because InstaCal saves its setting upon exit, and LabVIEW reads the setting once it is started.

There is no support for the USB-3114 or the USB-QUAD08 because the support is limited to analog input channels (volts). Assuming you have the 2017a Data Acquisition Toolbox, you should be able to use the USB-2637 analog input channels.

The driver is continuously filling an internal buffer from which you request data. Each time you read data, you make room for more. An overrun condition means the buffer is full, and there is no space for new data. To duplicate your condition, I modified the continuous.py example so that every time it read data, it would sleep for 0.5 seconds, and I didn't get an overrun error. If I increased the delay, I did get the error. This tells me you have at least a half second to write data out, which is a lot. So, I suspect your streamwriting is taking too long. The MCC 172 default buffer should be large enough to hold one second of data. You could make the buffer large enough to hold two seconds of data by setting samples_per_channel = 2 * scan_rate.

The DT302-PBF is supported on Windows 10 64-bit. To get the QuickDAQ application, download the Omni CD and install the required software.