Альтернатива VISA для работы с последовательным портом

VISA, TCP/IP, USB, CAN, GPIB и подобные протоколы
Аватара пользователя
dadreamer

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

Re: Альтернатива VISA для работы с последовательным портом

Сообщение dadreamer »

Юрий, я здесь не при делах :dntknw: Подозреваю, что раз тулкит работает целиком и полностью на WinAPI, то все возможные ошибки генерируются Windows, которая переводит текст ошибки на язык текущей локализации. Список возможных ошибок системы очень велик и даже их просмотреть займёт приличное время: https://docs.microsoft.com/en-us/window ... rror-codes Внизу страницы есть разделы, где номера ошибок сопоставлены их текстовым описаниям. Однако автор тулкита специально выделил некоторые ошибки, критичные для связи по последовательному интерфейсу. Их можно найти в файле \errors\English\lvserial-errors.txt. Надеюсь, это как-то поможет.
Юрий
leader
leader
Сообщения: 526
Зарегистрирован: 28 фев 2010, 18:04
Версия LabVIEW: LV2018
Благодарил (а): 10 раз
Поблагодарили: 18 раз
Контактная информация:

Re: Альтернатива VISA для работы с последовательным портом

Сообщение Юрий »

[quote=="dadreamer"]Юрий,Список возможных ошибок системы очень велик и даже их просмотреть займёт приличное время: https://docs.microsoft.com/en-us/window ... rror-codes[/quote]
Действительно, здесь нашёл свои ошибки на русском языке. А они возникали при открытии портов. Интересный момент. На разные порты возникали разные ошибки 32 и 170. 170 - это порт есть, но доступа к нему нет. А 32, когда возможно потенциальное открытие порта при условии, что он будет освобождён другой программой. Это можно использовать для дополнительной подсказки о возможности или принципиальной не возможности открытия порта.
Аватара пользователя
dadreamer

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

Re: Альтернатива VISA для работы с последовательным портом

Сообщение dadreamer »

Юрий,
>>170 - это порт есть, но доступа к нему нет. А 32, когда возможно потенциальное открытие порта при условии, что он будет освобождён другой программой.

Вот эти ошибки?

ERROR_SHARING_VIOLATION
32 (0x20)
The process cannot access the file because it is being used by another process.

ERROR_BUSY
170 (0xAA)
The requested resource is in use.

С первым всё понятно, а второе, это судя по всему, когда порт заняла та же самая программа. В одном месте открыли и вдруг начали открывать ещё в каком-то. При правильной реализации порт может стать доступен в обоих случаях. Не смогу сейчас сказать, как у автора это сделано, проще наверно проверить практически. Скорее всего, как и в VISA, отдаётся на откуп юзеру - если ошибка "порт занят", можно открывать его в цикле до бесконечности (ну, или пока не станет доступен).
Юрий
leader
leader
Сообщения: 526
Зарегистрирован: 28 фев 2010, 18:04
Версия LabVIEW: LV2018
Благодарил (а): 10 раз
Поблагодарили: 18 раз
Контактная информация:

Re: Альтернатива VISA для работы с последовательным портом

Сообщение Юрий »

Да, именно эти ошибки, но на русском. Работаю с модемом, который и организует этот порт. Если программа модема запущена, то, при открытие этого порта своей программой, возникает ошибка 170.
Аватара пользователя
toshas
assistant
assistant
Сообщения: 105
Зарегистрирован: 05 апр 2009, 22:45
Версия LabVIEW: 9.0
Благодарил (а): 13 раз
Поблагодарили: 7 раз
Контактная информация:

Re: Альтернатива VISA для работы с последовательным портом

Сообщение toshas »

Какой-то странный косяк с serpdrv в LV19/LV20. Что это может быть ?

Fatal Internal Error 0x8a6d4139 datasupp.cpp line 1805
Вложения
fatal_err.PNG
Аватара пользователя
dadreamer

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

Re: Альтернатива VISA для работы с последовательным портом

Сообщение dadreamer »

toshas
Я не проверял работу serpdrv на современных версиях :labview: . Вероятно, что-то где-то не так с конвертацией данных. Если есть желание поразбираться, можно выполнить отладку по шагам и посмотреть, на каком блоке выскакивает эта ошибка. Также можно включить детальный лог :labview: с помощью этих ключей:

Код: Выделить всё

createLogFile=True
DPrintfLogging=True
DPrintfToFile=True
promoteDWarnInternals=True
После перезапуска в папке с labview.exe будет создан текстовый файл DPrintf.txt, куда будет сливаться вся отладочная информация.

