RobST

Hello @Fausto. Thank you for your answer. Yes, we tested with another Compute Module (so far we tested 4 units, each with their own CM and HATs). To test the HATs with their address in sequence with their physical installation is currently not possible within our setup, due to design restrictions which already led to corresponding hardware. According to the MCC documentation the installation sequence is only a recommendation, not a requirement. I'll check what we can do about that and report back as soon as I have more test results. If anything comes to mind in the meantime, please let me know. EDIT: As the installation sequence became a topic, I have to add some information that might be important: The 8 HATs are divided into 2 modules (each carrying 2x MCC152 and 2x MCC118). The connection of those two modules to the GPIO interface is realised as a Y-connection. So there is no physical sequence between those modules. Best regards, Rob

Hello. I’ve got a question regarding a side effect when using MCC118 and MCC152 DAQHATS together. The MCC152 configuration is mostly kept at default with digital input, apart from DIO_PULL_CONFIG set to 0 for pull-down. Analog output is not used. Our setup consists of 4x MCC152 and 4x MCC118, all continuously read by one program. The MCC118 are set to OPTS_CONTINUOUS with an external clock signal. There are no other HATs used. The physical installation of the HATs is not in sequence with their addressing, due to restrictions in our setup, but each HAT has its unique address (of course). A Raspberry Pi Compute Module 4 is used. While continuously reading, we get the following side effect after varying amounts of time (mostly in the range of 3 to 50 minutes): One of the MCC152, always the one with address 5, goes all high independent of the real signal state. The HAT at address 5 then does not react to any changes in signal state anymore and we keep reading all high on all ports of address 5. The reading process is the same for all addresses, there is no exclusive handling of address 5. This keeps happening after exchanging the MCC115 HAT, independent of where the HAT with address 5 is physically located in relation to the Pi CM4, independent of reading the MCC152 HATs and the MCC118 HATs sequentially within the same thread or independently in different threads, when we reduce the number of HATs (2 x MCC118 and 2x MCC152), but with much longer time until the effect occurs. Is there any known issue regarding the operation of MCC118 and MCC152 together which could explain the effect? Do you have some hints on what could cause the effect? Thanks in advance. Best regards Rob