Why does Serial.print() fix my code

Projects Programming
1

I'm having a sporadic issue that goes away when I include a Serial print.The machine normally has nothing connected to the Serial port; I am only using it for debugging and initial programming. When I press the Start button on the machine (or 'FaultResetButton'), it will print several messages to serial than start the machine after a 150 millisecond delay. However, if I comment out: "Serial.print(F("StartChanged "))" it will skip all the Serial prints after the debounce and immediately start the motor. Sometimes, it wont even start the motor. I find it very strange that the Serial print must be included even if nothing is connected to the port. Any Suggestions?

void StartStop()
{

  /////________     Start       _________/////
  
  int Startreading = digitalRead(FaultResetButton);
 
  if (Startreading != LastStartReading)
  {
    
    lastDebounceTime = millis();
    StartState = 1;
    //Serial.print(F("StartChanged ")); //<-- MUST BE PRESENT
    
  }
  if (StartState == 1 && (millis() - lastDebounceTime) > debounceDelay)
  {
    if (MachineStopped == 1)
    {
      if (digitalRead(FaultResetButton) == LOW && DownstreamJam == 0)
      {

        Serial.print(F("Start - "));
        RunState = 1;
        StartState = 0;
        MachineStopped = 0;
        BoxIsWiped = 0;
        Zone1Wiped = 0;
        Zone2Wiped = 0;
        lastEntryPEState = digitalRead(EntryPE);
        lastExitPEState = digitalRead(ExitPE);
        EntryPEState = lastEntryPEState;
        ExitPEState = lastExitPEState;
        LastTopCounts = TopCounts;
        LastBottomCounts = BottomCounts;
        Serial.print(F("RunState: "));
        Serial.println(RunState);
        delay(150);
        if (MachineSetup != 20)
        {

         
          digitalWrite(UpstreamConveyor, HIGH);
          MotorState = 1;//StartMotors
          Serial.println(F("motorRun"));
        }
        BoxState = 0;
      }
if (MotorState != lastMotorState)
  {
    digitalWrite(MotorRelayPin, MotorState);
    Serial.println(F("MOTORSTATE CHANGED"));
    lastMotorState = MotorState;
  }
    }

ELECDIAMSD.pdf (31.6 KB)

BPduino_AS1c.ino (13.9 KB)

FunctioningConsistentlyWithSerial.JPG
FunctioningConsistentlyWithSerial.JPG1065×206 54.4 KB

InconsistentWithoutSerial.JPG
InconsistentWithoutSerial.JPG1119×215 43 KB

BP_Variables.h (5.13 KB)

2

Usually the commenting out of a specific line of code causing a sketch to work or crash means you are running short on SRAM.

1 Like
3

I agree, but I'm using an atmega 1284 with only 11% sram and 14% program memory utilized- I should be more than fine. However, in my experience, the reverse is true, where adding prints with lots text causes instability. But in this case, I have tried to use the (F()) macro everywhere and the problems start when I remove it.

5

With out the whole code its hard to say but my guess would be that serial print is acting as a delay.

with out seeing the rest of the code theres no way to tell.

6

You forgot to post BP_variables.h

7

sterretje:
You forgot to post BP_variables.h

I just added it to the original post.

gpop1:
With out the whole code its hard to say ....

The whole project has several thousand lines of code. If you really want to wade through it, I'll post it, but the relevant part is shown, IMHO. The average cycle time is approximately 40msecs without any delays(). I'll add a delay() in that spot to see if gives the same result.

8

Yes, a delay shorter than 10msecs in place of the serial print causes an inconsistent response. So the serial print is acting like a delay.

9

If you have memory issues, every line of code can be relevant.

Zip the whole thing and post it here. Somebody might have time.

10

seanz2003:
Yes, a delay shorter than 10msecs in place of the serial print causes an inconsistent response. So the serial print is acting like a delay.

yep thought so. It does seem odd to

lastDebounceTime = millis();

in a code where the next line practically says

if (StartState == 1 && (millis() - lastDebounceTime) > debounceDelay)

I would have expected a separate if to reset the timer.

so

if (Startreading != LastStartReading)//run code

else //reset the debounce

im guessing your debounce delay is very short (under 10 millis) which is why the serial print acting as a delay makes the code operate the way you intended.