Jump to content
Форум по продукции MOXA

boris_r_v

Пользователи
  • Posts

    106
  • Joined

  • Last visited

Everything posted by boris_r_v

  1. Считаю в тему закрытой - проблема некорректного приемы была в неверном количестве стоповых битов в ответе slave-устройства, собственной разработки: ожидалось два, а по факту был один. Результат исследования проблемы: В контроллере UC-8112-lx, по сравнению с его аппаратным близнецом UC-2112, по разному прописана работа с УАРТами; Это привело к тому, что при неверной настройке количества стоповых битов (master ждет 2, slave шлет 1), обмен на UC-8112 не работает, а на UC-2112 работает; Также экспериментально установлено, что информационный обмен при неверной настройке стоповых бит работает на следующем оборудовании Моха CP-131, CP-114, UPort-1130, UPort-1400, W321, W325, UC-7112+, Все перечисленное оборудование успешно работает с неверными настройками, а применение UC-8112 позволило выявить проблему в прошивке slave-устройств. Благодарности: Компании Moxa, что делает такое "лояльное" оборудование, хотя конвертер ICP COM i-7561 тоже не заморачивается со стоп битами; Знайке - за участие в решении проблемы.
  2. Хм, так нет на стороне мастера второго единичного стопового бита, после первого наступает пауза (логическая 1-ца), потом старт бит нового байта - 0 и принимаем следующий байт. не вижу пока как можно по вашему описанию из 0х02 получить 0х20 и из 0х96 получить 0хF9, не похоже на сдвинутые байты, да и кодовое растсояние более 1 ... Надо еще раз обдумать и пописать биты. Но https://github.com/boris-r-v/uc8112.git - тестовый софт в котором повторяется эта проблема при использовании 2-х портов UC-8112 Не понятно в чем причина, что UPort трафик с п.1 корректно принимает через tty_sniffer.py Если есть возможность протестировать его на UC21xx было бы отлично, - помнится как то мне удаленку давали на контроллер для тестов - сейчас можно повторить это с UC2112, соединив его порты?
  3. Хм., так это и смущает, что какая-то беда с игнорированием 2-го стоп бита. Т.е. если я ставлю 1 стоп бит на передачу и прием - то все хорошо. Если я ставлю 2 стоп-бита на прием и передачу то UART в slave-device игнорирует второй стоп-бит, принимает запрос, выполняет его и отвечает с 1-м стоп битом, а UC-8112 не может корректно принять ответ - игнорировать нечего, а так ждал и поэтому расстроился, и не принял ответ. Можно вопрос задать так: "Почему UC81xx при задании 2-х стоп битов некорректно принимает ответ от slave-device, у которого в ответе 1 стоп бит, хотя согласно Table 4-235 (https://www.ti.com/lit/ug/spruh73q/spruh73q.pdf?ts=1610351324922) должен игнорировать второй стоп бит от устройства? При этом в UC-21xx в той же ситуации работает согласно Table 4-235. - игнорирует второй бит и принимает ответ корректно."
  4. Возможно, я с вами бы и согласился если не одно, но: оба контроллера UC21xx & UC81xx построены на одном и том же процессоре Armv7 Cortex-A8, (на UC8112 распаян am3352bzcza100) который имеет 6 штук UART на микросхемах TL16C550 согласно документации: https://www.ti.com/lit/ds/symlink/am3357.pdf?HQS=TI-null-null-alldatasheets-df-pf-SEP-wwe&ts=1610364078338&ref_url=https%3A%2F%2Fpdf1.alldatasheet.com%2F https://www.ti.com/lit/ug/spruh73q/spruh73q.pdf?ts=1610351324922 Т.е. железо в обоих контроллерах с большой долей вероятности одинаковое, стоп биты как раз UARTы отмеряют, сл-но остается разница настройках микросхем UART в tty-драйверах контроллеров. Согласно Table 4-235 по второй ссылке TL16C550 синхронизируют только первый стоп бит, независимо от кол-во указанных, но если бит STB в line control register установить в 1 то можно задавать различные варианты 1, 1.5, 2 стоп бита в зависимости от количества бит на символ. Это я к тому, что разная настройка UARTа в разных контроллерах может приводить к тому эффекту о котором идет речь, как бы все таки выяснить есть ли отличия в драйверах у разных контроллерах?
  5. Да когда поставил 1 стоп бит все за отвечало, устройства друг другу не мешают работать, отвечают штатно все 3 (два коротким ответом, один длинным). Но все еще интересней: Девайсы у которых короткий ответ не имеют в своей прошивке для PIC16F873A указания количества стоповых битов, там по-умолчанию один стоп бит, второй добавляли руками и для этого устройства это не сделано, т.е. стоп бит один. Поэтому логично, что UC-8112 не может корректно вычитать ответ, когда ожидает 2 стоп бита, т.к. неверная настройка ком-порта: на мастере 2 стоп бита, на slave 1 стоп бит. Тут чуда не случилось, все стало ясно. Устройства с коротким ответом, конвертеру UPort1130, контроллерам W321, UC-2110 и PCI-платам Moxa CP-132, CP-114 отвечают хорошо при 2-х стоповых битах настройки мастера, хотя на устройстве 1 стоп бит. Почему при неверной настройке работает стоповых битов все работает? - драйвера устройств по-любому причастны Далее: девайс у которого длинный ответ, имеет настройку в прошивке на 2 стоповых бита и с ним прием штатный на UPort1130 и UC8112, не зависимо от того сколько стоп битов ожидает мой софт хоть 1 хоть 2, а в легаси-софте везде и всегда 2 стоповых. Почему UC8112 настроенный на 1 стоповый бит успешно принимает длинный ответ с двумя стоповыми битами? Итог: для ответа в 3 байта (короткий ответ) нужно чтобы на UC8112 было верно указано кол-во стоп битов, на остальных устройствах не важно, а для длинного ответа (порядка 130 байт) настройка кол-ва стоп битов не важна на всех устройствах. Т.е. мое виденье, что ранее во всех устройствах моха были послабления на количество стоповых битов в принимаемых пакетах (как это сделать не знаю), а в UC8112 их убрали и прием коротких ответов на нем логично сломался (не совпали стоп биты). Тут налицо наличие технического долга в софте мастера, т.е. проблема на моей стороне, а не на стороне Moxa. Но почему длинный ответ хорошо принимается на UC8112 с 1 стоп-битом? И коль уж так углубились в дебри, как-то можно выяснить в чем отличия в драйверах ком-портов в части работы со стоповыми битами между рядом устройств: UPort1130, W321, UC2110, CP132. CP114 и контроллером UC8112? Просто если в UC8112 инженеры Моха подчистили свой технический долг и это исправление будет тиражироваться на остальные устройства, конкретно меня и моих коллег ждут тяжелые времена ... Тут везде используются linux драйвера, коллега проверит на windows подскажет.
  6. Наметился прогресс: на переходнике UPort-1130, контроллерах Moxa W321, UC-2110 - прием устойчиво работает когда выставлено 2 стоп бита ( как устройства и отправляют) на переходнике UPort-1130 прием также работает когда выстален один стоп бит, контроллеров w321 uc2110 нет под рукой - проверит не могу а вот на uc-8112 - прием заработал только при одном стоповом бите (и длинного и короткого ответов), когда ставлю два стоповых бита - происходит некорректный прием короткого ответа, и корректный прием длинного. Опрашивал реальные устройства которые по документации (и по исходникам софта который с ними работает с прошлого века) настроены на отправку двух стоповых битов.
  7. С конкретно этого устройства должно быть 0х00 0x02 0x96 приходит 0x00 0x20 0xF9 (в десятичной форме 0 32 249), т.е. верно принимается только стартовый бит. С другого подобного устройства не принимается ничего. принимается 0х0 0х96 - когда ожидали 0х0 0хFF 0х96, т.е. не приняли второй байт
  8. Первый: это тот на котором эксперименты проводятся: s/n TAGHB1019002 moxa@Moxa:~$ kversion -a UC-8112-LX version 3.4 Build 20101418 moxa@Moxa:~$ uname -a Linux Moxa 4.4.0-cip-rt-am335x #1 Tue Aug 11 19:11:02 CST 2020 armv7l GNU/Linux moxa@Moxa:~$ Второй: который с объекта привезли в надежде успешного решения проблемы S/N TBZDB1068246 moxa@Moxa:~$ kversion -a UC-8112-ME-T-LX version 3.0 Build 18110917 moxa@Moxa:~$ uname -a Linux Moxa 4.4.0-cip-uc8100-me #2 Fri Nov 9 17:50:14 CST 2018 armv7l GNU/Linux
  9. Согласен тут не совсем корректно: "0 2 96" должно быть написано 0х0 0х2 0х96 - тогда б не было путаницы Ожидаемый ответ 0х00 адрес 0х96 (0х96 - это константа)
  10. Да на двух последних осцилограммах полярность обратная по сравнению с первыми двумя. Слова которыми обмениваемся: 1. те что не работают. Запрос 0x0 0x2 0x3f 0xff 0xff 0xff 0xff 0xff 0xff 0x5 0xfd Ответ: 0х0, 0x2, 0x96 2. тот что работает. Запрос: 0x0 0x20 0x3 0x0 0x0 0x0 0xb3 0x3 Ответ: 0x0 0x20 0x84 0x10 0xeb 0xac 0xbc 0x2b 0x60 0xad 0x3c 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x8d 0x0 0x0 0x0 0xcd 0x1 0x2 0xbd 0xe6 0xd5 0x2d 0x3d 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x2b 0x60 0x2d 0x3c 0xe6 0xd5 0x2d 0x3c 0xe6 0xd5 0x2d 0x3c 0xe5 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x2b 0x60 0xad 0x3c 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x6a 0x0 0x0 0x0 0x2b 0x60 0x2d 0x3c 0xe6 0xd5 0x2d 0x3c 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x7 0x0 0x0 0x0 0x0 0x0 0x0 0x3 0xf4 0x69 Во всех запросах и ответах первый байт - стартовый, второй адрес устройства. А не использование modbus - это легаси, родом из 90-х, когда интернет был редким и дорогим зверем.
  11. А что тут скажешь, паузы формально описаны только в Modbus, в данном случае не модбас, поэтому формальных ограничений нет. Поэтому мы можешь оперировать только субьективными трактовками. Хотя ограничения на паузы в стандарте модбас тоже появились не просто так ... На стороне опрашиваемых железок, кода который бы считал эту паузу и строго по прерыванию от таймера выдерживал нету. Добавить можно, но что делать с уже поставленными образцами, т.е. есть тяжелый легаси, правка которого экономически нецелесообразна, т.к. есть UC21xx который не имеет такой проблемы, его минус - это форм фактор. Это я к и тому, что есть альтернатива опять же от компании Moxa Поэтому если все так и останется в принципе ничего страшного, UC8112-lx мы купили всего два, и заменить их на UC21xx не стоит огромных денег, а эти отправятся на склад на хранение в ожидании подходящего проекта. Далее ряд замеченных странностей, которые оставляют надежду на решение проблемы: Хорошо бы понять это на время переключения, или что-то иное т.к. на тестовм столе было два однотипных устройства, и картинки которые были ранее - это с того с которого данные не приходят, но был еще один с которого приходили, но не корректные, причем если паралельно читать пакеты из другого tty через python - то там данные приходят верные. Походит на проблему в моем софте, НО есть еще одна странность. Есть еще одно устройство другого типа (назовем его УНС), у которого ответ порядка 140байт, а не 3 как у ранее рассмотренных и оно опрашивается без проблем. При этом интервал между окончанием запроса и началом ответа на УНС: 80мкс - первая картинка, приложенная к данному посту, вторая - тот же запрос и ответ с большей ценой деления по оси времени. Подводя итог под вышесказанным, и принимая новую информацию - грешить только на аппаратную часть не получается. потому как если ответ длинный - то все работает с очень малым интервалом, на том же софте и харде. Поэтому прошу донести эту информацию до разработчика может еще раз заглянут в код tty-драйвера. Сейчас можно сказать, что комбинация: короткий ответ и малый интервал - не работает, а длинный ответ и малый интервал - работает.
  12. Получилось локализовать проблему. Для этого из боевого софта был выкушен кусок кода которые отвечает за работу с ком-портами и на его основе сделан имитатор подчиненного устройства (slave). Был поставлен экперимен: на одном ком-порту UC8112-lx был запущен софт который опрашивает устройство, на втором ком-порту UC8112 был запущен имитатор. Комп порты в режиме RS-485-2W, обвязаны 2-х проводной линией к которой подключено опрашиваемое устройство. Когда работа имитатор физическое устройство выключалось, когда работало устройство - выключался имитатора, во избежание коллизий. Пакет запроса - 11 байт, ответа - 3 байта, скорость 19200. Результат эксперимента: ответы имитатора принимаются, ответы устройства нет. Почему видно из приведенных ниже осcцилограмм: имитатор начинает отвечать через 4мс, после окончания ответа (файл: имитатор_2.jpg); устройство начинает отвечать через 0.5мс, после окончания ответа (файл: устройство_2.jpg) Заставить быстрей отвечать имитатор не получилось - видимо ограничение аппаратной части. Теперь к странному: Если опрашивать два одинаковых устройства, но сидящие на разных адресах, то от одного принимается ошибочно 2-й байт из 3-х, от другого вычитываются 2 байта из трех. Причем ПО ждет удвоенное время необходимое для передачи кол-во байт ответа на заданной скорости, и этого не хватает, чтобы дочитать 1 байт, а может времени ожидания хватает на передачу 6 байт в рассматриваемом случае. К сожалению во время экспериментов я спалил UPort1130, поэтому осциллограмму работы через него предоставлю позже. Да возможно интервал в 0.5мс на начало передачи ответа и мал, но еще раз повторюсь: на контроллерах W321, W325, UC21xx таких проблем не было. Если немного пованговать: - то похоже на то, что переключение на прием происходит медленно (тогда все скорее всего плохо) или при переключении сбрасывается буфер уже принятых байт. Если эту проблему удастся порешать было бы отлично - уж больно формфактор UX81xx хорош по сравнению с UC21xx Благодарен за любой ответ. P.S. Ссылка на имитатор: https://github.com/boris-r-v/uc8112.git (исполняемый tty_slave или tty_slave_one)
  13. Ну из меня такой себе схемотехник, как сделать внешнюю подтяжку нужно еще уметь . Проблема в аппаратной части контроллера, потому как сейчас идут пусконаладочные работы по одному объекту где применяется UC-8112-ME-LX с версией 3.0. И там та же проблема, не работают опрос модулей автоматики, завезли туда с другого объекта UC-21xx, тот же deb пакет и на UC-21xx опрос модулей автоматики работает.
  14. Пробовал. Схема была такая: один порт UC-8112 шлет запросы, второй порт слушает: cat /dev/ttyUSB0 | xxd И UPort1130 тоже пытается слушать - но у него загорается одновременно Tx и Rx и линия садится, кто-то делает подтяжку ее к логической 1-це видимо. Надо по традиции собрать тестовое ПО которым можно поделиться и на котором воспроизводиться эта проблема. Или если есть какое-нибудь консольное тестовое ПО - поделитесь. .
  15. Доброго времени суток, сегодня наткнулся на странную проблему работы со встроенными tty на UC-8112-lx (ttyM1, ttyM0) Если вкратце: есть три устройства: С 1-го пакет ответа 138 байт, они принимается хорошо Со 2-го пакет ответа 3 байта, должно быть 0 2 96 приходит 0 32 249 С третьего ответ тоже 3 байта вообще не приходит kversion: UC-8112-LX version 3.4 Build 20101418 порты в нужном режиме: setinterface ttyM0 -> Current uart mode is RS485-2W interface. setinterface ttyM1 -> Current uart mode is RS485-2W interface. Проверил другие прошивки с ресурса: https://moxa.ru/shop/comp/risc/uc8100/uc-8112-lx/ на версиях 2.1, 3.2 ошибка та же НО если подключить к USB порту UPort-1130 и через него опрашивать - все работает корректно. В /etc есть moxa-config, там moxa-uart-control.json -> /etc/moxa-configs/UC-81X2-LX_old/configs/moxa-uart-control.json. Если ставить симилинк на moxa-uart-control.json -> /etc/moxa-configs/UC-81X2-LX/configs/moxa-uart-control.json USRT неверное конфигшурируется и не работает вообще Подскажите куда дальше смотреть и чего еще попробовать. P.S. до этого работал с UC-2100 - с ним таких проблем не было.
  16. Хороший вопрос, повелитель - давно не имел проблем с драйверами прям года так с 2015-2016. А в то время я драйвера с форума брал на сайте moxa были старые драйвера. Поэтому ответ - привычка. - Но теперь буду знать
  17. Отсутствие информации легко объяснить тем, что подавляющее большинство скад написаны под винду и там другой драйвер.
  18. Решение 4-й проблемы, (так себе вариант): Запретить загрузку ti_usb_3410_5052 Делается довольно просто - указанный модуль помещается в черный список Я сделал так в каталог /etc/modprobe.d добавил файл blacklist-moxa.conf Со следущим содержанием: По другому строку Можно добавить в любой другой файл начинающийся с blacklist.... Выдернуть переходник и выгрузить модули: Вставить обратно упорт и убедится в отсутствии лишнего модуля Все. Но нет теперь модуль ti_usb_3410_5052 никогда не будет загружен даже если будет нужен, что не совсем хорошо. Чтобы этого избежать нужно удалить алиасы из modprobe.alias который храниться в /lib/modules/5.4.0-33-generic Но просто удаление не поможет - тут нужно драйвер (ядерный модуль) отвязать от устройства, а это я не знаю как. Возможно пока не знаю
  19. 4-я ошибка уже не связанная с драйвером от мохи, а возникшая из-за левого левого драйвера загруженного самой убунтой при подключении UPort: Зовут героя так: ti_usb_3410_5052 Как ранее писали где-то в ветках про эти UPortы - необходимо выгрузить ядерный модуль rmmod ti_usb_3410_5052 Но грабли в том, что при повторном подключении переходника грузятся сразу два драйвера
  20. 3-я ошибка сборки (уже позабористей): ошибка в Makefile Нет четкой подсказаньки как раньше как быть, но гугл нам дает решение: https://askubuntu.com/questions/232840/my-makefile-results-in-no-rule-to-make-target-arch-x86-tools-relocs-c-needed Cook reciрe: Заходим в ./mxu11x0/driver и правим Makefile (48 строку или около того): Нужно: $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules Заменить на: $(MAKE) -C $(KDIR) M=$(PWD) modules Profit - драйвер собрался загрузился
  21. Здрасте коллеги. Я думаю админы перенесут этоту ветку куда надо я не придумал где ей будет лучше - Это манул по решению проблемы из названия топика Итaк есть Ubuntu 20.04 И драйвер driv_linux_uport1p_v1.3.21_build_17112717.tgz скачаный с этого форума Проблема: не собирасется. Трабшутинг: 1-я ошибка сборки: flex: not found Решение: apt install flex
  22. Здрасте коллеги, оговорюсь сразу - ниже это мой опыт, статистика компании Moxa может отличаться. Мотивация к написанию поста - смотрю люди тоже мучаются с зависанием npreal & nport 5xxx - для меня это пройденный этап - решение найдено, глюк мохи побежден. Итого, имею три объекта, запускались в разные года 2016, 2017, 2019 на двух (года пуска: 2016, 2017) стоят по одной штуке MOXA NPort 6650-32 48V, а на третьем (2019) стоят 4 штуки MOXA NPort 5450I, чтобы набрать те же 32 порта. Если интересно, используются в системах мониторинга (СТД-МПК) для съема телеметрии на станциях Салым Св.ж.д., Островной Св.жд. и Кинель Кб.ж.д. соответственно. Возникшая проблема. - Там где стоят NPort-6000 серии все работает четко и нет проблем - порты не подвисают. А на 5000 серии зависают с рандомным интервалом от 5 минут до часа. Драйвер npreal один и тот же на всех трех объектах, и софт и хард для коммуникации с которым используются NPort так же одинаков. Питание всех четко по номиналу: 48V так 52V, 24V так 28V :). Т.е условия работы идентичны, Перепрошивка одного NPort 5450 на последнюю на август 2019 года прошивку - эффекта не принесла. Симпомы болезни: прекращается опрос датчиков телеметрии, исследования показали, что провалившись в системный вызов tcdrain (tcdrain(): waits until all output written to the object referred to by fd has been transmitted) из него уже не возвращаемся никогда. Если учесть, что нужно подтверждение передачи всего буфера - проблема явно в драйвере, но это противоречит устойчиво работающим NPortам 6ххх серии. Вобщем, есть гемор, надо решать его, а не исследовать проблему в коммуникации ядерного модуля и удаленного девайса по tcp (вангую: проблема в tcp - udp на мой взгляд в режимах потоковой передачи данных лучше работает - т.к. потеря одного пакета не критична по сравнению с таймингами tcp). Решение оказалось простое в моей архитектуре: на работу с каждым последовательным портом выделена отдельная нить (pthread), поэтому ее останов не влияет на работу системы в целом она прогрессирует хоть и менее эффективно. Поэтому решение очевидно: отловить момент останова нити опроса модулей и закрыть и открыть порт. Видимо вызову close плевать на подвисший tcdrain, а ядерный npreal в этом случае закрывает tcp соединение. А потом по новой open и пока снова не повисним. В общем уже скоро будет год как этот костыль работает, и никто больше не помнит об этой проблеме. Акромя логов куда валяться варнинги о перезапуске опроса модулей телеметрии. Если это вам поможет - значит не зря писал - всем удачи.
×
×
  • Create New...