Bret.PID.Analyzers

Hello @Fausto! Apologies, I thought I had posted this in the correct place. The board was purchased new for this unit, but has otherwise been working correctly. We unfortunately do not have another USB-DIO24/37 to swap it with. The other thing supporting the idea that the output is damaged is that there are several other pins being used by that port (Port A), and they all function as needed. The unit also uses a USB-1608FS-OEM, so I asked the programmer to move that command to an output on there to be able to test further. I also need to make a modification to the amplifier board that output is going to today, so I should be able to try and test that input to see if there's something wrong on the amplifier board's end as well. I've been able to get it to switch correctly on the test rig I have, but that also can provide a great deal more current than the pins on the DIO24/37 can. I'll be able to report back with more info that might help later. Thank you! -Bret

Hello, we're using a USB-DIO24/37 as a controller in a product for an automated process. I've run into an issue where for some reason the pin being used to activate a gain stage on an amplifier board isn't switching. The outputs are all set to be pulled down when not activated, and I usually see the 5V when I turn a point on and off. When I measure the output for the pin controlling the amp board gain though, it only goes to about 70mV. We tried moving the board to a different input that uses a different pin to activate this feature, but it garnered the same result. Furthermore, when I measure this output while not connected to the board, it's still reading about 70mV. This is the first time I've seen this happen in years of using this board like this, and I'm concerned that the output may have been damaged by an issue with the amplifier board. Is it safe to assume this, or is there something I might need to change to revert this? Thank you!

Apologies for the late reply! That was one of the first things I tried on the advice of a coworker, no results. We'll be sending back the board today or later this week, I'm assuming that there's probably just a bad component but it's probably best to have MCC look at it. Thank you again! -Bret

I reinstalled the 32-bit version of the OS, and got the same end result, no recognition. After leaving it with people more familiar with Raspberry Pi hardware and them not being able to get any farther, I think it's time to request an RA # for the board. Oh well. Thank you for the help and info! -Bret

Hello, and thank you for the reply! I was actually able to try a different hat, the MCC 152, and the Pi was able to see it successfully, but I'll try the 32-bit OS as well. I have the board at Address 0 (no jumpers) already, and I've been using the daqhats_read_eeproms command, and it hasn't provided any success, so as mentioned I'll try the 32-bit OS.

Hello, I have an MCC 118 that I'm using with a Raspberry Pi Model B with the 64-bit Raspberry Pi OS installed. I'm trying to set this up in order to test a program that uses it as a signal source, but I'm having an issue with getting the Pi to recognize the hat. I've gone through the entire process at https://mccdaq.github.io/daqhats/install.html, but when I get to the point of either using the MCC DAQ HAT Manager software or the command daqhats_read_eeproms, it never seems to be able to read the board. The command brings back "0 boards found," and the manager doesn't add any hats to the list, and says there's nothing found when I open the ACC 118 app. I have the hat completely pressed in, and the power LED is on, so I think there should be enough of a connection for this to be readable. I've tried it with both no jumpers and one jumper in the A0 position, but I still get the same results. I've also uninstalled and reinstalled the daqhats resources folder, but this changed nothing. Is there something else that I may be missing? Thank you!