Странное поведение LabView2017 + VISA + FTDI

VISA, TCP/IP, USB, CAN, GPIB и подобные протоколы
rbl
assistant
assistant
Сообщения: 122
Зарегистрирован: 09 дек 2014, 10:14
Версия LabVIEW: 7-2015
Откуда: Санкт-Петербург
Контактная информация:

Странное поведение LabView2017 + VISA + FTDI

Сообщение rbl »

Имеем связку - LV2017 (sp1, patch3),VISA, FTDI(rs232, дефолтные настройки).
Цикл обмена состоит из Записи, и двух последовательных Чтений.
Проект не компилирован. Асинхронный режим.
Проблема - крайне редко (~1 раз 7-8 часов) LV застревает в функции Записи (не вываливается по таймауту), остановить программу невозможно (либо у меня не хватило терпения дождаться этого момента).
При переключении в синхронный режим зависания прекратились, из Чтения вываливается по Unknown Error, после чего можно возобновить обмен возможно пересозданием сессии (не выключая программу).

Кто нибудь с подобным сталкивался? Ума не приложу, что убивает визу...
Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3926
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2022
Благодарил (а): 11 раз
Поблагодарили: 126 раз
Контактная информация:

Re: Странное поведение LabView2017 + VISA + FTDI

Сообщение dadreamer »

rbl писал(а):Кто нибудь с подобным сталкивался? Ума не приложу, что убивает визу...
Возможно, FTDI драйвер просто глючит временами. На D2XX Direct Drivers (не используя VISA) проверяли описанное событие?
rbl
assistant
assistant
Сообщения: 122
Зарегистрирован: 09 дек 2014, 10:14
Версия LabVIEW: 7-2015
Откуда: Санкт-Петербург
Контактная информация:

Re: Странное поведение LabView2017 + VISA + FTDI

Сообщение rbl »

Через директ не пробовал. Скачал с их сайта пример под 7й LW, он пока просто отказывается работать. Может есть чтото более актуальное?
Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3926
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2022
Благодарил (а): 11 раз
Поблагодарили: 126 раз
Контактная информация:

Re: Странное поведение LabView2017 + VISA + FTDI

Сообщение dadreamer »

rbl писал(а):Скачал с их сайта пример под 7й LW, он пока просто отказывается работать.
А в каком :labview: запускаете? В архивах есть как ftd2xx.dll, так и ftd2xx64.dll. Все обертки и примеры сделаны под LV 32 бита, в 64-битном LV они сходу вряд ли заработают - нужно менять представления хэндлов (FT_HANDLE) с U32 на (Un)signed Pointer-sized Integer. Может помочь заголовочный файл ftd2xx.h и D2XX Programmer's Guide. Примеры, конечно, очень примитивно сделаны, такое ощущение, что их автор открыл :labview: пару дней назад и не вполне врубается, какие вообще инструменты использовать. Так что надо там каждый блок перепроверять, следуя описаниям, и переписать пример по-человечески, без Sequence Structure, с обработкой ошибок, иконками и прочим.
rbl
assistant
assistant
Сообщения: 122
Зарегистрирован: 09 дек 2014, 10:14
Версия LabVIEW: 7-2015
Откуда: Санкт-Петербург
Контактная информация:

Re: Странное поведение LabView2017 + VISA + FTDI

Сообщение rbl »

32 бита. Если честно, то изза цейтнота, потратил на тот пример буквально минут 5. Запустил, с ходу не заработало, посмотрел на инициализацию, увидел инициализацию по номеру девайса, ничего не понял, закрыл пример и пошел переписывать свою используя аналог визы (на портале есть ему посвященный топик). Вроде заработало, но лабвью с ним лабвью иногда банально крашится.
Вернулся обратно к визе и пишу костыли на оживление после ошибки...
Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3926
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2022
Благодарил (а): 11 раз
Поблагодарили: 126 раз
Контактная информация:

Re: Странное поведение LabView2017 + VISA + FTDI

Сообщение dadreamer »

