yvo

Hi borg Good point. I added the proposed delay between the call of the monoflop and the call to shutdown the RPi. In the meantime, I set up a test-bed running a continuous start- and shutdown-procedure. During the procedure, an external simulates the main-switch hit by the user for on and off. Turning on, the RPi starts automatically and the backup-power-service gets activated. Turning off, the RPi starts the shutdown-procedure with the final power-cut. One of this cycle takes about 60 seconds. And the setup was now running for almost 20 hours without one failure (about 1'200 sequences). That is great. I will go with this setup into the real-world during the next two days. I will keep you informed, how it works. Cheers. Yvo

Hi @borg Hi @MatzeTF I was building a lab-setup of the RPi-5-, HAT- and IndustrialDualRelay-setup to simulate the shutdown- and power-cut-procedure. Attached two pictures of the setup. At first, I try to describe the duty of the setup used as a real-world-application: The user switches the setup ON by providing 24V power-supply to the HAT. The RPi starts. A services starts in the background and switches on the IndustrialRelay to provide the HAT with an additional power-supply by USB. The setup has now two power-sources: 24V main-supply, 5V USB-supply. The setup is getting the designated job done autonomously. The user switches the setup OFF by interrupting the 24V power-supply of the HAT. The setup is still powered by the USB-power-supply. The initially started and still running service detects the missing main-power-supply of the HAT (calling hat.get_voltages() in an endless loop). The services initiates the shutdown-procedure using the following code: def shutdown(self): ''' The function is called, as soon as the value of the voltage_dc of the HAT goes to 0.0V (user switched main-switch to OFF). The function guarantees a proper shutdown of the system and a final power-cut of all bricklets and HAT. ''' ''' Maximum of the power-off period of the HAT (about 130 years). See documentation. Guarantees a period long enough to be disabled. Due to the hard power-cut, at each restart, the unit starts anyway. ''' powerOffDuration = 2**32-1 ''' The delay in seconds till the hardware turns off. ''' delay = 10 ''' Initiate the hard power-cut of the HAT with the given delay in seconds to shutdown the system properly. ''' self._hat.set_sleep_mode(delay, powerOffDuration, True, True, False) ''' Turns the USB-power-supply off with the given delay in milliseconds. ''' self._dualRelais.set_monoflop(0, True, delay * 1_000) ''' Initiating the shutdown of the system of the RPi. Using a delay of 10 seconds of the hardware-based power-cut is enough to let the system properly running a shutdown. Important remarks: * Even if the RPi is shutdown, the HAT will perform the final power-cut. ''' os.system("sudo shutdown now") During the experiment with the lab-setup, the GPIO-4 stays always at 3.3V (high). It only goes low, when the two power-supplies are cut. Question: What is your suggestion? This code and setup should guarantee a bullet-proof way to disconnect the setup from the USB-power-supply? Is there an issue with the GPIO-4 staying high? And should it set to low before calling sudo shutdown now for the proper shutdown of the system? Looking forward to any suggestions and hints. Cheers. Yvo

Hi borg Puh, your questions are fare to deep into the technical details for my limited knowledge. I just found some hints, that this behavior of GPIO-4 is a main difference between RPi4 and RPi5. I have the same shutdown-procedure running on many RPi4 (8 pieces) with the same setup and the same software, but not encountering this behavior. Strange enough, even the behavior of the 8 RPi5 is not consequently the same. I was able to get the GPIO-4 to low (0V) using the call as you mentioned. But short after the shutdown ended, the GPIO-4 goes back to high (3.3V).

Hi MatzeTF Mh. there is still an issue about the entire shutdown-process of the HAT. The mentioned problem above only addresses RPi-5. The RPi-4 has never shown this kind of behavior. Some research gave me a hint, that one difference between RPi-4 and RPi-5 is the behavior of the GPIO-4. It seems, that on RPi-5 the level on GPIO-4 stays high (3.3V). On the contrary, on RPi-4 the level on GPIO-4 changes to low (0V). And that the behavior of GPIO-4 on RPi-5 prevents the HAT from an entirely shutdown. Question: What do you think? Does it make sense to you and would it make sense to go further into this topic? Looking forward to any hints and suggestions. Many thanks in advance. Cheers. Yvo

Hi MatzeTF It works perfectly. Thank you very much. In my case, I use the: IndustrialDualRelay.set_monoflop(channel, value, time) as the very last command. Before this command, I call the HAT to power-off: HAT.set_sleep_mode(power_off_delay, power_off_duration, raspberry_pi_off, bricklets_off, enable_sleep_indicator) The set_monoflop is called with slightly longer delay (e.g. 1 second) than the set_sleep_mode. With this concatenation, I have a deterministic power-off of the entire system. Looking forward to see it working in the real-world. Cheers, Yvo

Hi MatzeTF Great. Thank you very much for the fast replay. I will test it in the next days and coming back with the result, Cheers. Yvo

Dear MatzTF Great. Thank you very much for the advise. I will go for trial with the ESP32-Ethernet-Brick, learning something new. As soon as I have the setup, I will post an image. Cheers. Yvo

Dear list I am using several Industrial-Bricklets in a rough environment. Well protected by an IP68-metal-box. But still exposed to vibrations. All the bricklets are very well supporting the environment since +12 month. As connection to a local Industrial-PC (IPC), I am using a Master-Brick and a USB-C cable. The entire setup is installed using a Rail Mounting Case . The software using the bricklets is running on the IPC and uses localhost as address. All other sensors used by the IPC are connected by LAN-connections using RJ45. The power-supply of the IPC and all the attached sensors is using 24V DC. The USB-C connection of the Master-Brick turned out to be the weak-point of the setup. The connection has to be protected by using silicon-glue from loosing. I would like to get a mechanically better connection between the IPC and the bricklets. Question: Would a ESP32 Ethernet Brick using a ESP32 Power Supply a reasonable replacement? The ESP32 Ethernet Brick could be attached with available LAN-connections and the software would address the defined LAN-address instead of localhost. Looking forward to your advice and suggestions. Cheers. Yvo

Hi List Last summer I was asking about the set_sleep_mode of the RaspberryPi using the BrickHAT. You will find the original post here. And the solution proposed by matzeTF was perfect. The background was, to control the shutdown of the RPi in a controlled way in combination with an Industrial-Dual-Relay Bricklets and a second power-supply of HAT and RPi using the 5V USB-connection. This combination allows a controlled shutdown of the entire system and a final cut of any power-supply of the system. This works perfectly so far with RPi-4. In the meantime, I switched to RPi-5 for a new edition of the entire setup. And with this switch, I am confronted with the new following effect: After calling the set_sleep_mode() -function, the system starts to shutdown as defined. But, at the end, the Industrial-Dual-Relay is not set back to default (no connection between A and SW). As a result, the system gets blocked in the following state: The system of the RPi is down. The Industrial-Dual-Relay still provides connection between A and SW. The HAT and RPi gets still power. The only solution to solve the problem is, to manually disconnecting the USB-power-supply from the HAT. After the disconnecting, everything goes and stays as it should (no connection at relay between and SW. Unfortunately, this behavior is not observed systematically. It occurs sometimes. While writing this post, I started the reflection, if the power_off_delay with 5.0 seconds is to optimistic and if the problem could be solved using a longer time-period for the power_off_delay. Do you have any ideas or suggestions? Looking forward to any hints. Cheers. Yvo

Hi MatzeTF Fantastic. Thank you very much for the quick and positiv replay. Then I will implement it in this way. Cheers. Yvo

Dear List I am running a measurement-station using an Industrial-Counter-Bricklet to monitor the frequency given by an encoder: One application is accessing the Industrial-Counter-Bricklet every 5 seconds reading the current frequency on channel 0 and provides the information to a Prometheus-monitoring system. That works perfectly A second application could take usage of the measurements of the Industrial-Counter-Bricklet to monitor its own functionality. For this, it has to read the frequency on channel 0 of the Industrial-Counter-Bricklet as well. This in a similar rate such as every 5 seconds. Question: Is it safe and reliable to access an Industrial-Counter-Bricklet (or any other bricklet) reading the values from two individual applications using the same host and port? Or is it recommended to use a second bricklet. To keep the two applications fully independently, I try to avoid an exchange of the measurements between the two applications through a kind of communication-protocol. Looking forward to any suggestions and hints. Cheers, Yvo

Dear MatzeTF Thank you very much for the quick replay and the hint about the AA-battery. Works for me. Cheers

Dear list I have many installations running using the Real-Time-Clock bricklet. All the installations are running remote and are difficult to access (tunnel-construction sites). The installations are running for about 24 months. During the long duration of the installation, some batteries of the Real-Time-Clock bricklets are getting to low-voltage and the support of the RTC is not given anymore,. Question: Is there a way or method, to monitor the battery-voltage of the RTC-bricklets? Such kind of monitoring could allow to plan the exchange of the backup-battery of the RTC-bricklet. Looking forward to any ideas and hints. Cheers, Yvo

Dear list Some bricklets are used by services written as Python-scripts started automatically at the startup of the RaspberryPis were the applications are running. One of those bricklets is an IndustrialDualRelay. At the start of the service / of the script, I am getting sometimes the following exception: Exception during usage of DualRelay: Did not receive response for function 255 in time (-1) Question: Can it be, that the service starts to early and the connection to the bricklet cannot be established? And do you have any suggestions? Thank you advance for any ideas and hints. Cheers. Yvo

Dear MatzeTF Ahh, sometime the solution is to easy to be found. Thank you very much for the hint. Works perfectly. Cheers and a nice weekend. Yvo