LabView _lab (МУ к лабораторным работам)
.pdfОчередь будет сохранять запрос второго состояния и выполнит его после отработки первого запроса.
2.2.Программа работы
1.Открыть файл Генерация чисел.vi.
2.Создать две глобальные переменные: одну для передачи счетчика циклов, вторую, логическую, для передачи команды Стоп.
3.Открыть файл Индикация чисел.vi.
4.Установить две глобальные переменные: одну для отображения значения счетчика циклов, вторую для записи команды Стоп.
5.При помощи клавиш Alt+PrtSc записать и сохранить в файле .doc скриншоты блок-схем двух ВП.
6.Открыть файл 3sin_no_queue.vi.
7.Решить двумя способами задачу синхронного вывода на одну диаграмму трех синусоидальных сигналов. Первый способ: используя технологию локальных переменных, второй: используя Queue Operations Functions.
8.При помощи клавиш Alt+PrtSc записать и сохранить в файле .doc скриншоты блок-схемы программы и лицевой панели для обоих вариантов решения задачи мультиплексирования данных.
2.3.Содержание отчета
1.Ответы на вопросы, содержащиеся в программе работы.
2.Скриншоты программ по п. п. 5, 8 программы работы.
Контрольные вопросы
1.Какой тип переменой используется для передачи данных между несколькими ВП?
2.В каких случаях создается ВП с лицевой панелью, но без блок- диаграммы?
3.В чем заключаются преимущества использования очередей в
программах типа «производитель-потребитель»?
4. Какие две функции выполняют одновременно очереди при реализации шаблона «производитель-потребитель»?
Пример правильного решения задачи по п. 7 программы работы для варианта с использованием функций Очередь приведен на рисунке 6.
Рисунок 6. Пример правильного решения задачи по п. 7 программы
работы для варианта с использованием функций Очередь
Лабораторная работа №3
ПЕРЕРАБОТКА КОДА ПРИЛОЖЕНИЯ
Цель работы – овладение навыками применения основ программирования по принципу потока данных. Получение информации о типичных ошибках программирования и способах их преодоления.
3.1.Основные сведения
Потоковое программирование
Потоковое программирование - принцип программирования, состоящий в том, что исполняемые узлы начнут выполняться только после получения всех необходимых входных данных. По завершении выполнения узлы автоматически генерируют выходные данные. Среда LabVIEW – это система программирования в соответствии с потоком данных. Порядок выполнения VI и функций на блок-диаграмме определяется продвижением данных через узлы.
Продвижение данных через узлы определяет порядок выполнения VI и функций на блок-диаграмме. Программы на Visual Basic, C++, JAVA и в
большинстве других текстовых языках программирования выполняются в соответствии с моделью управления потоком команд, согласно которой
последовательность программных элементов определяет порядок выполнения программы. В качестве примера потокового программирования рассмотрим блок-диаграмму, приведенную на рисунке 7, которая складывает два числа, и затем из суммы этих чисел вычитает число 50.00. В этом случае блок-диаграмма выполняется слева направо не из-за того, что объекты размещены в таком порядке, а вследствие того, что функция Subtract не может выполняться до тех пор, пока не выполнится функция Add, которая передаст данные функции Subtract. Следует помнить о том, что узел выполняется только тогда, когда данные доступны на всех его входных терминалах, и выдает данные на выходные терминалы только тогда, когда узел закончит выполнение.
Проанализируем, какой сегмент программного кода на рисунке 8 будет выполняться в первую очередь функция Add, Random Number или Divide. Вы не сможете это узнать, поскольку данные на входах функций Add и Divide доступны одновременно, а у функции Random Number нет входов. В ситуации, когда один сегмент программного кода должен выполняться раньше другого, причем функции взаимно независимы относительно
Рисунок 7. Пример программы, управляемой потоком данных
данных, следует пользоваться другими методами программирования, например, которые используют кластеры ошибок, чтобы принудительно задать порядок выполнения программы.
Рисунок 7. Пример с несколькими сегментами кода, управляемыми потоком
данных
Распространенные причины ошибок в VI
Ниже приведены распространенные причины возникновения ошибок в процессе редактирования VI:
∙На блок-диаграмме есть оборванный проводник из-за несоответствия типов данных или какой-либо конец проводника никуда не подключен.
∙Обязательный для подключения терминал никуда не подключен.
∙Неработоспособен subVI или его панель подключения редактировалась после того, как иконку subVI поместили на блок- диаграмму VI.
Оптимизация существующих ВП
Наиболее общая проблема, с которой вы можете столкнуться, получив виртуальный прибор от других разработчиков – трудночитаемый и плохо понятный код, в который сложно внести необходимые вам изменения. Эта проблема, иногда именуемая «угасанием» программного обеспечения, чаще всего связана с тем, что в процессе разработки или модификации ВП мало внимания уделялось его структуре и организации.
«Угасание» программы можно предотвратить, своевременно проведя его переработку. Переработка – это модификация созданного программного обеспечения, призванная сделать его более легким для понимания и внесения изменении, и тем самым более экономически оправданным в долгосрочной перспективе. Переработка изменяет, оптимизирует внутреннюю структуру ВП, не меняя его функциональность и поведение.
В этом разделе вы изучите основные методы переработки и оптимизации «вторичного» кода, а также проведете эксперименты по устранению типичных ошибок, связанных с этим процессом.
Переработка «вторичного» кода
Если вы вовлечены в крупномасштабный и/или долгосрочный проект по разработке программного продукта, делайте свою часть максимально наглядной и «читабельной», поскольку трудозатраты ваших коллег и
последователей на понимание и модификацию вашего кода могут оказаться больше, чем ваши – на его создание. Разработчики часто говорят «я потрачу меньше времени на полное переписывание этого фрагмента кода, чем на понимание данной его реализации». Действительно, в
большинстве проектов модификация и обновление программного продукта требует больше ресурсов, чем его первичное создание. Таким образом, компактный, легкий для понимания и изменения код представляет большую ценность, чем громоздкий и непонятный. Как следствие, оптимальный и
наглядный код имеет лучшую динамику развития и больший жизненный цикл.
Рассмотрим «вторичный» ВП, показанный на Рисунке 8, и переработанный, приведенный на Рисунке 9.
Переработанный код функционально идентичен исходному, но существенно более понятен и «читабелен». Исходный код, показанный на Рисунке 9, создан с нарушением многих правил разработки ВП, с которыми вы уже знакомы. В процессе переработки кода вы устраняете эти погрешности и
Рисунок 8. Пример «вторичного» ВП
Рисунок 9. Переработанный «вторичный» ВП
делаете виртуальный прибор наглядным и пригодным к модификации, что реально повышает его ценность.
Еще раз отметим, что переработка ВП не должна изменять его функциональность. Даже изменение предусмотренного разработчиком
способа взаимодействия ВП с пользователем или другими ВП может привести к возникновению ошибок в процессе выполнения. Переработка
кода затрагивает его внутреннюю структуру и организацию с целью упрощения восприятия и последующей модификации. Важно не путать переработку кода с оптимизацией, например, производительности или объема занимаемой памяти.
Типичные трудности и ошибки
При переработке виртуальных приборов возникает риск внесения в код новых ошибок. Минимизировать этот риск можно путем постепенного
изменения кода небольшими фрагментами и тщательным тестированием ВП после каждого изменения. Последовательность действий при переработке ВП показана на Рисунке 10.
Рисунок 10. Последовательность переработки ВП
При переработке и улучшении качества диаграммы кода старайтесь первоначально провести небольшие «косметические» правки перед тем как браться за серьезные исправления. Так, например, гораздо проще
обнаружить повторяющиеся участки кода, если диаграмма хорошо организована и терминалы функций содержат текстовые ярлыки.
Существует несколько принципиальных моментов, затрудняющих работу с виртуальными приборами, полученными от других разработчиков. Следующий список описывает типичные проблемы и приемы переработки, делающие ВП более понятными и простыми для модификации.
∙Блок-диаграмма слишком плохо организована. Улучшить
читабельность ВП можно путем оптимального перемещения объектов внутри диаграммы. Вы можете также создать виртуальные подприборы из наиболее «запутанных» участков диаграммы, снабдив эти ВПП комментариями, помогающими разобраться в их функциональном назначении.
∙Блок-диаграмма содержит много неясных имен терминалов и функций и плохо понятные иконки ВПП. Этим часто отличаются ВП, полученные «из третьих рук». Например, ярлык элемента управления Control1, показанного на Рисунке 11, не позволяет догадаться о его назначении. Control 2 – тот же самый элемент управления, но переименованный для лучшего пояснения его назначения, и, тем самым, для большей наглядности кода ВП.
1 Неподходящий ярлык |
2 Подходящий ярлык |
Рисунок 11. Варианты ярлыков элементов управления
Имена ВПП и изображения их иконок также важны для улучшения читабельности ВП. Например, имя ВПП «Сбор данных.vi», расположенного в левой части диаграммы на Рисунке 3-19, предоставляет недостаточную информацию о назначении этого ВПП, поэтому целесообразно дать подприбору более осмысленное имя. Для этого сохраните его копию под новым именем и замените все вхождения данного ВПП на новое. Наиболее простой метод реализации этой задачи – открыть все ВП верхнего уровня, которые используют данный ВПП, и затем сохранить ВПП под новым именем. LabVIEW автоматически заменит во всех открытых ВП ссылки на новое имя ВПП. Так, имя Измерения температуры окна.vi лучше отражает функциональное назначение данного виртуального подприбора. Иконка ВП также призвана пояснять его назначение. Иконка, создаваемая LabVIEW по
умолчанию, не может отобразить эту информацию – например, варианты 1 и 2 иконок на Рисунке 12. Улучшить восприятие ВП поможет подходящая по смыслу иконка, такая как приведена в варианте 3.
1 Неподходящее |
2 Подходящее имя ВПП |
3 Подходящее имя и иконка |
имя и иконка |
|
ВПП |
ВПП |
|
|
|
Рисунок 12. Варианты имен и иконок ВПП |
|
Переименованием элементов управления и созданием наглядных иконок ВП и ВПП вы можете добиться значительного улучшения восприятия и понятности кода, полученного от других разработчиков.
∙ Блок-диаграмма содержит ненужные логические конструкции.
Если рассмотреть диаграмму, показанную на Рисунке 13, можно обратить внимание на наличие в ней ненужных логических конструкций. Если какой- либо фрагмент диаграммы заведомо не будет выполнен, смело удаляйте его. Довольно трудно бывает понять код, который выполняется, но совершенно невозможно понять код, который не будет выполняться никогда. Более того, ненужные кодовые конструкции сильно загромождают диаграмму ВП.
Рисунок 13. Иллюстрация ненужных логических конструкций
∙ Блок-диаграмма содержит повторяющиеся логические конструкции.
Если диаграмма ВП содержит повторяющиеся фрагменты, вам в любом случае необходимо переработать такой ВП, наиболее просто – созданием ВПП из повторяющихся фрагментов. Так вы достигнете большей наглядности ВП, а также его пригодности к модификациям и тестированию.
∙Алгоритм не следует принципу программирования «по потоку данных»
Если диаграмма ВП, полученного вами от других разработчиков, содержит много Структур Последовательности (sequence structures) и локальных переменных (local variables), данный ВП очевидно создавался без соблюдения принципа программирования «по потоку данных».
Вам следует заменить большую часть последовательностей на шаблон разработки машина состояний. Локальные переменные целесообразно убрать, оставив вместо них обычные элементы управления или индикаторы, соединенные проводниками данных.
∙ Диаграмма содержит очень сложный и громоздкий алгоритм
Чересчур сложные алгоритмы делают ВП трудным в чтении и понимании. Более того, переработка таких алгоритмов сильно затрудняется возросшей вероятностью внести ошибки. При переработке сложных и громоздких
алгоритмов старайтесь производить коррекции малыми шагами и сразу же проводить тестирование обновленных ВП. В ряде случаев упрощение
сложных алгоритмов можно проводить при помощи встроенных функций LabVIEW. Например, ВП, показанный на Рисунке 14, проверяет имя и пароль, введенные пользователем, на соответствие сохраненным в базе данных.
Рисунок 14. ВП со сложным алгоритмом
Вы можете переработать этот ВП при помощи встроенной функции, осуществляющей поиск текстовых строк, так, как показано на Рисунке 15.
∙ Диаграмма слишком велика
Виртуальные приборы, имеющие диаграмму, не умещающуюся на один экран компьютера, уже сложны в чтении и понимании. Необходимость в
прокрутке экрана усложняет восприятие кода и увеличивает время на его