rbl писал(а):увидел инициализацию по номеру девайса, ничего не понял
FTDI API может открывать устройство тремя разными способами: по серийному номеру (например, "FT000001"), по описанию (например, "USB Serial Converter") и по идентификатору физического размещения на шине USB (например, 0x23). В примере на :labview: используется открытие по описанию: вызывается FT_ListDevices с параметрами FT_LIST_BY_INDEX и FT_OPEN_BY_DESCRIPTION для получения описания конкретного устройства (если оно подключено; индекс устройства = 0 означает, что нужно найти первое устройство) и затем FT_OpenEx с параметром FT_OPEN_BY_DESCRIPTION для открытия (на вход подаём описание, на выходе получаем хэндл открытого устройства). Так что COM-порт можно вообще не указывать. Если устройство одно подключено, то без разницы даже, какой способ подключения использовать. Если устройств несколько, то надёжнее будет сделать открытие по серийному номеру. Ну, понятное дело, для этого надо немного подправить узлы CLFN в ВИ-шках. В описании API, что я выше приводил, есть примеры на С к каждой функции, в них довольно просто разобраться.
rbl
assistant
assistant
Сообщения: 122
Зарегистрирован: 09 дек 2014, 10:14
Версия LabVIEW: 7-2015
Откуда: Санкт-Петербург
Контактная информация:

Re: Странное поведение LabView2017 + VISA + FTDI

Сообщение rbl »

dadreamer писал(а):
rbl писал(а):увидел инициализацию по номеру девайса, ничего не понял
FTDI API может открывать устройство тремя разными способами: по серийному номеру (например, "FT000001"), по описанию (например, "USB Serial Converter") и по идентификатору физического размещения на шине USB (например, 0x23). В примере на :labview: используется открытие по описанию: вызывается FT_ListDevices с параметрами FT_LIST_BY_INDEX и FT_OPEN_BY_DESCRIPTION для получения описания конкретного устройства (если оно подключено; индекс устройства = 0 означает, что нужно найти первое устройство) и затем FT_OpenEx с параметром FT_OPEN_BY_DESCRIPTION для открытия (на вход подаём описание, на выходе получаем хэндл открытого устройства). Так что COM-порт можно вообще не указывать. Если устройство одно подключено, то без разницы даже, какой способ подключения использовать. Если устройств несколько, то надёжнее будет сделать открытие по серийному номеру. Ну, понятное дело, для этого надо немного подправить узлы CLFN в ВИ-шках. В описании API, что я выше приводил, есть примеры на С к каждой функции, в них довольно просто разобраться.
Спасибо за пояснения. Учту.

http://sine.ni.com/nips/cds/view/p/lang/ru/nid/212767#

А вот этот аддон Вам случайно не знаком? Имеет смысл пробовать его опробовать?
Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3926
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2022
Благодарил (а): 11 раз
Поблагодарили: 126 раз
Контактная информация:

Re: Странное поведение LabView2017 + VISA + FTDI

Сообщение dadreamer »

rbl писал(а):А вот этот аддон Вам случайно не знаком? Имеет смысл пробовать его опробовать?
Не попадалось раньше. Но это для устройств с MPSSE (Multi-Protocol Synchronous Serial Engine) для конфигурирования по SPI и I2C, к примеру FT2232D, FT2232H или FT4232H. Для обычных USB-UART адаптеров вряд ли подойдёт. Ну, если только как пример хорошо выполненных :vi: -обёрток над драйверами D2XX / FT4222.
rbl
assistant
assistant
Сообщения: 122
Зарегистрирован: 09 дек 2014, 10:14
Версия LabVIEW: 7-2015
Откуда: Санкт-Петербург
Контактная информация:

Re: Странное поведение LabView2017 + VISA + FTDI

Сообщение rbl »

В продолжение данной темы.

