Я согласен с тем, что сценарии LabVIEW - это один из подходов, но позвольте мне выбрасывать еще один вариант.
Если вы планируете одноразовую миграцию с вашего тестового кода на LabVIEW, а не на сценарии, но если вы планируете регулярно обновлять свой тестовый код (потому что проще использовать «тестовый» язык, чем LabVIEW), чем может быть довольно болезненно постоянно выполнять миграцию каждый раз, когда ваш тестовый код изменился.
У меня был большой успех, просто поместив мой state machine внутри цикла for, а затем прочитав «команды» из текстового файла, который был сгенерирован с использованием моего «тестового» языка (см. Рис.).
Например, чтобы сделать внутривенный подметать мой текстовый файл может сказать что-то вроде:
SourceV, 5
ReadI
Wait, 1
SourceV, 6
ReadI
Это изображение значительно упрощаются - я не использую государственную машину, и я не показываю, как использовать «параметры», но при необходимости я могу предоставить более полный пример. Опять же, я имел большой успех, делая это с помощью около 30 «команд», управляющих несколькими инструментами, а затем я сгенерировал ввод текста с помощью VBA или Python. 
Является ли мой ответ достаточно ясным? Было бы полезно расширить? – Charlie
Ваш лучший вариант с Matlab или другой структурой для такого рода вещей. Я работал с Labview около 5 лет и нашел, что большинство других программ было лучше в этом. – Greg
@Greg: Есть причина, по которой я не могу использовать Matlab: я буду водить скамейку, которая работает с Veristand, которую ведет Labview. –