再次回忆“根本状况机形式”的6个缺陷，只剩下第6个缺陷无法在上述的“状况机和事情结构的结合形式”中被处理。
- 任何时刻只能有一个状况在运转
这个问题或许有些剩余，可是在实践的使用中往往又是最常见的。大多数比较复杂的使用至少应该有“菜单”和“收集”两个状况，假如数据收集程序在运转时依然期望体系能够处理菜单的事情，这是在传统的状况机或许事情结构中无法完成的。由于无论是状况机结构仍是事情结构，都是由一个循环组成的，不同的状况是无法一起被响应和处理的。
处理这个问题的方法也比较简单，LabVIEW自身便是一种多线程的程序设计语言，能够再加一个循环或许别的开一个程序独立运转。可是这样也会带来一些新的问题，比方：
- 两个循环（程序）之间怎么交流和同享数据。
- 两个循环（程序）都有着独立的过错处理体系，它们之间是怎么和谐的。
- 两个循环怎么分工呢？应该以哪种方法对状况进行分类以将不同的状况放置在不同的循环（程序）中？
- 一个程序怎么操控另一个程序的运转和中止。
在上面提出的4个问题中，对循环和程序这两个处理方案而言，第（1）~（3）个问题的处理方法是相同的。只要第（4）个问题是专门针对两个程序而言的，在LabVIEW中这种不同程序之间的彼此调用称为“程序的动态调用”。
