JRys

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.

The DT9857E has never undergone vibration and shock testing, so there's no data to report.

The idea is to run DAQami for a period of time in order to determine where the error lies. If it can read data from your devices simultaneously without error, then the issue points to the C# program. Do not run other programs in parallel because you will get strange errors. Or, you could use InstaCal to test each device separately with the Test->Analog panel. You could need a better USB hub if each device works individually but not together. When using multiple devices, it's best to use a PCI or PCIe hub instead of one that plugs into a USB port.

It seems odd that your error report lists InstaCal when using a C# program to control the devices. InstaCal is run once to add the devices to the configuration and set the analog input mode. It should not be run while another program is controlling them. You could upgrade to InstaCal 6.74 to see if it helps. You could also try our DAQami program to see if it can reproduce the problem.

Never mind about TracerDAQ right now. I think the update that you missed is essential. You can force it by running HIDRegUpdater.exe located in \Program Files (x86)\Measurement Computing\DAQ\. It instructs Windows to not remove USB power from the device. Once you have completed the update, repower the device by re-inserting the USB. Then, rerun InstaCAl. There is no need to calibrate the device as it was calibrated before leaving the factory. InstaCal has a test feature (Test->Analog) that allows you to read the temperatures. After, close InstaCal and run TracerDAQ.

It must be a RedLab-1608FS-Plus, which is our USB-1608FS-Plus. It does not support the original RedLab-1608FS, which is our USB-1608FS.

I found a Modbus simulator program and used it to check the output. I didn't have any luck updating 4xxxx holding registers, but I was able to update individual coil outputs. According to your documentation, the coil outputs are 489 through 496. I had to set the start register to 488 for it to begin at 489. I noticed that the value written must be 2 or more, which is a mystery to me. Luckily, the default output value for a Switch is 5. I hope this helps. Modbus.DSB

By default, display windows are minimized. Go to View->All Windows->Show. There is also an icon on the toolbar for this. It looks like a window with an arrow. It's called Restore All Windows.

An sch file can be opened with TracerDAQ. In this case, TracerDAQ acts like a data viewer. Once you have it loaded, perform a Save As. If, instead, you would like information about the sch because you want to create a custom file converter program, I've attached a file format document.

The DASYLab documentation regarding Modbus control suffers greatly, and making matters worse, not all device manufacturers adhere to the standard. The DASYLab Modbus Digital Output bitwise write goes by registers offsets from 40000. Register numbers automatically get added to 40000 behind the scenes. Setting the Start-register to 31 (not 40031) and enabling eight channels would write outputs #0 - #7. If bitwise is unchecked, writing hex 0x00FF to address 31 should set outputs #0 - #7. Try using a decimal value of 31 with the bitwise box checked and eight channels enabled. If it fails, see if you can write a single output using 489 (coil address of output #0) Also try 31 with bitwise unchecked and writing a value of 255 to set outputs #0 - #7.

3 samples per second per channel (3 S/s/ch). Page 19 in https://files.digilent.com/manuals/TC-32.pdf