NI TestStand

Ответить
Аватара пользователя
Kosist

Activity Gold
expert
expert
Сообщения: 1236
Зарегистрирован: 21 фев 2011, 23:44
Награды: 2
Версия LabVIEW: 2013-2020
Благодарил (а): 23 раза
Поблагодарили: 30 раз
Контактная информация:

NI TestStand

Сообщение Kosist »

NI TestStand – це один із потужних і цікавих програмних продуктів від National Instruments, основна задача якого – створення програм для автоматичного тестування і валідації. Як правило, тест-програма представляє собою набір послідовних інструкцій/функцій/кроків, які необхідно виконати для тестування того чи іншого продукту. Така послідовність – sequence – також вимагає деяких більш загальних операцій, як вхід в систему оператором, зчитування серійного номеру продукту, запис до бази данних, і т.д. І – що головне – тест-процедура не передбачує великої варіації дій, як в випадку звичайних програм для моніторингу, контролю, і т.д.
TestStand – по-суті, є фреймворком для створення і виконання таких послідовностей. Завдяки своєму ядру, TestStand Engine, він дозволяє сконцентруватися лише на імплементації програмних код-модулів, а контроль за виконанням, порядком дій, і т.д. він бере на себе. Іншими словами – логіка і порядок виконання тих чи інших ділянок програмного коду є визначеною, і розробнику софту потрібно лише підключити свої програмні код-модулі в потрібне місце.

Відразу постає питання – навіщо користуватися TestStand, якщо такий самий код можна зробити і в самому LabVIEW? Адже за допомогою тієї ж стейт-машини можна просто і легко імплементувати логіку послідовного виконання тих чи інших дій? Але, уявіть лише тест процедуру, що складається із 100, 200 чи 500 кроків? При цьому, потрібно буде вимірювати різні фізичні величини, за допомогою різного заліза; порівнювати отримані результати із лімітами, відображати результати порівняння; робити переходи між різними ділянками тест-процедури; виконувати декілька тест-процедур паралельно. Звичайно, що LabVIEW дозволить все це зробити, але під кінець такий код буде важко підтримувати, модифікувати, і використовувати для нових проектів.

В TestStand, навпаки, буде використовуватися інший підхід. Головне – це розбити тест-процедуру на одиночні кроки, і імплементувати для кожного типу кроку свій код модуль. Код модуль – повинен мати контроли і індикатори на лицевій панелі, підключені до connector pane. Таким чином, коли код модуль буде добавлений в послідовність – далі я називатиму її sequence – можна буде отримувати доступ до входів/виходів код модулю, передавати параметри в нього, і зчитувати данні після його виконання.

Далі, я намагатимуся розповідати про основні функції та особливості TestStand... Я не претендую називати це уроками, чи туторіалом; це буде просто дуже стислий огляд головних тем, які використовуються при роботі з TestStand. Хотілося б почути ваші відгуки - чи потрібна ця тема взагалі, на що більше звернути уваги, які теми будуть цікавими, а які - ні... Це моя перша спроба в подібному роді, тому, в разі чого, прошу сильно не бити :wink: , але буду дуже радий почути будь-яку критику і побажання :think:
Мы делили апельсин - много наших полегло...
Аватара пользователя
Kosist

Activity Gold
expert
expert
Сообщения: 1236
Зарегистрирован: 21 фев 2011, 23:44
Награды: 2
Версия LabVIEW: 2013-2020
Благодарил (а): 23 раза
Поблагодарили: 30 раз
Контактная информация:

Re: NI TestStand

Сообщение Kosist »