А так, если не хотите работать с Визой, есть тулкит от Мартина, который работает и в 32-х, и в 64 битах.

upd:
Подтверждаю, на LV 2020 получил такую же ошибку. Легко воспроизводится при вызове блока Device Control/Status.
serpdrv_datasupp_err.png
Потом ещё в лог заглянул - surprise, mf! :D
2021-05-18_21-17-37.jpg
DAbort 0x8A6D4139: LockFlat: Support for Device Control/Status primitive was dropped in LV 7.0. Why are you still using this?
e:\builds\penguin\labview\branches\2020\dev\source\data\datasupp.cpp(1805) : DAbort 0x8A6D4139: LockFlat: Support for Device Control/Status primitive was dropped in LV 7.0. Why are you still using this?
В отладчике видно, что в функции LockFlat и UnlockUnflat впихнули заглушки вместо кода.
2021-05-18_21-45-43.jpg
Остальной функционал, вероятно, в порядке, надо проверять. Можно вместо Device Control/Status :vi: вызвать функцию DevCtrlStat через CLFN.
Аватара пользователя
toshas
assistant
assistant
Сообщения: 105
Зарегистрирован: 05 апр 2009, 22:45
Версия LabVIEW: 9.0
Благодарил (а): 13 раз
Поблагодарили: 7 раз
Контактная информация:

Re: Альтернатива VISA для работы с последовательным портом

Сообщение toshas »

dadreamer писал(а): 18 май 2021, 18:41 DAbort 0x8A6D4139: LockFlat: Support for Device Control/Status primitive was dropped in LV 7.0. Why are you still using this?
вот это находка!
dadreamer писал(а): 18 май 2021, 18:41 Можно вместо Device Control/Status :vi: вызвать функцию DevCtrlStat через CLFN.
вызвать из serpdrv ? LV его не распознает как dll библиотеку, он ей наверное и не является, как в таком случае быть ?
Аватара пользователя
dadreamer

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

Re: Альтернатива VISA для работы с последовательным портом

Сообщение dadreamer »

toshas писал(а): 19 май 2021, 10:19вызвать из serpdrv ? LV его не распознает как dll библиотеку, он ей наверное и не является, как в таком случае быть ?
Прямо с диаграммы вместо Device Control/Status. Но там, насколько я вчера понял, не совсем всё просто. Как будет время, поэкспериментирую, если будут какие-то успехи, напишу.
Аватара пользователя
dadreamer

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

Re: Альтернатива VISA для работы с последовательным портом

Сообщение dadreamer »

toshas, починил.
serpdrv LV2019+.rar
(581.84 КБ) 120 скачиваний
Немножко погонял на нуль-модемном кабеле, вроде всё работает.
Аватара пользователя
toshas
assistant
assistant
Сообщения: 105
Зарегистрирован: 05 апр 2009, 22:45
Версия LabVIEW: 9.0
Благодарил (а): 13 раз
Поблагодарили: 7 раз
Контактная информация:

Re: Альтернатива VISA для работы с последовательным портом

Сообщение toshas »

dadreamer, все отлично работает!

Можете рассказать, как была восстановлена функциональность Device Status/Control.vi ? По версии из LV6.1 ?
https://forums.ni.com/t5/LabVIEW/What-w ... td-p/76846

И еще вопрос, как вы считаете, стоит ли просить NI оставить serpdrv в покое ?
Похоже есть все шансы, что в следующей версии LV они снова какой-то vi для serpdrv заполнят заглушкой.
Аватара пользователя
jane_wild
master
master
Сообщения: 459
Зарегистрирован: 30 июн 2016, 02:11
Версия LabVIEW: 2020
Благодарил (а): 83 раза
Поблагодарили: 15 раз
Контактная информация:

Re: Альтернатива VISA для работы с последовательным портом

Сообщение jane_wild »

