一直在苦苦思索对于一种大规模的控制系统，譬如一个包含50+个motor，200+ IO，以及flow控制、流量控制等多种控制的系统，如果进行有效率，如何按照一定结构进行组织管理。 在学校从来没有遇到过这么复杂的系统，在学校作研究和工作了做研究的重点完全是不一样的。在学校研究的东西可能很难，但是不复杂；现在做的东西不难，但是很复杂，要很好的把整个系统结构化起来是件很困难的事情。 code能run，和code便于维护完全是几乎是不相干的2码事情。 由于工作需要，接触了些fsm编程，感觉这是一种非常好的编程思想。 写state machine感觉就像是自己在写os schedule multi-task的东西，每个task什么时候该做什么事，什么时候被scan到完全是自己控制的。缺点是，state一多的话，写code的人本身就被搞得晕乎乎的。 之前的一个项目做下来，发现其实并不难的一个项目如今做的并没有自己预想的那样那么顺利，问题很多。 主要在整个project的style不一致， module之间分工不明确，module之间调用方法不合理，模块之间通讯方式有问题。 更大的问题是，因为尽量用1个thread完成多任务操作，所以每个state machien的状态超多，写到后来简单的一个sequence动作竟然要写上几十条语句才能完成，而一个多线程的写法可能10条语句内就全部搞定了。 State Machine的思想用于工业控制是个非常不错的思路，但是如何进行有效合理的使用，是个一直困扰我的问题。 工作需要慢慢接触到一些整合到系统的PLC部分代码，突然发现PLC的思想和State Machine是多么的相近。 同样都是根据某些变量而进行判断执行对应的代码，同样需要scan，同样都是模块化设计，同样都是用于工业软件开发。 今晚偶然的发现了下面的这篇文章，对我的启发很大。
