AF + typedef
-
- professor
- Сообщения: 3391
- Зарегистрирован: 31 июл 2011, 23:05
- Награды: 2
- Версия LabVIEW: 12-18
- Благодарил (а): 49 раз
- Поблагодарили: 172 раза
- Контактная информация:
AF + typedef
Не понимаю, что за глюк.
Делаю проект с несколькими AF.
И само собой есть typedef.
Так вот регулярно случается беда. Открываю td, добавляю элементы (ладно бы Убавлял или переименовывал), закрываю, сохраняю. Программа не работает,
Ищу проблемы, обнаруживаю, что некоторые td скатились до нулевого значения.
Что за беда? никогда такого не было, только на AF заметил.
td раскиданы по библиотекам, может, в этом проблема?
Делаю проект с несколькими AF.
И само собой есть typedef.
Так вот регулярно случается беда. Открываю td, добавляю элементы (ладно бы Убавлял или переименовывал), закрываю, сохраняю. Программа не работает,
Ищу проблемы, обнаруживаю, что некоторые td скатились до нулевого значения.
Что за беда? никогда такого не было, только на AF заметил.
td раскиданы по библиотекам, может, в этом проблема?
-
Kosist
- expert
- Сообщения: 1236
- Зарегистрирован: 21 фев 2011, 23:44
- Награды: 2
- Версия LabVIEW: 2013-2020
- Благодарил (а): 23 раза
- Поблагодарили: 30 раз
- Контактная информация:
Re: AF + typedef
AF тут ни при чем - это просто набор либок для создания акторов.
Иногда LabVIEW просто делает reset значений кластера при его модификации; на NI форуме описаны подобные случаи... Поэтому NI рекомендует устанавливать значения по умолчанию в явном виде, при помощи Bundle (Bundle by Name). В таком случае ошибки точно не будет. Да и код читается легче - т.к. сразу видно, что заданы определенные значения, не нужно искать изменения в самом кластере.
Иногда LabVIEW просто делает reset значений кластера при его модификации; на NI форуме описаны подобные случаи... Поэтому NI рекомендует устанавливать значения по умолчанию в явном виде, при помощи Bundle (Bundle by Name). В таком случае ошибки точно не будет. Да и код читается легче - т.к. сразу видно, что заданы определенные значения, не нужно искать изменения в самом кластере.
Мы делили апельсин - много наших полегло...
-
- professor
- Сообщения: 3391
- Зарегистрирован: 31 июл 2011, 23:05
- Награды: 2
- Версия LabVIEW: 12-18
- Благодарил (а): 49 раз
- Поблагодарили: 172 раза
- Контактная информация:
Re: AF + typedef
Это не кластер, это enum. Тип запроса. И в коде лежит константа с выбранным типом.
А при обновлении некоторые команды "сделай это" сваливаются на "не делай ничего". И приходится бегать по коду, искать, где произошло сваливание
А при обновлении некоторые команды "сделай это" сваливаются на "не делай ничего". И приходится бегать по коду, искать, где произошло сваливание
-
Kosist
- expert
- Сообщения: 1236
- Зарегистрирован: 21 фев 2011, 23:44
- Награды: 2
- Версия LabVIEW: 2013-2020
- Благодарил (а): 23 раза
- Поблагодарили: 30 раз
- Контактная информация:
Re: AF + typedef
Походу, это глюк тайпдефа - неважно, энум или кластер... Но ясной инфы на форуме не нашел...Artem.spb писал(а):Это не кластер, это enum. Тип запроса. И в коде лежит константа с выбранным типом.
А при обновлении некоторые команды "сделай это" сваливаются на "не делай ничего". И приходится бегать по коду, искать, где произошло сваливание
Я уже давно для имен комманд использую строки, а не энумы... Но вот недавно работал на проекте, тоже использовал AF, была куча либок, классов, и т.д. - и также использовал энумы для некоторых объектов, проблем с их обновлением не было...
Мы делили апельсин - много наших полегло...
-
- professor
- Сообщения: 3391
- Зарегистрирован: 31 июл 2011, 23:05
- Награды: 2
- Версия LabVIEW: 12-18
- Благодарил (а): 49 раз
- Поблагодарили: 172 раза
- Контактная информация:
Re: AF + typedef
я вот считаю это дикарством.Kosist писал(а):Я уже давно для имен комманд использую строки, а не энумы...
Это примерно то же самое, почему Ni отказывается в классах методы оформлять через invoke node: потому что это будет текстовое программирование, а не графическое.
енум хорош тем что все пользователи сообщат мне, что не хватает кейса или чего-то подобного. И задать нужную команду гораздо проще, нет опасности ошибиться в одной букве. Каждому своё, но я не понимаю, ради чего отказываться от прелестей графического программирования.
Ну и меня опять закидают шапками, но строка занимает кучу байт, а енум всего пару.
-
Kosist
- expert
- Сообщения: 1236
- Зарегистрирован: 21 фев 2011, 23:44
- Награды: 2
- Версия LabVIEW: 2013-2020
- Благодарил (а): 23 раза
- Поблагодарили: 30 раз
- Контактная информация:
Re: AF + typedef
О, холивар назревает ))Artem.spb писал(а): я вот считаю это дикарством.
На вкус и цвет - фломастеры разные.
Во всем есть свои выгоды, и невыгоды. И выгоды енума на первый взгляд бесспорны.
Но:
- при большом количестве модулей использующих стейт машины на каждую из них нужен свой тайпдеф енум. При том, что много комманд будут повторяться;
- при переносе модуля на новый проект нужно править енум (если есть какие-то комманды, которые не требуются);
- невозможно создать универсальное API для обработки комманд - т.к. они будут "завязаны" на конкретный енум;
- ну, и иногда при правке енума обнуляются комманды .
Строки:
- единственный минус, что нужно знать список комманд, и не повторяться. Для "отлова" опечаток на стадии разработки достаточно дефолтного стейта в стейт машине, а список комманд видно при создании API для комманд. Также при помощи API виаек легко задается интерфейс для самой комманды (какие данные нужно отсылать с коммандой), и отслежываются конкретные места вызова комманды.
Правда, с енумом тоже можно делать API, но даже его шаблон для модулей не будет универсальным.
JKI использует string-based стейт машину, Delacor кажись тоже (хотя может и ошибаюсь). Также многие NI примеры, и референс-дизайны тоже содержат код со стейт машинами на основе строки.
В конце-концов, это дело вкуса - и оба методы имеют право на жизнь. Так как использование енума не дает
т.к. это не есть чисто "фишка" ; энумераторы есть и в других языках. Это удобно, да - но опять же, дело привычки и вкуса.Artem.spb писал(а):прелестей графического программирования
Мы делили апельсин - много наших полегло...
-
- doctor
- Сообщения: 2210
- Зарегистрирован: 28 июн 2012, 09:32
- Награды: 3
- Версия LabVIEW: 2009..2020
- Откуда: город семи холмов
- Благодарил (а): 27 раз
- Поблагодарили: 26 раз
Re: AF + typedef
Поддерживаю Artem.spb, От строк вообще надо уходить. В LV безобразно устроена работа памяти при работе со строками. Будете смеяться, но это основной источник неконтролируемой утечки памяти.
С точки зрения качества программирования Enum использовать предпочтительнее. А если надо, то всегда можно выдернуть из контрола текстовый список значений.
С точки зрения качества программирования Enum использовать предпочтительнее. А если надо, то всегда можно выдернуть из контрола текстовый список значений.
-
- professor
- Сообщения: 3391
- Зарегистрирован: 31 июл 2011, 23:05
- Награды: 2
- Версия LabVIEW: 12-18
- Благодарил (а): 49 раз
- Поблагодарили: 172 раза
- Контактная информация:
Re: AF + typedef
я не говорил, что enum - признак графичности. Признак графичности - нажал стрелку, получил весь список. И не надо вспоминать или в доках искать.Так как использование енума не даетт.к. это не есть чисто "фишка" ; энумераторы есть и в других языках.прелестей графического программирования
и да, Borjomy_1 прав
Ещё в древних трактатах 90х читал, что по возможности надо строки перегонять в массивы u8, и только потом делать с ними что хочется, особенно если это вставки/замены и пр.В LV безобразно устроена работа памяти при работе со строками. Будете смеяться, но это основонй источник неконтролируемой утечки памяти.
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 126 раз
- Контактная информация:
Re: AF + typedef
Я отчасти с этим согласен, однако SM со строковым селектором реально работает медленнее, чем с числовым. Это подтверждено уже давно и до сих пор справедливо вплоть до LV 2019. Есть вот такой бенчмарк: Performance of state machine with enum vs string? У меня получаются следующие результаты: enum (subroutine) - 0,930054; string (subroutine) - 1,17707; enum - 1,28307; string - 1,50509 (число итераций = 10 млн, дебаг отключен). Причина отставания строк от чисел (в данном случае) не в работе с памятью, а в побайтовом сравнении текущего значения с каждой командой/состоянием из списка SM. Очевидно, чем длиннее строки, тем больше времени потребуется на сравнение, особенно если оно не чувствительно к регистру. Работа с памятью на самом деле в LV не очень, но в этом виноваты в первую очередь внутренние функции LV, а не само представление типа данных (в самом деле, строка и массив U8 имеют одну и ту же структуру, просто с массивом можно работать in-place). В NXG эта ситуация должна заметно измениться, т.к. внутренние менеджеры переписаны с нуля. Тем не менее время от времени я тоже использую строку в качестве селектора SM, когда создаю простенькие программы с логикой, не критичной во времени. Это проще/быстрее, нежели задавать тайпдеф, а часто лень перевешивает затраты на оптимизацию; скажем, автоиндексация в циклах не всегда полезна, и лучше задавать число итераций явно, заранее выделять буфер и т.д. (об этом ещё Андрей писал в своих статьях), но подавляющее большинство использует автоиндексацию. Таких примеров много. В остальных случаях команду для SM лучше задавать числом. Ещё бы редактор элементов списка был поудобнее, но похоже не в этой "линейке" LV.Kosist писал(а):В конце-концов, это дело вкуса - и оба методы имеют право на жизнь.