Для початку, розглянемо інтерфейс.
TS view.png
1. Insertion Pallete - містить всі можливі типи кроків, які можна створити в TestStand. Кроки розбиті на логічні групи; іконка над ними відображає тип адаптеру, який використовується для кроків. Щоб вставити крок із Insertion Pallete, треба вибрати необхідний, і зробити drag-and-drop.
2. Sequence File View – власне, тут відображаються всі кроки та налаштування sequence, вибранної зі списку послідовностей.
3. Variables. TestStand має 4 основних типи змінних, а саме: Locals, Parameters, FileGlobals, StationGlobals. Основна їх різниця – це область їх доступності, scope. Так, Locals – доступні лише в рамках однієї послідовності; при виході із неї (при завершенні її виконання) всі значення змінних обнуляються, і в інших послідовностях вони не доступні. Parameters – дозволяють передавати значення змінних в і з під-послідовностей (про це я напишу пізніше). FileGlobals – доступні в рамках одного файлу послідовностей (sequence file); і по закінченню однієї ітерації його виконання вони не обнуляються. StationGlobals – доступні для будь-яких файлів послідовностей, в рамках однієї робочої станції, по суті – комп*ютера.
4. Sequences View. Тут відображається список послідовностей, які використовуються/створені в данному файлі послідовностей.
5. Templates. Дозволяє роботи доволі цікаву річ – за допомогою drag-and-drop в данне поле можна добавляти найбільш вживані кроки, змінні, і т.д.; які будуть доступні в усіх файлах послідовностей на данному комп’ютері, але при переносі файлів на інші машини, данні шаблони не будуть там відображатися.
6. Step Settings. При виділенні кроку в полі Sequence File View, в Step Settings будуть відображатися всі налаштування данного кроку. В залежності, який саме це крок, будуть доступні різні властивості – що, само собою, зрозуміло... Для код модулів, створених в LabVIEW, як видно на скріншоті, доступна Connector Pane, за допомогою якої данні передаються із TestStand в код модуль (за допомогою контролів код модулю), і навпаки (за допомогою індикаторів).

І, наостанок, варто згадати про головні типи кроків, які використовуються в TestStand

TestStand має різноманітні види кроків. Наприклад, це Action, Pass/Fail Test, Numeric Limit Test, String Value Test, і т.д.
Action – це просто дія. Вона не являється тестом. Зазвичай, це дія типу «ініціалізувати прилад», «активувати/деактивувати цифровий вихід», «переключити канал мультиплексору», тощо.
Pass/Fail Test – це вже тест, тобто дія, результат якої є визначений, і в разі, якщо очікуваний результат не співпадає з реальним, тест є «проваленим» (fail). Pass/Fail Test «працює» з типом данних Boolean. Наприклад – це зчитування стану цифрової лінії, чи порівняння стану декількох ліній, і т.д.
Numeric Limit Test – «працює» з числами, і автоматично порівнює результат тесту з заданими лімітами. Для такого типу кроку можна присвоювати значення нижньої і верхньої границі ліміту, а також тип порівняння (>, >=<=, і т.д.), одиниці вимірювання, і треба вказати, який самий параметр буде порівнюватися. Зазвичай, це корисно для вимірювань – зчитування напруги за допомогою AI карти, чи DMM, і т.д.
String Value Test – «працює» з типом данних string, і порівнює отриманий текст із передбачуваним, лімітом. Наприклад, це може бути відповідь мікроконтроллера на якийсь конкретний запит.

Наостанок, на сайті NI, присутня купа матеріалів по TestStand - починаючи від азів, і закінчуючи статтями для "просунутого" програмування. Ось деякі з них: http://www.ni.com/teststand/resources/,
http://www.ni.com/white-paper/3395/en/,
http://www.ni.com/white-paper/14905/en/,

ну, і ще багато інших - гугл завжди допоможе тим, хто шукає =))

В наступній темі, коли знову з*явиться час, хотілося б розповісти про налаштування TestStand перед початком роботи, а також описати простий приклад створення тест-процедури...
Мы делили апельсин - много наших полегло...
Аватара пользователя
Pavel Krivozubov

Activity Bronze
professor
professor
Сообщения: 4421
Зарегистрирован: 07 фев 2008, 16:39
Награды: 3
Версия LabVIEW: 7.0 - 2013
Откуда: г. Электросталь
Благодарил (а): 24 раза
Поблагодарили: 9 раз
Контактная информация:

Re: NI TestStand

Сообщение Pavel Krivozubov »

Отлично! ты пока первый и единственный претендент на победу в конкурсе языковых веток!
Аватара пользователя
Kosist

Activity Gold
expert
expert
Сообщения: 1236
Зарегистрирован: 21 фев 2011, 23:44
Награды: 2
Версия LabVIEW: 2013-2020
Благодарил (а): 23 раза
Поблагодарили: 30 раз
Контактная информация:

Re: NI TestStand

Сообщение Kosist »

Продовжую розповідь )))) Перед тим, як почати створювати тест-послідовність, хотілося б згадати про дві теми. Перша з них – це налаштування Search Directories.
Налаштування Search Directories можна знайти за допомогою меню Configure -> Search Directories. Навіщо вони потрібні? При доданні код модулю до кроку в TestStand, TestStand може «підвантажити» код модуль використовуючи або повний шлях до нього, або відносний. Відносний шлях до код модуля кращий, оскільки при переносі коду на іншу машину, не треба буде знову «підвантажувати» всі код модулі по новим шляхам, вони вже будуть налаштовані правильно. Саме теки Search Directories TestStand використовує для пошуку програмних код-модулів, і «будує» відносно них відносний шлях до код модулю.
Таким чином, при створенні проекту, краще створити одну теку, в якій вже будуть інші теки з файлами послідовності, і теки з код модулями. А потім, добавити головну теку з код модулями в Search Directories. Таким чином, проблем із шляхами не виникне.
Це, по суті, маленька деталь, але її слід пам*ятати, щоб в разі чого не виникало сюрпризів із «пропавшими» код-модулями в файлі послідовності.

Друга тема – це більш детальний розгляд типів кроків, які безпосередньо використовуються при тестах, а точніше – розгляд їх налаштувань.
Нижче я приводитиму скріни налаштувань, із коротким поясненням головних із них.

Вкладка Properties.
General.png
General. Назва говорить сама за себе =)) Корисна вкладка тим, що в ній можна прямо змінювати тип адаптеру, а також тип кроку – просто вибравши необхідний із меню. Ім*я – як на мене, зручніше змінювати прямо в полі Sequence View.
Looping.png
Looping. Дозволяє зациклювати виконання код модулю по деякій умові; або ж не зациклювати взагалі (дефолтне значення). Корисне тоді, коли тест процедура дозволяє повторювати кроки до тих пір, доки не буде отриманий правильний результат. Але, зациклювання по таймауту – краще робити іншим способом, за допомогою стандартних засобів таймаут реалізувати важкувато...
Post Actions.png
Post Actions. Активні для кроків-тестів. Дозволяють обирати переходи між кроками, в разі проходження, або не проходження тесту. Але, краще ними не зловживати, бо можна потім загубитися у переходах... Також, є така невелика деталь – якщо, скажімо, спочатку ви налаштували перехід на певний крок, а потім той крок був видалений – при виконанні тесту згенерується помилка. І данний «косяк» в коді не вдасться виявити стандартним аналізом файлу-послідовності...
Expressions.png
Expressions. Дозволяють прописувати вирази, які повинні виконатися або перед виконанням кроку (Pre-Expression), або після його виконання (Post-Expression), але в рамці одного кроку. Тобто, якщо крок не буде виконаний, то і вирази також не будуть виконані.
Preconditions.png
Preconditions. Це поле має Boolean тип; і якщо воно буде пустим, або матиме значення True – крок буде виконаний; якщо ж матиме значення False – крок виконаний не буде. Корисний функціонал тим, що іноді дозволяє уникнути використання структур If … Else; т.к. дозволяє реалізувати логіку вибору виконання кроку прямо в налаштуваннях кроку.

Вкладка Module.
Module.png
Як я писав уже вище, ця вкладка відображає входи-виходи код модулю, дозволяє завантажити код модуль, відкрити його; перезавантажити (наприклад, якщо код модуль був добавлений в крок, а потім його connector pane була змінена/оновлена, крок потрібно перезавантажити знову), і т.д.

Вкладка Limits.
Limits.png
Для кроків типу Numeric Limit Test, само собою, вона дозволяє вибрати тип порівняння, вказати нижній і верхній ліміт, а також вибрати фізичну величину тесту, якщо така є; і форматування результату. Для кроку типу String Value Test вона трохи інша, і містить вибір порівнянн – з/без урахування регістру; а також поле з очікуваним текстом. Кроки типу Pass/Fail Test такої вкладки не мають взагалі.

