VISA -> Serial ошибка обмена данными

[ZAFA]

Здравствуйте, у меня возникла проблема с реализацией обмена данными через последовательный порт (COM3). Суть проблемы заключается в следующем, для разработанного устройства необходимо было организовать пользовательский интерфейс - для этого был выбран LabVIEW v.2012(32bit). Я в этом не спец, но разобравшись что к чему - связь между средой LabVIEW и оконечным устройством была налажена, правильно или не совсем, но оно работало как надо, исходящие пакеты отправлялись и принимались квитанции от устройства ( проверка целостности посылок и ответных квитанций была реализована через CRC16). В общем ближе к сути... Есть 2 компьютера на которые была установлено одна среда LabVIEW с одного диска, есть два готовых устройства, полностью идентичных в аппаратном и программном смысле. На одном ПК был разработан проект, отлажена связь с одним оконечным устройством, при попытке запустить этот проект на другом ПК с точно таким же оконечным устройством - LabVIEW выдал какую то критическую ошибку, причем на момент запуска проекта, а не в процессе работы, ну особо не вчитываясь нажал repair. Виртуальный прибор запустился, но связь с прибором перестала работать, то есть данные отправляются, а в ответ приходит не корректный пакет, по сути мусор. Содержание которого не зависит от того, что я отправляю не меняется (всегда приходитодно и тоже). С проекта LabVIEW был до этой ситуации сделан .exe, который так же работал до этой ошибки, после чего перестал. Связь с устройством можно установить не через LabVIEW, а через программу терминал, так вот, при отправке того же пакета через терминал, оконечное устройство отвечает корректно, то есть проблема явно не в устройстве. LabVIEW я на всякий случай переустановил, реестр почистил все как надо на всякий случай. После установки чистой версии на тот же ПК, да другой локальный диск, проблема не была решена. Оконечное устройство работает через микросхему преобразователь FTDI 232RL, то есть через виртуальный COM port 3, работает с терминалом как положено, то есть с драйверами FTDI, проблем нет, так как и терминал и LabVIEW работают через один виртуальный порт, естественно я не пытаюсь одновременно отправить данные и через LabVIEW и через терминал, то есть конфликта быть не может. Может у кого нибудь такое было, или хотя бы есть идеи в чем проблема?

[dadreamer]

1. Через какой API организована связь с устройством - VISA или библиотеки FTDI?
2. Пробовали ли переустановить VISA/драйвер и либы FTDI?

[ZAFA]

Ниже изображения фрагмента Vi и терминала, с отправкой => чтением пакета из устройства. И там и там, отправляется 2 байта 71- код команды- 0F - данные. В терминале приходится вручную отправлять СRC16,
Vi же считает сам все, и отправляет в устройство с интервалом 1мс. В терминале выделен принятый пакет (F1.65.Е4.07). Аналогично считается CRC16 и проверяется.Суть в том что Vi должен отображать только 1 и последний байт пакета. То есть на индикаторах Vi - DATA Rx1 и DATARX2 должны быть значения F1 и 07. STATUS отображает готовность к обмену, то есть после отправки 71 происходит чтение из устройства и сравнение кодов. Они должны совпасть после сброса 7 бита пакета. Они не совпадают. LabVIEW или не пишет данные или не читает из устройства, До возникновения той ошибки о которой я говорил выше, все работало корректно, и в .exe и в VI проекте и в терминале.

[ZAFA]

Отправляется все через Visa в VI. Терминал написан не мной, и не на LabVIEW это независимое приложение. После вчерашних попыток найти причину, снес полностью весь LabVIEW и все что с ним связанно, после чего установил чистую версию с того же диска. FTDI не трогал вообще потому как смысл его трогать если он работает с терминалом, причем нормально.

[dadreamer]

Честно говоря, пока затрудняюсь сказать что-то конкретное.

LabVIEW выдал какую то критическую ошибку, причем на момент запуска проекта, а не в процессе работы, ну особо не вчитываясь нажал repair.

По памяти, не видел ни разу подобной кнопки при открытии проекта. Repair есть вот тут:

Но в автомате туда никак не должно перекинуть.

А так, если раньше всё работало именно в , а сейчас не хочет, то вариантов не так много. Снесите Визу и поставьте самую последнюю версию, соответствующую вашей версии LV: http://digital.ni.com/public.nsf/allkb/ ... 1F00003B82

Проверьте также на другом ПК, на чистой системе (чтобы исключить возможные ошибки в текущей ОС).

Ну, или есть более радикальный вариант - провести ревизию настоящего кода - либо выкладываете код работы на Визе и вместе смотрим, где какие косяки и исправляем, либо переходите на библиотеки FTDI вместо Визы и проверяете на них.

[ZAFA]

Всплывшее окно было не таким как вы показали. К сожалению скрина нет. Драйвера USB=>Serial (FTDI) переустановил, не помогло... Терминал работает, VISA - соединения нет... Код можно выложить только его работу без реально устройства не проверить.

