JRys

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

When power is applied to the board, nothing happens until the USB is connected. When this occurs, the driver starts up and systematically turns on power to board sections to minimize inrush current. At this time, the digital IO is configured as inputs all high. The board is not powered on if the system fails to recognize it. If the computer is shut down or the USB cable is removed, the port state should drop to zero volts because board power is removed. The board must be in contact with the device driver for it to remain powered. There may be a case where the USB driver crashes and leaves the board power applied, but I cannot verify this.

In between capturing data sets, use the File->Save As option to save the file into a different format. By default, the file type is sch. Choose txt or cvs from the Save as type box (underneath the filename) to produce a copy in a different format. Existing sch files can be opened and converted using File->Open followed by File->Save As.

d_out and d_in are 8-bit operations whereas d_out_bit and d_in_bit are 1-bit operations. It's up to you to determine which is best based on your software design. If I can make one recommendation, set port directions early in your init function and don't change them later. This is because the configuration will reset the port value. Documentation can be found here. In the help, search on USB-1024LS to get to the device page.

If the PersonalDaq's power LED is off, the device will not appear in Personal DaqView's Active Devices panel. If it is on, please ensure it is connected before starting the software. As for PostView, I don't know what you mean because it gets its data from a data file and not from an active device.

Your code is failing not because FirstPortB is used with d_config_port to designate the direction but because you then read it with d_bit_in. Both d_bit_in and d_bit_out use FirstPortA exclusively with bit numbers from 0 to 23. On the other hand, d_in and d_out use FirstPortA, B, CL, and CH.

The USB-ERB24 is a general-purpose dry contact relay switch box. Because it's a dry contact, the impedance is the contact resistance (0.1 ohm), unless I'm missing something.

The typical conversion is g's = volts * (1 / sensitivity). For a 100mV/g sensor, multiply volts by 10 ( 50g accelerometer).

Thank you for the update.

Using a separate isolated device, like the USB-TC, would isolate the thermocouples from the pressure transducers and help if there is a ground loop.

The latest Bookworm operating system significantly changed GPIO control due to the pi5 design. This required us to rework sections of our driver, which is now in beta. You are welcome to try the beta version by performing the following commands: 1. $ cd daqhats 2. $ sudo ./uninstall.sh 3. $ git pull 4. $ git checkout pi5 5. $ sudo ./install.sh 6. $ pip install daqhats (manually add Python support) You can switch back to the released library by uninstalling the library, running “git checkout master”, then installing the library.

If you were to restart the computer to ensure no other programs are running in the background and then run InstaCal, you should not get an error that the network device is in use. You might want to review what others have said about the error. The following is one that a quick search turned up. https://www.stellarinfo.com/blog/fix-local-device-name-is-already-in-use-error/ If you are convinced the problem is the TC-32, I can start the process to return it to the factory for testing. However, so that you know, the turnaround time is 4-5 weeks.

The USB-2416-4A0 and a USB-3104 will provide the required channels. The USB-3104 requires an external power supply to power the 4_20mA loop. Grounding can be tricky depending on how the thermocouples are used. The pressure sensor power supply ground will establish the USB-2416-4AO ground. If there is more than one power supply, there is a risk of a ground loop. Also, using a grounded thermocouple, I want you to know that the bare wire end will establish another ground point. The USB-2416-4AO engages an internal resistor from the low side connected to the ground. Expect update rates around 5Hz. For software, there is C and Python programming support for Windows and Linux, or DASYLab BASIC or FULL for Windows.

It makes sense that opening InstaCal while your LabVIEW program is running produces the error. InstaCal will attempt to communicate with the devices in the board list. We recommend not running InstaCal when LabVIEW is open. This includes having the development system open. If someone else in your organization might try to access the TC-32, you can add a unique connection code to the InstaCal setup, under network settings. This will prevent another user or process from opening a connection to the device.

I got a little carried away and enhanced the script I sent - attached. It will now do the conversion to csv after storing the data in a bin file. The first column is the scan number. If you multiply it by 1 / rate, you get elapsed time. Absolute time requires that you record the start time. Then during the conversion to csv, time = start_time + scan * 1 / rate. There's probably a little more to it than that because you're dealing with time, but you get the picture. a_in_scan_file.py