Вкладка Data Source.
Step Result.png
Кожен із типів кроків-тестів має свою змінну, яку він використовує для проведення тесту – порівняння її значення із очікуваними лімітами. Для Numeric Limit Test – Step.Result.Numeric; для String Value Test – Step.Result.String, і для Pass/Fail Test – Step.Result.PassFail.
Що саме це означає? На скріншоті для вкладки Module, Step.Result.Numeric є присвоєна до виходу код модулю Result. Таким чином, коли код модуль буде виконаний, значення індикатора Result буде присвоєне змінній Step.Result.Numeric, і буде порівняне з лімітами.

Як ще можна це використовувати? Дуже просто. Уявіть, що вимірюється напруга, а тест повинен проводити порівняння струму через опір заданної величини. Значить, спочатку виміряну напругу треба перерахувати в струм, а вже потім – порівнювати. Значить, вихід код модулю Result треба присвоїти якійсь проміжній змінній (нехай це буде Locals.Voltage), і в Post-Expressions зробити конвертацію, як показано на скріншоті.
Test 2.png
Таким чином, код модуль може бути більш універсальним – і не треба імплементувати перерахунок напруги в струм в ньому, добавляти додатковий індикатор, і т.д., і т.п. – ви просто проводите необхідні перерахунки в Post Expressions.
В принципі, якщо запустити данну послідовність зараз (достатньо вибрати Execute -> Test UUTs; або натиснути зелену «плей» кнопку на панелі інструментів), вона вже виконається, як тест. Але, це ще не є повноцінний приклад, оскільки в ньому не використовується ще одна особливість TestStand, а саме – Process Model Callbacks.

Продовження буде слідувати в наступних постах )))
Мы делили апельсин - много наших полегло...
Аватара пользователя
Kosist

Activity Gold
expert
expert
Сообщения: 1236
Зарегистрирован: 21 фев 2011, 23:44
Награды: 2
Версия LabVIEW: 2013-2020
Благодарил (а): 23 раза
Поблагодарили: 30 раз
Контактная информация:

Re: NI TestStand

Сообщение Kosist »

Сьогоднішній пост буде присвячений простому прикладу тест-послідовності.

Уявімо, що потрібно реалізувати наступну послідовність.
1. На початку виконання серій тесту, оператор повинен задати шлях для збереження тест-звітів; ліміти для «вимірювання», а також затримку перед і після проведення вимірювання.
2. Перед кожним циклом тестування, оператор задає серійний номер та модель виробу, що тестується.
3. Під час тесту вимірюється напруга на виходах виробу, що тестується.
4. Після закінчення циклу тестування, данні зберігаються до простого файлу-звіту.

Само собою, що приклад дуже простий, але основи створення більш складніших послідовностей, надіюся, на ньому теж будуть зрозумілі.
Що нам спочатку треба? Створити код-модулі.

Я підготував такі:
1. Settings.vi – діалогове вікно для введення параметрів тесту.
2. UUT_Info.vi – діалогове вікно для введення інформації про виріб, що тестується (UUT – unit under test).
3. Timer_FGV.vi – FGV-віайка для моніторингу часу виконання.
4. RandomGenerator.vi – власне, віайка для генерації результатів вимірювання.
5. LogResults.vi – створення тест-звіту в простій формі.
6. StopSequence.vi – діалогове вікно для зупинення тест-послідовності.

