slayer Posted January 21, 2016 Share Posted January 21, 2016 Добрый день. Имеется задача: запустить ModBus Slave на контроллере под управлением ОС QNX 6.5, чтобы отдавать данные через Moxa nPort IA-5150 в режиме RealCom Mode. Драйвер под QNX взят с сайта и скомпилирован, корректно запускается и работает. Moxa nPort IA-5150 настроена в соответствии с моими представлениями о том, как это должно быть сделано. При использовании ModBus начинаются проблемы. В контроллер втыкаем витую пару от Moxa, запускаем драйвер, запускаем программу ModBus Slave, на другом конце ноутбук подключенный к Moxa по 232 или 485, не важно, ситуация идентична, на ноуте запускается ModBus Master, который отправляет запросы в порт. Но к слейву запросы приходят разбитыми на части и с отсутствующими байтами. Выглядит это так: Запрос от мастера: 000055-Tx:01 03 00 2A 00 0A E4 05 Что видит слейв: got 1 bytes from port 01 CRC ERROR! got 2 bytes from port 00 0A CRC ERROR! got 1 bytes from port E4 got 2 bytes from port 00 0A CRC ERROR! got 1 bytes from port E4 got 1 bytes from port 01 CRC ERROR! got 2 bytes from port 00 0A CRC ERROR! Примечательно то, что наоборот: мастер на контроллере, слейв на ноутбуке - все работает. В корректности используемого ПО тоже нет сомнений, при исключении из связки Moxa и подключении к физическому COM-порту контроллера обмен работает нормально. Так же замечена странная ситуация, когда с ноутбука пишешь в COM-порт произвольную последовательность байт, то до контроллера они не доходят, а возвращаются от Mоxa обратно в COM-порт ноутбука, т.е. получается некая петля. С контроллера же, при записи в COM-порт Moxa, данные передаются корректно (аналогично с ситуацией для ModBus, когда в одну сторону запросы идут, а в другую - нет). Подскажите пожалуйста, куда копать в данной ситуации. Конфигурация Moxa во вложении. cfg.txt Link to comment
Незнайка Posted January 21, 2016 Share Posted January 21, 2016 Здравствуйте! Опуская ситуацию с "возвращающимися данными" - попробуйте изменять значение поля Force Transmit (это я применительно к первой части вашего сообщения сейчас). Рекомендуемые величины - от 5 до 50 мс. Находится этот параметр в разделе Operation Settings. Будет ли изменяться поведение схемы? Link to comment
slayer Posted January 21, 2016 Author Share Posted January 21, 2016 Попробовал значения 5, 25, 50. Ситуация изменилась, при любом значении приходит только один первый байт: номер слейва. got 1 bytes from port 01 CRC ERROR! got 1 bytes from port 01 CRC ERROR! got 1 bytes from port 01 CRC ERROR! got 1 bytes from port 01 CRC ERROR! got 1 bytes from port 01 CRC ERROR! Link to comment
slayer Posted January 21, 2016 Author Share Posted January 21, 2016 По поводу "возвращающихся данных": Шлю в порт некую последовательность, через 11 мс. она мне приходит обратно: В это время на принимающей стороне: То есть - тишина. Должно быть так: Это минуя Moxa. Напрямую в железный COM-порт контроллера. Link to comment
slayer Posted January 22, 2016 Author Share Posted January 22, 2016 Если вместо контроллера с QNX взять компьютер с Windows и повторить эксперименты, приведенные выше, то все работает корректно. Как обычная передача данных в порт, так и ModBus-запросы. Из чего делаю вывод о частичной неработоспособности драйвера nPort 5150 под UNIX, в частности под QNX 6.5. Куда можно обратиться по этому вопросу? Link to comment
Незнайка Posted January 22, 2016 Share Posted January 22, 2016 Понятно. В таком случае (для диагностики) - давайте попробуем взаимодействовать с IA-5150 "напрямую", минуя драйвер виртуального COM со стороны QNX. То есть, возьмём какой-либо терминал, и подцепимся на TCP-сокет 950 IA-5150. В каком виде на терминал будут приходить запросы от master - устройства? Link to comment
slayer Posted January 25, 2016 Author Share Posted January 25, 2016 На терминал запросы приходят корректно: 00000000: 01 03 00 2B 00 0A B5 C5- + µЕ И сразу целиком. Link to comment
Незнайка Posted January 25, 2016 Share Posted January 25, 2016 В общем-то - как и предполагалось. Были и до этого подобного рода подозрения. Укажите, пожалуйста, версию драйвера, который используем? Link to comment
slayer Posted January 25, 2016 Author Share Posted January 25, 2016 Драйвер NPort Fixed TTY Driver для Unix (версия 3.5 от 20.03.2012) Так написано на сайте moxa.ru. Product: NPort/Async Server Fixed TTY driver Version: 3.5 Build 11032510 Date: 03/25/2011 Так написано в файле Version.txt. Link to comment
Незнайка Posted January 25, 2016 Share Posted January 25, 2016 Давайте попробуем посвежее (во вложении). Что получится? Хотя, есть определённые подозрения, что конкретный драйвер придётся подстраивать под конкретное ядро, применительно к ОС реального времени. Для достижения требуемой частоты опроса буфера NPort. Ибо опрос из файла (tty устройства) и опрос сетевого сокета - в общем-то разные вещи. Теперь давайте порассуждаем. Вы пишете: "Примечательно то, что наоборот: мастер на контроллере, слейв на ноутбуке - все работает.". То есть, контроллер формирует запрос 01 03 00 2A 00 0A E4 05 (0A записей по 2 байта), который, в свою очередь на QNX корректно распознаётся, и в ответ отправляется порядка 40 байт ответа (34+4+2) , которые, в свою очередь, корректно воспринимаются контроллером. Я к чему веду - от перемены master-slave работоспособность то не должна меняться. Либо вы что то недоговариваете, либо это всё таки проблемы на последовательном шлейфе. На что косвенно указывает наличие так называемой "петли", описываемой во втором разделе сообщения. moxattyd_3.5.3_build_15032315.tar VERSION.TXT Link to comment
slayer Posted January 25, 2016 Author Share Posted January 25, 2016 Я и сам не понимаю, почему мастер получает данные нормально, а слейв - нет. Странная ситуация. Интерфейсный кабель уже менял, в том числе и на заводской. Пробовал передавать данные и по 232, и по 485. Не помогает. С новой версией драйвера ситуация аналогичная. Link to comment
slayer Posted January 25, 2016 Author Share Posted January 25, 2016 Выяснилась очень интересная штука: та самая "петля" - это вовсе не аппаратная ошибка связи, это ответ драйвера такой. Видно, что в посылке, те байты, который начинаются на 0, заменяются драйвером на 5E 40 и посылка отправляется обратно. Когда я в первый раз обнаружил эту "петлю", у меня в посылке не было байтов, начинающихся на 0, поэтому мне вернулось ровно то, что я отправлял. Сейчас я попробовал отправить в порт обычный ModBus запрос, а на другом конце просто отключил слейв и запустил прослушку этого порта. Вот такие данные мне возвращаются от драйвера, та же посылка, просто с замененными байтами. Причем такая своеобразная петля работает только, когда я слушаю порт на стороне QNX, если порт не прослушивается, то возврата посылки не происходит. Ровно такой же ответ приходит и ModBus-мастеру, когда тот запрашивает данные от слейва: Тот же самый запрос с замененными байтами. А слейв в это время получает из порта какую-то билиберду. То есть ситуация такая: вне зависимости от того, запущен ли на принимающей стороне слейв, или же порт просто прослушивается с помощью cat /dev/ttyp, драйвер возвращает посылку назад, заменяя в ней байты начинающиеся с 0 на некую последовательность символов. Link to comment
Незнайка Posted January 25, 2016 Share Posted January 25, 2016 То есть: 1. Modbus-master на QNX - всё работает. 2. Modbus-slave на QNX (или прослушка) - не работает. При этом видно, что в случае, когда не работает - (дополню) - появляется эхо-ответ, в котором к некоторым данным добавляется 5E 40, а некоторые (03 и д.р) - игнорируются. Вопросы: 1. Какая конкретно версия QNX? 2. Какие настройки последовательно порта в QNX (stty)? Конкретно интересуют полные настройки. Link to comment
slayer Posted January 25, 2016 Author Share Posted January 25, 2016 Операционная система QNX 6.6 (ЗОСРВ "Нейтрино" КПДА.10964-01). Настройки порта: /isagraf $ stty -a </dev/ttyp8 Name: /dev/ttyp8 Type: pseudo Opens: 1 -parenb -parodd -parstk -cstopb -inpck +hupcl +cread -clocal +isig +icanon +iexten +echo +echoe -echok +echoke -echonl +echoctl -noflsh -ignbrk +brkint -ignpar -parmrk -istrip -inlcr -igncr +icrnl +imaxbel +opost +onlcr -isflow +osflow -ihflow -ohflow intr=^C quit=^\ erase=^? kill=^U eof=^D eol=^- eol2=^- swtch=^- start=^Q stop=^S susp=^Z dsusp=^- reprint=^- discard=^- werase=^- lnext=^V min=01 time=00 fwd=^- login=^- pr1=^[ pr2=5B pr3=^- pr4=^- sf1=^- sf2=^- sf3=^- sf4=^- left=44 right=43 up=41 down=42 ins=40 del=50 rub=^- can=^- home=48 end=59 par=none bits=8 stopb=1 baud=115200 rows=0,0 Link to comment
Незнайка Posted January 25, 2016 Share Posted January 25, 2016 Ну вот, более-менее прояснилось. +echo - эхо-ответ, например. Ну то есть вот и причина, откуда петля. Дальше надо смотреть все эти параметры (отмеченные знаком +) на предмет их функционального назначения. Неохота тонуть в дебрях www.qnx.com, если честно. Есть предложение отключить их, тем или иным способом, и проверить функциональность. Поясню мысль: QNX-master - отправляет запрос - slave отвечает - в ответ QNX-master отправляет эхо - slave выбрасывает эхо (т.к. не распознаёт адрес) - всё работает QNX-slave - получает запрос - отправляет master эхо - master даёт ошибку - обмена нет. Link to comment
slayer Posted January 25, 2016 Author Share Posted January 25, 2016 Все так. Просто система не дает менять эти опции, если порт уже открыт драйвером moxattyd. И настройка этих параметров должна происходить и происходит на уровне драйвера. Поясню: скорость, четность и т.д. драйвер берет из настроек Moxa и устанавливает их для порта, прописанного в конфигурации. Аналогичным образом должно отключаться эхо и другие ненужные опции. Ну то есть я при всем желании не могу изменить настройки порта, для этого необходимо лезть в код драйвера. Link to comment
Незнайка Posted January 25, 2016 Share Posted January 25, 2016 Вот тут не соглашусь. Базовые параметры (скорость, чётность и т. д.) драйвер как раз таки берёт из приложения, обращающегося в порт, и передаёт их на NPort (в режиме RealCOM), а уже NPort, в свою очередь, "открывает" свой "железный" интерфейс с требуемыми параметрами. Код драйвера собственно представлен в файле moxattyd.c, и поменять его как раз таки можно. Но дело-то в том, что этих параметров (я искал echo и icanon) в нём нет. Согласитесь, что нельзя поменять того, чего нет. Я честно скажу - в QNX понимаю ужасно мало, но на мой взгляд - искать их следует именно в ОС. Link to comment
slayer Posted January 25, 2016 Author Share Posted January 25, 2016 Для чего тогда в настройках Moxa задаются параметры порта, если он все равно потом порт будет открыт с параметрами приложения пользователя? Link to comment
Незнайка Posted January 25, 2016 Share Posted January 25, 2016 Для других режимов работы, таких как TCP server, например. Более того, изменяя настойки Max. Сonnection и Allow Driver Control можно включать/отключать поддержку этой опции в режиме RealCOM. Link to comment
slayer Posted January 25, 2016 Author Share Posted January 25, 2016 Понятно. Да, Вы правы, настройки порта можно конфигурировать на уровне приложения QNX. Эхо я отключил. Теперь возврат не приходит. Но к слейву все равно запрос приходит по частям с отсутствующими байтами. Может есть еще какие-то опции порта, которые нужно включить/отключить/настроить? Link to comment
slayer Posted January 25, 2016 Author Share Posted January 25, 2016 Помогло отключение опций для порта в QNX: ICANON Canonical input mode (line editing enabled). ISIG Enable signals. До этого были включены. Теперь обмен между мастером и слейвом происходит корректно. Огромное спасибо за помощь. Link to comment
Незнайка Posted January 26, 2016 Share Posted January 26, 2016 Ну вот, хорошо, что разобрались! И вам спасибо за интересный вопрос! Link to comment
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now