Rule Base
Brian Miller
Posts: 25
I'm current working on a project to automate my saltwater reef filtration room for my Reef. My goal eventually would be to have some type of connectivity to my stamp board so I can push down rules base·for operation to an eprom·from a PC. I'm slowly learning my Basic Stamp and getting ideas on how to architect my system. I'm currently struggling on how to manage setting up some type of "rules base" for all of my I/O. I will have multiple relays turning lights, pumps and other device on and off. I will also have many inputs temp, ph, and float switches. Typically all of these things will be tied together so that if "float #4" fails then "pump·#5" gets shutdown/faulted. I know·this could all be done with multiple if statements, but I think I would run out of programing room very quickly.· Does anyone know of some books or resources that might discuss algorithms at this level?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Newbie, using the NX-1000 24/40 Board with a BS2p40
Comments
The BS2 however is likely very capable if I correctly understood your post.
When I run into a situation where the programing is not straight forward, I draw a flow chart. Once the chart is drawn, I test the chart by one at a time going through the chart with each different scenario.
Then write the program once the flow chart appears to be correct.
Do you know exactly how many inputs and outputs you will need?
Basicly, you define a number of states (S1-S3), identify events that can occur while in each state (E1-E4) ·and identify one or more actions to take take·(A1-A6) and (really important) what new state to enter after the actions have completed. (This includes staying in the current state.) All this is encoded in a data table that your system uses to monitor and control your system.
Your state machine table would be similar to: (it's hard to show code in this editor)
S1, E1, A1, S1··(In State1, when Event1, do Action1 and goto State1)
S1, E2, A1, A3, A5, S2 (In State1, when Event2, do Action1 , 3 and 5 and goto State2)
S2, E4, A2, A3, S3· (In State2, when Event4, do Action2 and 3·and goto State3)
For the Stamp... The Actions list would be a list of indices that identify individual functions. For example
You would use a Branch instruction to use the index to select the funtion label to branch to.
A common paramater passing variable(s) handles parm values. Your·FSM table could be defined to have a parm field-value associated with each action index.
A CurrentState parm tracks your systems current state.
*************
So... your finite state machine has a state-event-action table that you download. Changing behaviours is as simple as downloading a new state-event-action table. You would not need huge if-then-else sections to sort through what you want to do when event X occurs.
To begin this design, on paper, start drawing out the different states your system would be in, identify events that can occur in those states and then identify one or more actions to take in response to each event. Then show which new state your system goes to.
Once you've got the basic state-event-action architecture drawn you can begin defining the action functions paying close attention to parameter requirements. What is the best way to pass parameters? This may be your biggest challenge.
Don't forget to identify a default response in each state for an unexpected event. As well, you can identify a single DisplayUpdate action as the last step in response to every event
Is this understandable? Feel free to ask questions. I'll code review your design if you would like.
Bob
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
······ Bob, Ottawa
W75 54 17·· N45 18 30
·········· G16 #27
Thanks for taking the time to write up such an easy to understand explanation of a state machine.
I learned quite a few things, which I will be applying to future projects.
Dave G