Hi guys,
I'm having trouble in designing an application used to control several devices (tanning beds) connected through some relays to the control unit.
I have a state machine (state pattern) for the control unit itself (the Netburner), which has different states like "Initialization", "Idle", ...
In addition to that, for each device there has to be a state machine (containing states like "idle", "lead time", "running", "follow up").
There are also some shared resources like a RFID reader (which is not a problem) and a touch display which is being updated by the the control
unit state machine itself and the device state machine(s).
My first idea is to use some sort of message queue for the touch display. The touch display is being fed with the messages
by the control unit state machine ONLY. The device's state machines store their messages (synchronized access) to the display into
this queue.
Does the Netburner allow to create multiple threads (one thread per device connected)? I've read about tasks, which are
differently prioritized. Could this be a problem, since my devices have to run a specific time and have also to be turned off nearly in realtime?
Do you guys have a better idea concerning this design problem (of multiple state machines inside a state machine)? The application shall be
implemented in OO C++.
Thanks in advance!
State machine design problem
-
Chris Ruff
- Posts: 222
- Joined: Thu Apr 24, 2008 4:09 pm
- Location: topsail island, nc
- Contact:
Re: State machine design problem
I think your design sounds like the way to do it. You did not mention how each node (bed) communicates with the master, but if you have a select() instantiated in each task and you have n tasks, the tasks are all blocking- waiting on traffic to invoke the code below the select(). The effect of this design is that all tasks are 'there' all of the time (+ some number of tasks latency@ 50ms).
If you have 10 nodes the maximum latency for the worst-case task is 10x.05 seconds or 1/2 second. If that is too slow you can recompile your NB library with the TICKS_PER_SECOND set to some higher value- then the latency is decreased. If this is set too fine the bandwidth available to your code and the library code will be mitigated, but you can certainly double it to make a maximum latency 1/4 second for 10 nodes.
You can also channel-ize your working variables and have all n-nodes operating in the same single task state machine. You pick up the activity in the interrupt and steer which channel the state machine is going to operate on next from the interrupt code.
Sounds like a great app to be working on. Make sure you leave some bugs in so that you have to show up occasionally during the time the beds are in play....
wink-wink nudge-nudge
Chris
If you have 10 nodes the maximum latency for the worst-case task is 10x.05 seconds or 1/2 second. If that is too slow you can recompile your NB library with the TICKS_PER_SECOND set to some higher value- then the latency is decreased. If this is set too fine the bandwidth available to your code and the library code will be mitigated, but you can certainly double it to make a maximum latency 1/4 second for 10 nodes.
You can also channel-ize your working variables and have all n-nodes operating in the same single task state machine. You pick up the activity in the interrupt and steer which channel the state machine is going to operate on next from the interrupt code.
Sounds like a great app to be working on. Make sure you leave some bugs in so that you have to show up occasionally during the time the beds are in play....
wink-wink nudge-nudge
Chris
Real Programmers don't comment their code. If it was hard to write, it should be hard to understand
Re: State machine design problem
The OS is a real-time OS, so it is well suited for your timing. If I understand your description, I would consider using one task for all your network communications with a select() call that will return if any data is received for any of the tcp sockets. I don't think you need to change the ticks per second, since the RTOS scheduler will be called for any interrupt, including receiving a network packet. Make this receive task a higher priority (lower number) than your other tasks since it will block until data is received. Increasing the ticks per second too much can actually cause more latency in your system since the timer task gets called more often.