А тепер, де ж викликати ці віайки? В цьому випадку треба трохи розглянути моделі, згідно який відбувається виконання тест послідовності в TestStand.
Існує три основні моделі: Sequential Process Model, коли виконується лише одна тест-послідовність за один раз. Parallel Process Model – коли виконується тестування декількох одиниць, незалежно одна від одної. Тобто, тест-послідовності можна запускати в декількох потоках, незалежно одна від одної. Batch Process Model – коли виконується декілька потоків тест-послідовностей, але всі вони синхронізовані між собою – мінімум на початку та кінці тесту, максимум – на довільних ділянках, як того вимагає тест-процедура.
Кожна з Process Model використовує свої Callbacks – це теж, по-суті, тест-послідовності, в які можна добавляти свій код, і які будуть виконуватися в певний час виконання основної тест-послідовності. Основні колбеки:
1- Process Setup – виконується один раз, при запуску файлу тест-послідовності.
2- PreUUT– виконується на початку кожної нової тест-ітерації.
3- Main Sequence – містить основну логіку тесту.
4- PostUUT – виконується на кінці кожної тест-ітерації.
5- Process Cleanup – виконується на кінці виконання файлу тест-послідовності, коли його виконання було зупинено.
Описання callbacks я привів в порядку їх виконання. Це – основні з них, але на ділі їх набагато більше. Добавити їх можна наступним чином: ПКМ в полі Sequences -> Sequence File Callbacks… -> вибираєте необхідний колбек, і тиснете кнопку Add. Якщо в колбекі є вже код, можна сміло його видаляти – це не вплине на інші тест-послідовності, які використовують ту саму Process Model, і ці ж callbacks.
В прикладі, що я прикріплюю до посту, тест-кроки розміщені у відповідних колбеках. Таким чином, вони будуть виконані у відповідний час і послідовності.

Основні моменти, на які слід звернути увагу:
1. Кроки Open Settings і Get UUT Information мають активну опцію Show VI Front Panel. Таким чином, можна не добавляти додатковий код для відкриття панелі нашої віайки – TestStand це зробить сам.
2. Тест-параметри записуються у змінні FileGlobals; таким чином, вони доступні на всіх етапах виконання тест-послідовності.
3. Час виконання ми отримуємо як тип данних Numeric, але для тест-звіту нам потрібен тип данних String. Конвертація виконаня в Post-Expression кроку Get Test Time, PostUUT Callback. Для цього використовується функція Str(…), яка перетворює будь-який (майже) тип данних в String.
4. В PostUUT, в кроці Log Results, на вхід UUT_Status має значення #NoValidation(Parameters.Result.Status). #NoValidation – це директива, яка «приховує» вираз, записанний в її дужках від TestStand-у, оскільки в іншому випадку при автоматичному аналізі тест-послідовності перед виконанням, TestStand повідомить про помилку. Parameters.Result.Status – це змінна, яка доступна в PostUUT колбеку, і містить результат виконання тест-послідовності – “Passed”, “Failed”, “Terminated”, “Error”. І доступна вона лише при виконання тест-послідовності, в режимі редагування вона просто не існує.
5. Terminate Test – це крок для виклику TestStand API, використовуючи ActiveX метод.
В принципі, в такому вигляді можна запускати тест-послідовність на виконання. Execute -> Test UUTs. Приклад зроблений в TestStand 2014 SP1, LabVIEW 2014 SP1.

Нижче приведені скріншоти виконання тест-послідовності.
Settings.png
UUT Info.png
UUT Info.png (9.01 КБ) 8091 просмотр
Test.png
Stop Sequence.png
Stop Sequence.png (8.71 КБ) 8091 просмотр
LogFile.PNG
LogFile.PNG (8.63 КБ) 8091 просмотр
Зрозуміло, що інтерфейс віайок – так собі, але це не головне...
Надіюся, що цей приклад допоможе ознайомитися із базовими можливостями TestStand, та підходом до створення тест-послідовності взагалі.
Зрозуміло, що тут відсутні багато речей – обробник помилок, зчитування налаштуваня з конфігураційного файлу, логування результатів вимірювання, лімітів та одиниць вимірювання, і т.д. В разі, якщо хтось буде зацікавлений в данній темі, я з радістю відповім на подібні питання, і приведу приклади. TestStand – це дуже багатогранний інструмент, який дозволяє вирішити багато задач, які постають при написанні софту для проведення автоматичних тест-процедур; і, надіюся, що мені вдалося хоч трохи зацікавити ним тих, хто читав ці пости ))
Вложения
TS Example.zip
(64.1 КБ) 165 скачиваний
Мы делили апельсин - много наших полегло...
Аватара пользователя
Pavel Krivozubov

Activity Bronze
professor
professor
Сообщения: 4421
Зарегистрирован: 07 фев 2008, 16:39
Награды: 3
Версия LabVIEW: 7.0 - 2013
Откуда: г. Электросталь
Благодарил (а): 24 раза
Поблагодарили: 9 раз
Контактная информация:

Re: NI TestStand

Сообщение Pavel Krivozubov »

