The StateMachineProject.ini file I attached in post #235 has everything that your sketch has.
If you give it a try, you will see it gives the same results as yours.
Don’t beat your head in trying to understand what’s happening, ask questions when you need help with an section.
A State Machine format has many advantages:
It is logical, clean, easy to follow and maintain.
All state coding follows one format.
It is extremely easy to add new states and associated tasks.
In this example, all timing is handled in one place, by the simple CheckTime() function.
States can be run once, repeatedly run, suspended/disabled and schedule.
More importantly, a State Machine lends itself to 'non-blocking' behaviour.
Spaghetti style code is avoided when you follow proper State Machine formatting.
After using State Machines a few times in your larger projects, you will not go back to sequential code writing.
If you download the file in post #242, you will see this at the top:
//*******************************************************************************
// YY/MM/DD Version Reason
// 18/01/08 1.01 Added GHheatControl section
Then you will see 5 lines further down the sketch with 1.01 at the far right side of the screen.
Alright I got it. Had to delete some older stuff first.
Are you sure I'm ready for this? I don't even have my training wheels off!!
Are you trying to make a programmer out of me?
I can kinda follow what's happening but I'm not understanding a whole lot of this.
When you first threw this out, it made me think that you were fishing to see if I'd bite. I went to Red Lake Ontario for 20 some years. I'd move to a new spot, change up the bait, etc. just to see if the walleye's would bite. I can just see you "changing the bait" - smiling the whole time - to see if I'll take the bait.
I'll bite. I'll swallow this deep. Be prepared cause I'll have LOT"S of questions.
There are others following this from the # of downloads. You folks pipe in here. You may ask the question that makes my "ah ha" moment. Believe me I can use all of of those I can get!
I've done some poking around today to try to understand this better.
Moore published in 1956 and is most restrictive.
Mealy published in 1955 and can work with inputs to the system and within transitions.
Harel in the 80's working with the aviation industry and added some extras. (Notice the 30 year delay)
These guys are all mathematicians!!!!!!!!!!!!
This interests me as I had an uncle that was a mathematics professor and another uncle that programmed for NASA for a while. That would have been back in the 50's - 70's.
Given that the computer used on the Moon landing had less power that the first basic hand calculators - It had to be a state machine. There were lot's of buttons pushed and switched flicked.
I'm not quite sure how to present my questions. I can copy the lines and paste in the post (that's how I'm going to start). If there is another way let me know what you want to see.
#1. State could be any term? Sate makes sense just curious.
I suppose, 'State' could mean just about anything.
In your example we are checking different sections of code to see if they need attention.
In the latest version, we have defined 6 possible states that your machine can be in.
StateStart, StateDHT22, StateUniversal, StateSoil_moisture, StatePrint and StateGHheatControl.
StateStart is when we first power on the controller. It is entirely possible that you do nothing here.
StateDHT22 is when we check to see if it is time to handle the DHT22 stuff.
. . .
StateGHheatControl is when we determine if the green house heater should be turned on or off.
In this example, a dedicated timer is running for each possible state. The timer is used to determine if that 'State' code should be executed.
There are 6 states defined below:
//define the available states that we can have for this sketch
enum States
{
//add more states as needed
StateStart, StateDHT22, StateUniversal, StateSoil_moisture, StatePrint, StateGHheatControl // 1.01
};
States mState = StateStart; //we start out in this machine state
enum States >>>---> defines a new 'type' called State
This similar to int, byte and float etc.
Where we have type int, type byte and type float
Below, we are giving names to all the possible states in your sketch.
You can refer to these in your code just like you do with other variables.
These are 'integers values' starting at 0 going up.
Where StateStart = 0, StateDHT22 = 1, StateUniversal = 2 . . .StateGHheatControl = 5.
You really don't need to know what these variables equal as the compiler figures it out for you.
{
//add more states as needed
StateStart, StateDHT22, StateUniversal, StateSoil_moisture, StatePrint, StateGHheatControl // 1.01
};
States mState = StateStart; >>>---> we are creating a variable called mState (machine state) and are setting it equal to what StartState equals.
mState can have the value of 0-5.
This is similar to int myVariable = 0. Where int is the 'type', myVariable is similar to mState and 0 is similar to StartState
Test time: Let's say we have the following lines of code, what is printed?
mState = StatePrint;
Serial.println(mState);
Ok - I'm kinda following that. I'll refer back to it a few more times before I'm done.
Next;
unsigned long testMillis; Questions on what this is used for.
unsigned long currentMillis; I get what this is doing.
unsigned long BlockingMillis; Questions on what this is used for.
unsigned long testMillis; We are define a new global variable called testMillis. It has a 'type' of
unsigned long. During sketch writing, we often use temporary variables to debug things. Hence testMillis was used for debugging purposes only.
unsigned long currentMillis;
unsigned long BlockingMillis; We are define a new global variable called BlockingMillis. It has a 'type' of unsigned long. This is a variable that is used in flashing a LED found on pin 13 on the Mega. I use it to show when the program is running properly i.e. if it flashes things are tickety boo.
