Nick Wright
-
Posts
14 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Posts posted by Nick Wright
-
-
On 7/31/2024 at 12:15 PM, Henry H said:
Hello @Nick Wright,
If using a DAQ-2408-OA to measure C type thermocouples:- Would the same procedure apply?
- How can the CJC output be read/recorded using the DAQ-2408?
Thanks in advance for any guidance you can provide
The USB-2408 and variants can read voltage directly, so you do not need to convert from temperature to voltage. However, I do not know of a method to read the CJC temperature directly from those devices.
-
I think your best course of action is probing the system to look for spikes or unexpected voltages. There are no obvious issues in the schematic, but I would focus on the high voltage portion around U3 and the switch. You may find unexpected behavior from things like the leakage current through the clamp diode in the ULN2081A on O5.
-
2 minutes ago, Donk said:
Some things seem odd in the design unless I misunderstand something:
- LED D1 is always off (has GND on both sides)
- The ULN2801A O5 is tied to GND
- There is no current limiting component for the U2 diode (unless the capacitive pushbutton switch limits current)
However, I do not see anything that would damage the MCC 152 if the connections on J7 are made correctly to the 152. What is the pin mapping from J7 to the 152? If you are using the 1x10 header footprint on the 152, the pinout is:
-
@Donk Is GND1 a different ground than the other ground symbols in the schematic? is it at the same potential or separated?
-
Just now, Donk said:
Thanks @Nick Wright.
The ULN2801 outputs are driving solenoids. Unfortunately, the schematic terminates at a connector without showing the coils. However I'm just using the built in suppression diodes from the ULN2801. The coils are 24VDC.
I'm almost done for the day, but if I can find time, would a schematic without the connectors, and showing the coils help? I could probably have one to you on Monday.
Yes. We mainly need to check that the freewheeling diode output from the ULN2801 is connected back to the coil supply so you don't get large spikes when turning the coils off. You can also check the MCC 152 outputs with a scope while switching the solenoids to look for spikes.
-
It is likely that the IO interface chip has been damaged, most likely due to some form of over or under voltage spike similar to what was reported here. A system schematic would be helpful for further analysis to avoid future damage. Are you driving relays with the ULN2801
-
@Display Name The 152 should not interfere with other devices using the I2C bus on GPIO2/3 unless they happened to use the same I2C address as the 152. The I2C components on the 152 support up to 400 kHz, but we do not change the I2C speed from the default value in the library so it is likely running at 100 kHz.
It is possible that the extra bus capacitance of having the 152s along with your devices is slowing the edges enough to have issues. Are you using any additional pull-up resistors on SDA / SCL? You could try capturing the I2C comms on a scope in both scenarios to see the difference, and adding additional pull-ups may improve the communications.
-
1 minute ago, Lwin D said:
Hi @Nick Wright, thank you for your response. One quick question, how do I calculate the CJC voltage given the thermocouple type and an ambient temperature of ~20 C? Do I just find the corresponding thermocouple voltage for 20 C for J and C type thermocouples?
Yes, that is correct. For best accuracy read the CJC temperature reported by the USB-TC because it could be different from ambient.
-
I think the voltage reading function in mcculw only applies to the USB-TC-AI and not the USB-TC. I do not know of a way to get a voltage reading from the USB-TC directly. You may be able to get it in a roundabout fashion in this manner:
- Configure the USB-TC to a similar voltage range TC type such as J.
- Read the thermocouple temperature T1 and the appropriate CJC sensor temperature Tcjc
- Calculate the corresponding type J CJC voltage using the J thermocouple data (Vcjc)
- Calculate the thermocouple voltage using the J thermocouple data (V1)
- Calculate the raw thermocouple reading voltage Vraw = V1 - Vcjc
You can then calculate the type C thermocouple temperature:
- Calculate the type C CJC voltage using Tcjc and the C thermocouple data (Vcjc2)
- Calculate the type C thermocouple voltage V2 = Vraw + Vcjc2
- Calculate the thermocouple temperature T2 using V2 and the C thermocouple data
-
@Display Name could you also please capture an analog scope trace on one of the encoder signals to check for the voltage levels, spikes, etc?
-
On 3/6/2024 at 5:06 AM, nbv said:
Hi,
not exactly. I'll explain it again chronologically.
1) a new RPi 4 (not sure what is the name of the OS but it was the one recommended by RPi at the time) was setup as per instructions.
2) 3 MCC boards were mounted and installed (MCC 152 on address 0, MCC 152 on address 1, MCC 118 on address 2). all jumpers and OS configurations as you wrote. The setup worked perfectly well for more than a year both with the manager app and with my scripts.
3) one day (this last Monday) it simply didn't work anymore. it didn't work in the way I explained in the original question i.e. "board not responding" (both of the MCC 152 on address 0 and 1, the MCC 118 continued to work).
4) The only thing that happened between the last time it worked and this Monday was the weekend during which the pi was turned off. I usually turn the pi off over the weekend. so the boards were not moved or removed or flexed. I only started manipulating them after the "not responding" error.
5) as part of troubleshooting I unmounted all three boards and mounted back only the first one (mcc 152 address 0) - it didn't work.
6) I tried it on another RPi - it didn't work.
7) I tried it again on both pi's after disconnecting all the wires. - didn't work.
8) NEW UPDATE: took one other mcc 152 scavenged from another system and connected it to my RPi 4 in the original setup (without any jumper in address 0) - this works perfectly well. next step, I took the second mcc 152 (the one that was before in address 1) and mounted it on top of the "new" mcc 152. now both of them work. I continued and mounted the mcc 118 in address 2 (as before) and it also works (as it did before).
9) my (strange) conclusion is: for whatever hardware-related reason, the mcc 152 in address 0 failed. it was identified and the EEPROM can be read but it could not respond (could not be opened in the manager app). This caused the second mcc 152 in address 1 to also not respond in the same exact way, although it is not damaged. ones I put in the same address but with a "new" mcc 152 below it, both respond. Even stranger - this problem didn't affect the mcc 118 in address 2.
does this make any sense?
The MCC 152 is different from the other MCC HATs in that it uses an I2C IO expander on the Pi I2C bus to implement the digital I/O. The other HATs all use SPI only. If the IO expander on a 152 gets damaged it can cause issues on the I2C bus, which would show up as problems communicating with other MCC 152s but not different models of HATs.
The HAT detection is performed by reading the EEPROMs on a dedicated ID I2C bus (separate from the one used for the IO expanders) so a damaged board can still be detected but communications do not work.
The most likely causes for damage to the IO expander are voltage related, due to things such as:
- Overvoltage on an IO pin (like connecting a 5V input signal when the MCC 152 is configured to 3.3V)
- Undervoltage on an IO pin (such as connecting signal and ground backwards)
Possible to Use with Other HATs
in Data Acquisition (DAQ) & Data Logging
Posted
The address jumpers on the MCC hats will change the base address of the EEPROM on the ID bus. You can set the MCC 118 to an address other than 0 and the EEPROM will no longer conflict with the EEPROM on the Adafruit hat. I do not see any other signals that will conflict, so everything should work with that change.
Regards,
Nick