[ZAFA]

Переустановка VISA последнюю версию совместимую с 2012 - 15.5 тоже ни к чему не привела. К большому сожалению...

[dadreamer]

Плохо дело. Ну, значит, придётся смотреть код. Конкретно, то место, где отправляется вышеописанная команда и где производится её разбор.

Хотя, перед этим можно пройтись сниффером трафика, например NI I/O Trace (NI Spy), вдруг что подскажет...

[ZAFA]

Создал Vi отвечающий только за отправку и чтение данных. Заранее прошу прощения если вы увидите там какую околесицу, но с я работаю буквально недавно, 3 или 4 день, так что если дадите какие либо критические замечания что неправильно я делаю или не корректно, то буду благодарен.

[dadreamer]

Теперь надо почитать протокол связи с устройством, чтобы разобраться в командах. Учтите, что по дефолту используется терминатор Line Feed, посмотрите, так ли это на самом деле.

По диаграмме есть кое какие замечания.

1) VISA Configure Serial Port нет необходимости вызывать дважды. Это фактически открытие COM-порта. Вы уже открыли порт, получили сессию (пурпурный провод), вот и тащите дальше этот провод через все инструменты, до закрывающего (VISA Close).
2) Задержки в 1мс никакого смысла не имеют, тем более на Винде, где погрешность таймера системы составляет 10-20 мс. При корректно организованной последовательности чтения-записи никаких задержек не нужно.
3) Сама по себе Sequence Structure в таком виде вообще не нужна, т.к. у вас порядок выполнения операций задан потоком данных, идущих по проводу сессии и проводу ошибок (error in/out). Так что можно вообще убрать эту структуру.
4) Не знаю, насколько оправдано двойная запись и тройное чтение в конце рисунка - нельзя ли реализовать подобное через однократную запись и однократное чтение? Это было бы лучше, чем считывать по 1 байту.

CRC проверять не буду, надеюсь, у вас там всё правильно.

[ZAFA]

Спасибо за замечания, учту.
1) Насчет двойного открытия я понял, но вот что я хотел этим добиться: подчиненное устройство работает как рестранслятор с расширенными функциями. Оно не все время стоит и ждет байта по UART, оно выполняет другие функции. Если в момент обращения, оно было занято другими задачами, оно не ответит на запрос. Для этой цели и идет побайтовое дробление. Первый баит, отправляет не только код команды, но по идее должен определять готово ли устройство к обмену, если на отправленный байт пришел ответ, то значит устройство готово к обмену и можно осуществлять последующую транзакцию пакетов. И вот тут вопрос! Я рассчитывал что в функциях VISA есть флаг отработки события который будет выставляться если чтение не удалось произвести, но как я потом выяснил это приводит к полной остановке с выводом окна ошибка VISA. МОжет я не так понял, и эта функция все таки есть? То есть если после отправки данных в течении какого то времени не пришел ответ, то просто зажечь, допустим, светодиод на панели с написью "Busy", и продолжить опрос кнопок или вроде, а не останавливать всю программу?
2)Насчет задержек... Они нужны для оконечного устройства, на том конце стоит контроллер разрядность входящего буфера UART не превышает 1 байта, если ему потоком сунуть стринг, он просто захлебнется, для этого задержки на передачу, с чтением таких проблем нет. И тут еще один вопрос. Можно ли выставить задержке менее 1 мс?
3) Насчет однократной записи, и многократной записи, я уже во 2 пункте написал. То ест суть в том что 1 байт - как бы статусный, он задумывался как отправка - команды => прием квитанции о готовности или не готовности, далее задержки сделаны для того чтобы контроллер не захлебнулся стрингом, а смог буферизовать данные, передача идет на низкой скорости, и думаю их можно будет выкинуть. Но потом попробую, когда выясню причину почему перестало все работать.
4) Насчет терминаторов я вроде выставлял соотвествующие настройки, проверю еще раз отпишусь.

[ZAFA]

Но в любом случае, протокол я сам придумывал и знаю как и что там должно быть, он прост.
1/{Первый байт передачи- отправка команды ожидание квитанции готовности от контроллера} - квитанция - заключается в том, что контроллер принимает байт, проверяет соответствие системы команд на наличие этой принятой команды, после чего контроллер инвертирует старший (7 бит) принятой команды и отправляет обратно в UART шину. если контроллер занят другими делами, он оставит принятую команду без ответа (вот тут я хотел бы и узнать, как завершить ожидание приема баита VISA, корректно, то есть если байт не пришел, как завершить последовательность обмена без крэша всей программы);

2/{контроллер посылает видоизменную команду, т.е. принятую с инвертированным старшим битом} (при условии, что на момент запроса он был в режиме ожидания);

3/{ сравнивает отправленную команду, с принятой квитанцией, предварительно инвертировав в квитанции старший бит} (если команда и квитанция сошлись зажигается STATUS) в этот момент контроллер находится в режиме ожидания данных от

