JKI状态机最佳操练

Scadao

JKI状态机编辑器

JKI近来发布了JKI状态机编辑器，这是款新型强大工具，使得LabVIEW工程师更加容易管理开发使用JKI状态机，比如通常添加、删除、拷贝状态任务，当前可添加动态事件。

随着试用反馈测试，近期版本的更新发布，作了几个方面的提升：

·使用体验启动更快
·UI反应更敏捷，更流水线化
·修复了几个繁琐操作


现下载使用JKI状态机编辑器

也可通过VIPM进行下载：

Scadao

5. 左对齐替代右对齐状态字符串

这次发帖，我们聊聊简单的，当然在实际项目中也是很重要的，这将使得你的代码可读性较佳，方便你后续开发和其他工程师的调用。

左对齐文本可读性较友好


右对齐文本可读性较困难


左对齐有助于多行文本目录标题分类/分组，一目了然。

这里我们预览下左对齐字符串常量的操作，首先从状态机左边拷贝“Macro:Initialize”字符串常量，下图操作过程展示其起点：

Scadao

4. 使用宏替代链式序列状态


宏是其它状态列表的一个简单集合，调用宏就如同调用所有列表中的状态。


有必要说下，在宏条件分支结构中，是没有做具体工作的，我们仅是简单罗列了一下队列状态序列。

这儿我们使用三个状态来作为范例演示下宏的作用：


使用宏会让我们对代码流程的理解更清晰；很明显调用宏即是执行状态序列，也很容易看到状态序列。

不太好的习惯是使用链式状态。

这里展示下链式状态序列，每个状态依次调用下一个状态：


跟宏相比，这就很没必要，因为：

a）链式各个状态间调用不是那么一目了然——也即不能一眼看出调用完“State 1”后是调用“State 2”，然后是调用“State 3”。


b) 在其他序列操作中要复用这些状态是相当困难的。因为链式序列中的每个状态都是紧密耦合的，比如要调用“State 3”，必须先调用“State 2”.

为什么要使用宏？为什么链式状态会将我们陷入困境？现在我们已经相当清楚了。

综观上述，你在实际案例中可能会动态按需按项目条件来切换配置宏的内容，这依赖系统状态，在构建宏时，可能这些信息不太具备。在这些情况下，我们可以使用一些特殊的技术，这将在以后的论坛中讨论这些技术。敬请关注！

Scadao

3.　保留原生架构尺度（比如不要去催生壮大架构）

JKI状态机窗口尺寸要在程序框图中小心设计成合理大小，“LabVIEW风格程序框图清单”告诉我们：

“避免创建太大的程序框图，[...]程序框图内容窗口大小会影响LabVIEW代码的可读性，确保其尺寸不要大于屏幕边框。”

当然，显示屏的尺寸是越来越大，如所谓的雷电屏，程序框图同时也随着变得越来越大。


还有，在你的JKI状态机演练中，你要小心避免窗口变化，因为我们限制它的尺寸，模块化你的代码是种好事，下面我们就要讨论，这些相互对应方法来实现……

首要注意的是确保JKI状态机尺寸发生变化：
·避免使用Ctrl拖曳方式插入到LabVIEW程序框图中；
·在JKI状态机中，针对所有结构将“自动扩展”功能关闭，有While循环、Case条件语句和事件结构。


第二点，随着你的应用逻辑和代码复杂度会越来越扩展，你可能需要模块化你的代码，比如不要试着在一个条件框中去做所有事情。可采取下面方法：
·将代码嵌入到子VI中
·针对你的状态机创建附加状态，以便组织分类到各自相关区域


记住，一旦你扩展你的JKI状态机，要想去缩小其规模，这几乎是不可能的，但通过我们的思想交流碰撞，这在将来是有可能的！

Scadao

2.　不要在事件结构中添加代码和逻辑判断

将代码依逻辑放在条件分支结构中，不要在事件结构中添加代码和逻辑。

我们这里的意思是要养成两种好习惯：
a) 事件结构仅产生状态字符串队列；

b) 条件分支结构做具体工作

a) 在事件结构中，通过简单添加状态到队列中来处理用户接口事件（即不要做具体事情）


b) 在条件分支结构中，嵌入代码做具体工作


不好的习惯：事件结构中包揽所有的工作
这种坏习惯就象下面这般将所有工作细节放在事件结构当中：


为什么？因为1）比较难复用代码；2）它锁住了用户接口。
有些细微差别：

1）条件结构中的代码比较容易复用
因为这样能简化状态机中的状态调用——那也是JKI状态机被设计成怎样工作的。与之相反，在事件结构中复用代码是比较困难的，你不得不通过调用Signal Value值属性来处理事件。这是人们普遍不喜欢的做法，因为读取调试这种代码是比较困难的，你不知道UI事件到底是用户还是编程代码引起的。

2）条件结构中的执行代码没有锁住用户接口
事件结构中的代码执行锁住了UI，因此给软件终端用户的体验度很差。某些情况下，这种糟糕被锁看起来好像软件崩溃了。
要点：通常来说，你应该只使用事件结构来捕获前面板和动态事件，事件结构添加状态字符串到队列中，条件分支结构调用状态字符串，功能代码放在其中。

这里需要指出下在事件结构中针对状态/条件进行判断切换是允许的，值得推介。


上文综述如下：不要在事件结构中添加代码和逻辑序列，要将这些功能码放在条件结构语句当中。

Scadao

1.　不要在子VI中隐藏状态字符串

下面两截图说明了：
较好的习惯：保留状态字符串在程序框图


不好的习惯：将状态字符串封装进子VI


我们JKI状态机在程序框图保留状态字符串，比封装在子VI，具备这些方面的关键好处：
A）提升代码可读性——在JKI状态机中，你没必要通过子VI去了解整个程序的逻辑流程，这使得你编码更快，也是JKI状态机关键目的所在之一。如果将代码放在子VI里面，将使得代码可读性和可维护性很差；

B）可在LabVIEW中创建“Find”对话框——你可在JKI状态机中通过指定状态字符串，从而在程序框图中查找到这部份VI内容。
举例来说，在程序框图中通过按“Ctrl+F”键，可搜索查找对象和类似“UI:Initialize”那样的文本内容，确保查找内容处于VI搜索范围。

单击“Find”就会在你的VI框图中寻找到所有包含“UI:Initialize”字符VI片段内容。


VI程序框图的状态字符串查找（替代）功能是款强劲的工具，如果你将状态字符串封装进子VI中，就显示不了这种功能。

C）状态转移的逻辑性与其应用代码其余部份之间的耦合是松散的——驻留在软件中的JKI状态机逻辑流程是松散耦合的，这意味着对某个VI的更改不会无意中影响到其他地方代码的功能。
要点：要保留好JKI状态机在程序框图中的状态字符串，请多加利用这种优势，而不要隐藏封装在子VI中！