dadreamer писал(а): 28 май 2021, 15:31 toshas, починил.serpdrv LV2019+.rarНемножко погонял на нуль-модемном кабеле, вроде всё работает.
Скачала, разархивировала и запустила Simple Serial (serpdrv) LV2019+.vi
В результате ошибка 37 при открытии порта. Что я забыла сделать?
(Win 10, LV 2020-32bit, порт виден в системе как "Virtual COM Port (COM10)" утилита Hercules с данным портом работает без проблем.
Спасибо
Аватара пользователя
dadreamer

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

Re: Альтернатива VISA для работы с последовательным портом

Сообщение dadreamer »

jane_wild писал(а): 30 июн 2021, 15:41Скачала, разархивировала и запустила Simple Serial (serpdrv) LV2019+.vi
В результате ошибка 37 при открытии порта. Что я забыла сделать?
Вероятно, забыли поместить serpdrv рядом с labview.exe. Вот этот пост читали?
Аватара пользователя
jane_wild
master
master
Сообщения: 459
Зарегистрирован: 30 июн 2016, 02:11
Версия LabVIEW: 2020
Благодарил (а): 83 раза
Поблагодарили: 15 раз
Контактная информация:

Re: Альтернатива VISA для работы с последовательным портом

Сообщение jane_wild »

dadreamer писал(а): 30 июн 2021, 15:52 Вероятно, забыли поместить serpdrv рядом с labview.exe. Вот этот пост читали?
Уже да. :wink: Все равно ошибка 37 :dntknw: Видно не судьба. Придется визой пользоваться.
Аватара пользователя
dadreamer

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

Re: Альтернатива VISA для работы с последовательным портом

Сообщение dadreamer »

jane_wild писал(а): 30 июн 2021, 16:02Уже да. :wink: Все равно ошибка 37 :dntknw:
:labview: 2020 32-bit - всё работает.
1. В serpdrv нумерация портов начинается с нуля. Для COM10 нужно открывать port number = 9.
2. Есть ли в labview.ini параметр serialDevices? Если есть, чему равно его значение? Если нет, создайте и перечислите доступные в системе порты. Например
serialDevices="COM1;COM2;COM3;COM4;COM5;COM6;COM7;COM8;COM9;\\.\COM10;\\.\COM11;\\.\COM12;\\.\COM13;LPT1;LPT2"
Или так:
serialDevices="COM1;COM2;LPT1"
Соответственно, COM1 будет 0-м, COM2 будет 1-м и так далее. Подробнее здесь: https://digital.ni.com/public.nsf/allkb ... FE006F3801
3. Если есть в системе обычные "железячные" порты, попробуйте их открыть также (для проверки).
4. Разблокируйте файл serpdrv, если он заблокирован (в свойствах файла).
5. Убедитесь, что взяли файл для Windows, а не для Linux (мало ли).
jane_wild писал(а): 30 июн 2021, 16:02Придется визой пользоваться.
А как же это?
Аватара пользователя
dadreamer

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

Re: Альтернатива VISA для работы с последовательным портом

Сообщение dadreamer »

toshas писал(а): 30 июн 2021, 13:06Можете рассказать, как была восстановлена функциональность Device Status/Control.vi ? По версии из LV6.1 ?
Году в 2016-м я изучал работу жёлтых блоков Device Manager, с тех пор остались кое какие наработки, которые всё-таки пригодились. В то время я даже состряпал тестовый драйвер, который исправно грузился вместо serpdrv в :labview: , но дальше него дело не пошло. Исходников serpdrv нет, а реверсить это дело тогда показалось довольно времязатратной затеей, а сейчас и вовсе бессмысленно. Есть альтернативы, да и потихоньку народ переходит на 64 бита (линуксоиды и маководы так давно уже; я и сам давно пишу в LV x64).

Если интересны технические детали, то вот. Как я писал ранее, на Mac OS (ещё когда она работала на Motorola 68k и PowerPC) было специальное системное API для работы с устройствами, т.н. Device Manager. Менеджеров там было много, но конкретно этот также работал и с драйвером последовательного протокола. Обычно это использовалось для связи с модемом (порты .AIn / .AOut) и принтером (порты .BIn / .BOut). Хотя можно было работать в принципе с любом устройством в системе. Здесь вся архитектура расписана более подробно. На Маке жёлтые блоки :labview: напрямую дёргали встроенные функции ОС.
Open Device -> DevOpen -> FUNCTION PBOpenSync (paramBlock: ParmBlkPtr): OSErr;

Read Device / Write Device -> DevWrtRd -> любая из этих функций:
FUNCTION PBWriteAsync (paramBlock: ParmBlkPtr): OSErr;
FUNCTION PBWriteSync (paramBlock: ParmBlkPtr): OSErr;
FUNCTION PBReadAsync (paramBlock: ParmBlkPtr): OSErr;
FUNCTION PBReadSync (paramBlock: ParmBlkPtr): OSErr;

Device Control/Status -> DevCtrlStat -> любая из этих функций:
FUNCTION PBControlAsync (paramBlock: ParmBlkPtr): OSErr;
FUNCTION PBControlSync (paramBlock: ParmBlkPtr): OSErr;
FUNCTION PBStatusAsync (paramBlock: ParmBlkPtr): OSErr;
FUNCTION PBStatusSync (paramBlock: ParmBlkPtr): OSErr;

DevAbort -> две функции:
FUNCTION PBControlImmed (paramBlock: ParmBlkPtr): OSErr;
FUNCTION PBKillIOSync (paramBlock: ParmBlkPtr): OSErr;

DevClose -> FUNCTION PBCloseSync (paramBlock: ParmBlkPtr): OSErr;
В блоке Open Device, кстати, я даже нашёл баг. Вход unit(0) соответствует полю ioVRefNum (тип short = I16) в структуре ParamBlock (/* volume reference or drive number */), но при вызове Control/Status ioVRefNum равен 0, т.е. unit(0) почему-то в системную функцию не передаётся, хотя должен. Из-за этого Device Manager :labview: нельзя полноценно заюзать для работы с Mac OS, что было бы интересно. Но и без этого, на эмуляторе мне удавалось:
- открыть произвольный файл, считать/записать его, закрыть;
- открыть диск (hdd), считать заданное число байтов, закрыть;
- извлечь CD-ROM (может быть, даже выехал бы лоток, будь у меня физический Мак);
- отправить гештальт на некоторый девайс.
Дальше у меня фантазия уже кончилась. :D Сами :vi: есть в наличии.

На Linux и Windows так просто нельзя было прилинковать жёлтые "кубики" :labview: к системным вызовам. Поэтому для унификации NI решили написать обёртки, которые бы выполняли "грязную" работу: serpdrv, daqdrv и gpibdrv. Структура обёртки не особо отличается от структуры стандартных CIN'ов, немного другая таблица экспорта и всего четыре специфических входных точки: InitDevice, DeviceCtrlStat_WrtRd, DeviceProd и DeviceClose. То есть, когда мы вызываем жёлтый "кубик" Open Device, :labview: вызывает внутреннюю функцию DevOpen, а та вызывает InitDevice из serpdrv. Дальше по аналогии: Read Device / Write Device и Device Control/Status -> DevWrtRd и DevCtrlStat -> DeviceCtrlStat_WrtRd. DeviceProd и DeviceClose собственных "кубиков" не имеют, но они тоже вызываются через врапперы: ProdDriver и DevClose.

Когда NI заменили код функций LockFlat и UnlockUnflat, они просто "сломали" конверсию входного параметра param (-) блока Device Control/Status. Предполагаю, это использовалось для приведения параметра к flattened-виду, ну и возможно, фиксировался адрес в памяти. Эти функции больше нигде в :labview: не использовались. Аналогичную конверсию легко сделать прямо на БД с помощью Flatten To String и закинуть данные по выделенному адресу (DSNewPtr / DSNewPclr + MoveBlock). Короче, все подготовительные манипуляции перед вызовом DevCtrlStat легко повторить на диаграмме, что и сделано в Device Control Status LV19+.vim (загляните внутрь). Параметр Param (-) тоже адаптивный, благо .vim это легко обеспечивают. По поводу Occurrence есть некоторые нюансы, которые посложнее объяснить. Это связано с (а)синхронными вызовами драйвера. Нужно показывать на тестовом драйвере. Если хотите, попробую.
toshas писал(а): 30 июн 2021, 13:06И еще вопрос, как вы считаете, стоит ли просить NI оставить serpdrv в покое ?
Это ничего не даст. С вероятностью 100% NI ответят, что негоже использовать legacy-технологии и нужно непременно перейти на VISA. Поддержка недокументированного и устаревшего кода не оказывается.
toshas писал(а): 30 июн 2021, 13:06Похоже есть все шансы, что в следующей версии LV они снова какой-то vi для serpdrv заполнят заглушкой.
Не исключаю этого. Похожим образом они "поломали" модуль C Generator и в :labview: 2020 он не работает. Но там не пофиксить - нужные функции просто были выпилены без остатка. Здесь ситуация лучше. Поживём - увидим. Может, и не придётся ничего чинить. Но если сильно переживаете, переключайтесь на альтернативы или не обновляйте :labview: . Больше я тут ничего не посоветую.
Ответить
  • Похожие темы
    Ответы
    Просмотры
    Последнее сообщение

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