(04-24-2022, 12:43 AM)Rob F Wrote: To be honest I'm a little surprised about the fear of running on a live tank as it feels like you've been making more changes in the code lately than I have based on our emails and posts. You're also updating manually due to this and if anything is missed it's not good.
Again, I'm NOT using the customized version, as i've already told to you , i've reverted back my changes (primary due to the email library issue).
Only changes currently active are the i2c check skipped for sensor with ID 104 (as you have suggested me), in this way the RTC clock is not seen and everything act as usual
AND a couple of changes in the web admin, obviously the web admin has nothing to do with the controller itself.
based on the system log the culprit is............. the retry feature, added by "someone very excited about that" in v6.5.
Code:
Apr 24 00:10:00 reef-tank startup[854]: RUNNING SCHEDULE #66
Apr 24 00:10:00 reef-tank startup[854]: startDosing------------------------------5
Apr 24 00:10:00 reef-tank startup[854]: TRY AGAIN -
Apr 24 00:10:00 reef-tank startup[854]: TRY AGAIN -
Apr 24 00:10:00 reef-tank startup[854]: TRY AGAIN -
Apr 24 00:10:00 reef-tank startup[854]: TRY AGAIN -
Apr 24 00:10:00 reef-tank startup[854]: TRY AGAIN -
Apr 24 00:10:00 reef-tank startup[854]: TRY AGAIN -
Apr 24 00:10:00 reef-tank startup[854]: TRY AGAIN -
Apr 24 00:10:01 reef-tank startup[854]: TRY AGAIN -
Apr 24 00:10:01 reef-tank startup[854]: TRY AGAIN -
Apr 24 00:10:01 reef-tank startup[854]: TRY AGAIN -
Apr 24 00:10:01 reef-tank startup[854]: TRY AGAIN -
Apr 24 00:10:01 reef-tank startup[854]: TRY AGAIN -
Apr 24 00:10:01 reef-tank startup[854]: TRY AGAIN -
Apr 24 00:10:01 reef-tank startup[854]: TRY AGAIN -
Apr 24 00:10:01 reef-tank startup[854]: TRY AGAIN -
Apr 24 00:10:02 reef-tank startup[854]: TRY AGAIN -
Apr 24 00:10:02 reef-tank startup[854]: TRY AGAIN -
Apr 24 00:10:02 reef-tank startup[854]: TRY AGAIN -
Apr 24 00:10:02 reef-tank startup[854]: TRY AGAIN -
Apr 24 00:10:02 reef-tank startup[854]: TRY AGAIN -
Apr 24 00:10:02 reef-tank startup[854]: TRY AGAIN -
Apr 24 00:56:31 reef-tank startup[854]: TRY AGAIN -
Apr 24 00:56:32 reef-tank startup[854]: TRY AGAIN -
Apr 24 00:56:32 reef-tank startup[854]: TRY AGAIN -
Apr 24 00:56:32 reef-tank startup[854]: TRY AGAIN -and so on until i've unplugged the cable (2 hours later, when I was back home and the EasySPS bag was already empty.
Why this happens ? Because there isn't any safety measure, it's an unlimited while, if the PCA didn't get the signal, your retry will retry forever.
And when this happens, even the clock hangs (as per my screenshot) and if the clock hangs, everything else won't work as expected.
A better system would be to retry 2-3 times then force OFF the affected pin, send email, send sms, warnings, call 911, the fire fighters and whatever you want, but SHUTDOWN THE PIN.
Forcing the pump/dc/ac/whatever to OFF or to a safe level is what i'm trying to tell you from weeks but you still add feature (that's good) without increasing reliability to the existing code.
Suggestion 2: when you start the counter for dosing/ac/dc/whatever, save the expected end time somewhere on database and clear the field when finished.
Then with an external script run from crontab, totally separated from the robotank application, check for the expire time and, if still set, force the shutdown of the port. This will shutdown the port even if robotank is crashed.
I've started to make some fixes in the previous weeks but every time you made a new release my fixes are ignored, so the question is: why wasting time if you discard every change?
I can also start to fix this huge flaw, but i know that you still ignore everything when releasing the v6.6 like you did for v6.5 and v6.4
In example, where are my pachtes for adding sub-milliliter dosing, like 15.50ml ? or patches for allowing the usage of PWM on each dosing pump ? A lower rotation rate increase the dosing precision. Or my patches for increasing the dosing time and so on ? No comments so far, no suggestions to my code or for a better implementation in your software. Just silently dropped.
You said the the dosing system is running properly from years, but the fix in v6.4 for the variable overflow that lead to an unlimited dose is mine....
(no, i'm NOT using anything of my patches to c++ code, just the one for the web interface, because using a patched version that need to be totally re-patched on every release is a pain)
anyway, here's a fix for the PCA.
maybe writing always 0 (and not the previous value) is better ? Doing in this way, the controller doesn't get stuck in TRY AGAIN, frozing everything else.
Code:
void pca9685::adjustPinLevel(short pinID, short value) { // adjust pca9685 pin level
std::cout << "adjustPinLevel - " << pinID << " - " << value << std::endl;
short pinLoc = 0;
for(short a=0; a < pca9685TotalPins; a++ ) // search all channels for matching pinID
{
if (pca9685PinID[a] == pinID) {pinLoc = a; break;} // record array location
}
short driverLoc = 0;
for(short a=0; a < pca9685totalEnabled; a++ ) // search all channels for matching i2c address so we know which driverID is required
{
if (pca9685Address[a] == pca9685AddressSaved[pinLoc]) {driverLoc = a; break;} // record array location
}
short a = 0;
char buffer[5];
int length = 5;
int cnt = 0; // Counter for max retry
int originalValue = getPinLevel(pinID);
buffer[0] = PCA9685_CHANNEL_0 + (pca9685PinNumber[pinLoc] << 2);
buffer[1] = a & 0xFF;
buffer[2] = (a >> 8) & 0x1F;
buffer[3] = value & 0xFF;
buffer[4] = (value >> 8) & 0x1F;
write(pca9685I2Cfile[driverLoc], buffer, length); // initiate write
delay(5);
// verify GPIO pin was updated
bool f = 0; // flag to exit while loop
while (f == 0 && cnt < 3) // check if pca9685 received the signal
{
if (getPinLevel(pinID) == value) {f = 1;} // pca9685 was updated correctly
else { // pca9685 wasn't updated, try again
std::cout << "TRY AGAIN - new value: " << value << ", original value: " << originalValue << std::endl;
logError(3, to_string(pca9685AddressSaved[pinLoc]), "PCA9685 did not update");
delay(50);
f = 0;
buffer[0] = PCA9685_CHANNEL_0 + (pca9685PinNumber[pinLoc] << 2);
buffer[1] = a & 0xFF;
buffer[2] = (a >> 8) & 0x1F;
buffer[3] = value & 0xFF;
buffer[4] = (value >> 8) & 0x1F;
write(pca9685I2Cfile[driverLoc], buffer, length); // initiate write
delay(50);
cnt++;
}
}
// IF f IS 1, UPDATE WAS OK, IF 0, THEN WE ARE HERE AFTER 3 UNSUCCESFULL RETRIES, THEN WE FORCE BACK THE VALUE
if ( f != 1 ) {
std::cout << "TRY AGAIN EXPIRED FORCE PREVIOUS VALUE. original value: " << originalValue << std::endl;
logError(3, to_string(pca9685AddressSaved[pinLoc]), "PCA9685 did not update");
delay(50);
f = 0;
buffer[0] = PCA9685_CHANNEL_0 + (pca9685PinNumber[pinLoc] << 2);
buffer[1] = a & 0xFF;
buffer[2] = (a >> 8) & 0x1F;
buffer[3] = value & 0xFF;
buffer[4] = (originalValue >> 8) & 0x1F;
write(pca9685I2Cfile[driverLoc], buffer, length); // initiate write
delay(50);
}
}