Повисание чтения №го кол-ва было исправлено костылем - переводом в синхронный режим, что исключило повисания, но вместо этого оно выплевывает обрезанную посылку.
В одном изделии это я могу игнорировать, но в другом я не могу пропустить ни такта. Погуглив, нарыл следующее (оказывается довольно распространенная проблема)- если читать кол-во байт, которых в данный момент на порту нет - функция чтения может наглухо! повиснуть. Решение - предварительно смотрим Bytes at port и только после этого проводим чтение. Решение работает - гонял 8 дней - полет нормальный.

Только одно но - имеем Timed Loop c дефолтными настройками внутри которого последовательно выполняется - Запись команды на порт, Смотрим байты на порту, Читаем подтверждение команды, Смотрим байты на порту, Читаем размер посылки, Смотрим байты на порту, Читаем № байт соответсвующих размеру посылки.
Чаще всего все прекрасно - время выполнения цикла - 10-12 ms, но иногда обмен однократно увеличивается до ~96 мс., после чего по гиперболе опускается до нормальных 10-12 ms.
Думал шуточки timed loop, но замена на обычный цикл привела только усугубила ситуацию, время выполнения стало абсолютно рандомным.

Если везде убрать предварительный просмотр байт на порту - такого эффекта нет - обмен стабильный 10-12 ms, но риск повиснуть недопустим. :\

Если кто с таким сталкивался - прошу прокомментировать ;)
Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3926
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2022
Благодарил (а): 11 раз
Поблагодарили: 126 раз
Контактная информация:

Re: Странное поведение LabView2017 + VISA + FTDI

Сообщение dadreamer »

rbl писал(а):если читать кол-во байт, которых в данный момент на порту нет - функция чтения может наглухо! повиснуть
Имеете ввиду, VISA Read виснет полностью без вариантов или VISA Read встаёт в ожидание заданного количества байтов в порту, а ожидание прекращается по истечении времени, заданного для VISA Configure Serial Port? В Timed Loop Визу я ни разу не помещал, да и на не-ОСРВ в этом мало смысла (винда же стоит, да?), операционка всё равно когда-нибудь да сдвинет заданное время на итерацию в +/-. Всегда получить время цикла в 10-12 мс не получится, даже если цикл полностью пустой будет крутиться. В 99% получите заданное время, а в 1% нет из-за сотни возможных причин (скажем, юзер решит запустить тяжеловесное приложение или винда решит обновиться). Замена Визы на либы FTDI или WinAPI может чуть улучшить ситуацию, но тоже не до конца, т.к. в итоге всё опять сведётся к использованию средств ОС.
В Timed-структуру я бы не советовал помещать :vi: , который сам по себе организует задержку во внутренних циклах. Как выкрутиться и получить минимальную задержку при чтении порта... Сходу сказать сложно, нужно рассмотреть несколько подходов и сравнить между собой.
1. VISA Serial Events; можно регулировать таймаут ожидания на эвенте, но неизвестно, как это будет работать, если задать таймаут очень маленьким (обычный VISA Read ведёт себя довольно необычно в таком случае и может легко пропускать байты в посылке);
2. Либы FTDI; если не пробовали, попробуйте; возможно, найдётся функция для "тру" асинхронного чтения;
3. Serial Port API как часть инструментария Windows API или скорее как демонстрация; не знаю, реализована ли там асинхронность операций, но если нет, можно взять за основу и допилить (ну, или написать с нуля).
А так, универсальный совет, который дают в таких случаях - переходите на real-time, если время выполнения критично.
rbl
assistant
assistant
Сообщения: 122
Зарегистрирован: 09 дек 2014, 10:14
Версия LabVIEW: 7-2015
Откуда: Санкт-Петербург
Контактная информация:

Re: Странное поведение LabView2017 + VISA + FTDI

Сообщение rbl »

