I use an Arduino UNO r3 via USB 3 port attached to a PC running WIN 10 and Python. Additionally i use Uart LIDAR sensor on another USB 3 port. The Arduino converts the status of an attached analog switch (status open or closed) to binary code for the Python script. Everything works fine, however after some time (hours or even days) the python script gets no data anymore from the Arduino. The Arduino sketch looks like this:
#include <avr/wdt.h> // Include watchdog library
#define ButtonPIN 8
#define LED 13
bool oldState;
void setup() {
Serial.begin(115200);
pinMode(ButtonPIN, INPUT_PULLUP);
pinMode(LED, OUTPUT);
bool state = digitalRead(ButtonPIN);
sendMessage(state);
oldState = state;
Serial.println("Setup complete");
delay(1000); // Ensure setup message is sent before entering the loop
wdt_enable(WDTO_8S); // Enable watchdog timer with an 8-second timeout
}
void loop() {
wdt_reset(); // Reset the watchdog timer
bool state = digitalRead(ButtonPIN);
if (oldState != state) {
digitalWrite(LED, state);
sendMessage(state);
delay(500); // Debounce delay
oldState = state;
}
}
void sendMessage(bool state) {
Serial.write(0x01);
Serial.write(0x29);
Serial.write(state ? 0x01 : 0x00);
Serial.write(0xEE);
Serial.write('\n');
}
How can i debug this? In the serial monitor of the Arduino IDE things are looking correct, just in python the switcg stos working at some point. I already checked hardware connection, OS sleep modus, bios setting for USB ports, etc. I can also trigger the failure by toggling the hardware switch many, many time realy fast. The adurino seems to stop cumminication. If i press the hardware reset button on the UNO all is back to normal. Is it a buffer issue?
Arduino UNO has a limited serial buffer size. If you're sending data too rapidly from the Arduino or if the Python script is not reading data fast enough, the buffer may overflow, causing communication to stop. You can try adding some delays in your Arduino code to slow down the data transmission, or optimize your Python script to read data more efficiently.
No. Arduino incoming buffer can overflow, yes indeed. Outbound will not. Instead, serial becomes blocking function, not returning from print statements until outbound chars are safely inserted in TX buffer. Nothing gets lost.
Thanks for trying to help, but this code let´s my python script think the switch is closed all the time, no matter how the actual state of the hardware switch is.
So do what you should do in these situations, post the whole of your code again, so we can check you understood what you were told. What you were told about is wrong and needs correcting.
It is also entirely possible that that there is other stuff wrong with your code. I only looked at the incorrect way you were creating those variables.
Remember it is you who are asking the questions here.
Sorry, well i tried it @Grumpy_Mike and it did not work. Since i need to use the application in a live environment over the weekend i need to revert to a version that at least runs the primary language without error. But when i tried your code it was stuck in the secondary language. The problem is maybe not even code related but a hardware issue which i am also investigating. I will post your proposal here again, i maybe made an error transfering the changes to the sketch:
#include <avr/wdt.h> // Include watchdog library
#define ButtonPIN 8
#define LED 13
bool oldState;
bool state;
void setup() {
Serial.begin(115200);
pinMode(ButtonPIN, INPUT_PULLUP);
pinMode(LED, OUTPUT);
digitalRead(ButtonPIN);
sendMessage(state);
oldState = state;
Serial.println("Setup complete");
delay(1000); // Ensure setup message is sent before entering the loop
wdt_enable(WDTO_8S); // Enable watchdog timer with an 8-second timeout
}
void loop() {
wdt_reset(); // Reset the watchdog timer
digitalRead(ButtonPIN);
if (oldState != state) {
digitalWrite(LED, state);
sendMessage(state);
delay(500); // Debounce delay
oldState = state;
}
}
void sendMessage(bool state) {
Serial.write(0x01);
Serial.write(0x29);
Serial.write(state ? 0x01 : 0x00);
Serial.write(0xEE);
Serial.write('\n');
}
//vers3
It did. I don´t exclude human error on my side for sure, it was late when i tried it. Will try again after the weekend when i can access the application. Do you mind telling me why it is better not to store the pin state. Does this cause a buffer overflow?
Update: just went back into the exbibition space, had a few hours left before the opening. Uploaded the new sketch again and this time no errors, switches were working. So it was my bad after all. I will get back in about 50 hours to report if the UNO keeps working or not. Thanks!
Been back to the machine after 13 hours, switches are still working. Great.
However when i switched off the power in the exhibition space (only the PC stays all the time on power) and then switched it on again, the UNOs were jammed in one language and the switch did not work again. The UNOs are in a metal case but still close to 240V current circuits. Is it actually possible to extend the UNO sketch, so each time the switch is toggled the UNO first resets and than reads the state of the button?
It is possible that the PC which was on all the time provided some parasitic powering of the Arduino. This can cause a situation called latch up, where it doesn't work. Most of the time a compleat powering down of everything will restore correct operation, but occasionally it can damage some devices.
A metal box is not the best thing for firing RF signals through.
Well i guess in that case the PC needs to be switched off before the rest gets shut down. I don’t get your hint about the RF signal…gear is all wired up.
@nanniapu this is a better way of opening the serial, it gives you more control over just writing everything in one go.
Pay attention to "button.dtr = True" when dtr goes from False to True in your Pyton script it resets the Arduino UNO. Below it sends the reset when the port is first opened but you can send the dtr command at any time while your Python script is running when you need a reset.