И Украинская языковая ветка перемещается на 4 место по посещаемости! :1stplace:
Спасибо Иван! :1stplace:
bee
junior
junior
Сообщения: 51
Зарегистрирован: 12 июн 2013, 09:04
Версия LabVIEW: 2014
Контактная информация:

Re: NI TestStand

Сообщение bee »

Дуже дякую за детальний огляд актуального тулкіту.
Розкажіть детально про обробку помилок і зчитування налаштувань з конфігураціного файлу в TestStand.
Чи могли б ви привести приклад тест-модулю з використанням будь-якого DAQ пристрою?
Аватара пользователя
Kosist

Activity Gold
expert
expert
Сообщения: 1236
Зарегистрирован: 21 фев 2011, 23:44
Награды: 2
Версия LabVIEW: 2013-2020
Благодарил (а): 23 раза
Поблагодарили: 30 раз
Контактная информация:

Re: NI TestStand

Сообщение Kosist »

О, нарешті хтось зацікавився темою, ура :thank: !!!

Постараюся відповісти на поставлені питання...

1. Обробник помилок.
Якщо Ви вже працювали з TestStand, то знаєте, що при завантаженні код-модулю із Error Cluster Indicator, TestStand автоматично присвоює йому значення контейнера Step.Result.Error. Таким чином, якщо в код-модулі виникне помилка, TestStand її автоматично "впіймає", і перейде до колбеку "SequenceFilePostStepRuntimeError". Ось там якраз і можна вставити свій код для обробки помилки. TestStand має уже готовий приклад <TestStandPublic>\Examples\Callbacks\PostStepRuntimeErrorCallback\ErrorHandlerExample.seq, я його прикладаю сюди теж.
Смисл такий - в колбекі SequenceFilePostStepRuntimeError спочатку "вбиваємо" помилку, а потім вибираємо, яку дію хочемо зробити. В елементарному випадку можна просто робити термінацію послідовності, і логувати помилку до файлу.
Текст помилки можна "витягнути" за допомогою виразу "Parameters.Step.Result.Error.Msg", а її код - за допомогою "Parameters.Step.Result.Error.Code". Ці вирази дійсні лише при виконанні тест-послідовності, тому краще їх записувати разом із директивою #NoValidation.

2. Зчитування налаштувань з конфігураціного файлу.
Найлегший спосіб - це зробити код модуль, який буде читати конфіг. файл, і присвоювати на виході значення тим чи іншим змінним у TestStand.
Є ще також такий тип кроку, як "Property Loader". Але скажу чесно, я з ним не грався - для моїх потреб підходить кастомний код модуль. Вхід - шлях до конфіг. файлу, на виході - значення змінної, і все...

3. Приклад можу привести доволі простий. Уявімо, що треба перемикати 2 DO лінії, та зчитувати значення з AI каналу.
Основні моменти такі.
1. ProcessSetup - спочатку, із конфіг файлу зчитуємо назви каналів, і записуємо їх у змінні. Далі - ініціалізуємо кожний канал/лінію окремо. Звичайно, якщо їх буде багато - ініціалізацію треба робити масиву каналів, наприклад.
2. TestStand має тип данних LabVIEWIOControl - саме в змінних такого типу ми будемо зберігати наші daq таски. Щоб створити таку змінну, треба ПКМ у полі змінних -> Insert Field -> Type -> LabVIEW -> LabVIEWIOControl.
3. У PreUUT перемикаємо наші цифрові лінії, все просто.
4. У MainSequence читаємо данні з AI каналу, і робимо тест.
5. PostUUT - перемикаємо цифрові лінії в дефолтне значення.
6. ProcessCleanup - робимо deinit нашого заліза.

Цей приклад не дуже оптимальний, але, надіюся, загальне уявлення з нього можна взяти...

Надіюся, що відповів на Ваші питання, і готовий до нових :wink:
Вложения
TS_Example_2.zip
(75.13 КБ) 161 скачивание
ErrorHandlerExample.zip
(11.79 КБ) 170 скачиваний
Мы делили апельсин - много наших полегло...
Ответить
  • Похожие темы
    Ответы
    Просмотры
    Последнее сообщение

Вернуться в «TestStand»