dadreamer писал(а):
rbl писал(а):если читать кол-во байт, которых в данный момент на порту нет - функция чтения может наглухо! повиснуть
Имеете ввиду, VISA Read виснет полностью без вариантов или VISA Read встаёт в ожидание заданного количества байтов в порту, а ожидание прекращается по истечении времени, заданного для VISA Configure Serial Port?
Виснет намертво. https://forums.ni.com/t5/Instrument-Con ... 934#M63146
dadreamer писал(а): В Timed Loop Визу я ни разу не помещал, да и на не-ОСРВ в этом мало смысла (винда же стоит, да?), операционка всё равно когда-нибудь да сдвинет заданное время на итерацию в +/-. Всегда получить время цикла в 10-12 мс не получится, даже если цикл полностью пустой будет крутиться. В 99% получите заданное время, а в 1% нет из-за сотни возможных причин (скажем, юзер решит запустить тяжеловесное приложение или винда решит обновиться).
Да, стоит винда. +/- секунды не критичны абсолютно. В принципе и 100 мс не страшно, т.к. принятый буфер я парсю и нет особой разницы сколько тактов обмена в нем находится 1 или 100. Мой потолок это ~400 мс, за это время входные данные на согласующем устройстве перезапишутся. Вроде, как сейчас имею 3й запас и можно расслабиться, но хочется понять причину.
Насчет деятельности юзера можно не волноваться, поскольку если он решит запустить, что-то кроме моего приложения, то будет расстрелян. :evil: Обновления винды отключены, вообще все что может запуститься по рассписанию или евенту - отключено. Виза в таймед луп ведет себя гораздо более предсказуемо, в отличии от обычных циклов.
dadreamer писал(а): Замена Визы на либы FTDI или WinAPI может чуть улучшить ситуацию, но тоже не до конца, т.к. в итоге всё опять сведётся к использованию средств ОС.
В Timed-структуру я бы не советовал помещать :vi: , который сам по себе организует задержку во внутренних циклах. Как выкрутиться и получить минимальную задержку при чтении порта... Сходу сказать сложно, нужно рассмотреть несколько подходов и сравнить между собой.
1. VISA Serial Events; можно регулировать таймаут ожидания на эвенте, но неизвестно, как это будет работать, если задать таймаут очень маленьким (обычный VISA Read ведёт себя довольно необычно в таком случае и может легко пропускать байты в посылке);
2. Либы FTDI; если не пробовали, попробуйте; возможно, найдётся функция для "тру" асинхронного чтения;
3. Serial Port API как часть инструментария Windows API или скорее как демонстрация; не знаю, реализована ли там асинхронность операций, но если нет, можно взять за основу и допилить (ну, или написать с нуля).
Спасибо, гляну.
dadreamer писал(а):А так, универсальный совет, который дают в таких случаях - переходите на real-time, если время выполнения критично.
Для данного проекта это к сожалению невозможно. Времени на глобальные изменения нет.
Blackman

Activity
leader
leader
Сообщения: 932
Зарегистрирован: 17 янв 2016, 15:02
Награды: 1
Версия LabVIEW: 6.1,8.5,20

Re: Странное поведение LabView2017 + VISA + FTDI

Сообщение Blackman »

В теме VISA Read hangs. Get Resetting VI dialog on abort посмотрите сообщения ErikMansson2 на странице 8. Там же есть :vi: тестирования адаптеров для воспроизведения проблемы. Все указывает на то, что это проблема VISA.
https://forums.ni.com/t5/Instrument-Con ... -p/3695827

В указанном Вами драйвере есть библиотека D2XX. Естественно она закрыта и с пробным периодом времени.
http://sine.ni.com/nips/cds/view/p/lang/ru/nid/212767#
Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3926
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2022
Благодарил (а): 11 раз
Поблагодарили: 126 раз
Контактная информация:

Re: Странное поведение LabView2017 + VISA + FTDI

Сообщение dadreamer »