4/{ отправляет подкоманду/данные}

5/{подсчет CRC16 (из байтов команды и подкоманды)и передача 2х байт в UART}

6/{контроллер пересчитывает принятые баиты команды и подкоманды и вычисляет из них CRC16}

7/{ передача 2х байт в UART (передается подсчитанное CRC16- которое подсчитал контроллер из принятых байтов команды и подкоманды)}

8/{передача параметра выполнения/отмены команды}

выглядит это примерно так
=>
Labview: [команда]|
|
| <=
MCU: [квитанция]

[Shamrel]

Может быть меня закидают помидорами, но, на мой взгляд, наиболее удобно работать в LabVIEW с преобразователем FTDI через драйвер FTD2XX.DLL.
Однако есть одно небольшое НО: работа с длл напрямую -- это уже не для начинающих. Однако тут есть еще одно но, правда поменьше:
на сайте FTDI есть готовая библиотека для LabVIEW, где созданы VI обертки для вызова dll.
LabVIEW Examples
В сети масса примеров, как все это дело использовать, но вот годнота на русском языке:
Учебный стенд и LabVIEW

P.S.: С Visa у меня дела не сложились, после того, как словил проблему дрыгания вручную ножками RS-232.

[ZAFA]

Спасибо за информацию, буду иметь ввиду. Только последовательность действий по шагам как раз наоборот, готово все кроме обмена, который тоже работал причем без проблем, по началу, до того момента как не дернуло меня на домашнем ПК запустить проект с работы. Завтра попробую на работе запустить проект с обоими устройствами, посмотреть что будет. Просто если с обоими блоками будет стабильный обмен, то что делать дальше не представляю? Сносить винду или что? Переустановка не помогла. Разве что с библиотекой FTDI мучаться, что тоже не гарантирует успеха. Просто, если бы проблема была бы с блоком, терминал бы не работал все равно, а он работает... То есть проблемы с аппаратной и программной частью блока скорее всего исключены.

[dadreamer]

Насчет двойного открытия я понял, но вот что я хотел этим добиться

Честно говоря, не понял, как связано двойное открытие с занятостью устройства и делением строки на байты. Если вы хотели таким образом выполнить параллельную операцию, то это не так делается. Да и вообще, интерфейс потому и называется последовательным, что данные передаются побайтово. У такого устройства только один входной буфер и один выходной. Хотя, вы это и без меня знаете. Поэтому обычно коммуникация с такими девайсами выносится в отдельный цикл, можно даже в два цикла при желании (приём-передача), а связь между циклами организуется в виде очереди. Тогда развязывается вход с выходом, а сами данные передаются строго друг за другом.

И вот тут вопрос! Я рассчитывал что в функциях VISA есть флаг отработки события который будет выставляться если чтение не удалось произвести, но как я потом выяснил это приводит к полной остановке с выводом окна ошибка VISA. МОжет я не так понял, и эта функция все таки есть? То есть если после отправки данных в течении какого то времени не пришел ответ, то просто зажечь, допустим, светодиод на панели с написью "Busy", и продолжить опрос кнопок или вроде, а не останавливать всю программу?

Можно сделать так:

таймаут операций чтения/записи делаете скажем 50-100 мс и анализируете кластер error out после VISA Read. Таким образом можно избежать использования VISA Bytes At Serial Port. Это в простом случае, когда не хотите заморачиваться с протоколом.

См. пример: http://www.labviewportal.org/viewtopic. ... 566#p69566
Но раз вы и сами определяете протокол, то лучше организовать это на уровне протокола. Скажем, не пытаться связаться с устройством, пока оно обрабатывает команды, а ожидать ответа от него. На каждый запрос - свой ответ. На некорректный запрос - ответ об ошибке. Терминатор задаём сразу и работаем по нему и на приём, и на передачу. Довольно просто. Формат пакетов можно уточнить. В общем случае формат может быть таким: http://labviewportal.org/viewtopic.php?p=65865#p65865

Насчет задержек... Они нужны для оконечного устройства, на том конце стоит контроллер разрядность входящего буфера UART не превышает 1 байта, если ему потоком сунуть стринг, он просто захлебнется

Ну и ну. А что такой маленький буфер? Ну, тогда надо ставить задержку не 1 мс, а больше, 10-15. Ибо пауза в 1 мс в реальности будет соответствовать джиттеру в 10-15 мс, т.е. будет то 0 мс (без задержки), то 10 мс, то 15.

И тут еще один вопрос. Можно ли выставить задержке менее 1 мс?

Можно, но бессмысленно из-за того, что Windows - не ОСРВ.

если контроллер занят другими делами, он оставит принятую команду без ответа

Как я выше написал, лучше было бы так: получил команду - послал ответ, типа "обрабатываю" - программа ждёт - как обработал, послал ответ "готов" и/или сами данные. Тогда бы и не было коллизий с одномоментными операциями.