rbl писал(а):Виснет намертво. https://forums.ni.com/t5/Instrument-Con ... 934#M63146
Это, конечно, баг, такого быть не должно. VISA должна ждать то время, что указано в таймауте, и возвращаться из ожидания в любом случае. Мне лично такого видеть не доводилось, хотя с разными интерфейсами часто работаю. Но охотно верю в подобное. Жаль, что галка асинхронности для Визы не обеспечивает то поведение, что изначально заложено ОС, то есть передача контроля вызывающей стороне сразу после вызова функции: http://labviewportal.org/viewtopic.php?p=65914#p65914 Это бы могло дать большое преимущество в подобных ситуациях.
rbl писал(а):Виза в таймед луп ведет себя гораздо более предсказуемо, в отличии от обычных циклов.
Ещё вариант для пробы пера - ждущий таймер из функционала Windows: http://labviewportal.org/viewtopic.php?p=70539#p70539 Обеспечивает несколько более точную задержку нежели стандартный Wait. Как альтернатива Timed Loop.
rbl писал(а):Для данного проекта это к сожалению невозможно. Времени на глобальные изменения нет.
На будущее, можете глянуть на вот такого "зверя" - RTX – Расширение реального времени для Windows. У меня всё руки не доходят написать программку и связать с :labview: , но в тестовых бенчмарках получается латентность меньше 10 мкс, что не может не радовать. Времякритичные участки вполне можно на такой надстройке запускать.
rbl
assistant
assistant
Сообщения: 122
Зарегистрирован: 09 дек 2014, 10:14
Версия LabVIEW: 7-2015
Откуда: Санкт-Петербург
Контактная информация:

Re: Странное поведение LabView2017 + VISA + FTDI

Сообщение rbl »

dadreamer писал(а):
rbl писал(а):Виснет намертво. https://forums.ni.com/t5/Instrument-Con ... 934#M63146
Это, конечно, баг, такого быть не должно. VISA должна ждать то время, что указано в таймауте, и возвращаться из ожидания в любом случае. Мне лично такого видеть не доводилось, хотя с разными интерфейсами часто работаю. Но охотно верю в подобное. Жаль, что галка асинхронности для Визы не обеспечивает то поведение, что изначально заложено ОС, то есть передача контроля вызывающей стороне сразу после вызова функции: http://labviewportal.org/viewtopic.php?p=65914#p65914 Это бы могло дать большое преимущество в подобных ситуациях.
rbl писал(а):Виза в таймед луп ведет себя гораздо более предсказуемо, в отличии от обычных циклов.
Ещё вариант для пробы пера - ждущий таймер из функционала Windows: http://labviewportal.org/viewtopic.php?p=70539#p70539 Обеспечивает несколько более точную задержку нежели стандартный Wait. Как альтернатива Timed Loop.
rbl писал(а):Для данного проекта это к сожалению невозможно. Времени на глобальные изменения нет.
На будущее, можете глянуть на вот такого "зверя" - RTX – Расширение реального времени для Windows. У меня всё руки не доходят написать программку и связать с :labview: , но в тестовых бенчмарках получается латентность меньше 10 мкс, что не может не радовать. Времякритичные участки вполне можно на такой надстройке запускать.
В понедельник потестим, спасибо.
rbl
assistant
assistant
Сообщения: 122
Зарегистрирован: 09 дек 2014, 10:14
Версия LabVIEW: 7-2015
Откуда: Санкт-Петербург
Контактная информация:

Re: Странное поведение LabView2017 + VISA + FTDI

Сообщение rbl »

Потестил сегодня обмен через VISA events. Реализация при всей своей кажущейся простоте совершенно укуренная, взять хотя бы то, что сработавшие евенты нужно принудительно закрывать через VISA close.
Как посмотреть содержимое очереди сработавших и отработанных триггеров непонятно. Имена сработавших триггеров по большей части пустые, но некоторые содержат № порта и № евента.
Но самое обидное в том, что в принципе данная конструкция работает и работает идеально - тайминги прекрасные (обмен стабильно 6-9мс), но в какой-то момент без каких либо предпосылок сия конструкция падает по тайм-ауту. При этом неважно какого он размера. При этом почти всегда это происходит через 60000 тактов и два раза через 120000... какая-то черная магия.
Ответить
  • Похожие темы
    Ответы
    Просмотры
    Последнее сообщение

Вернуться в «Коммуникация с приборами»