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

boris_r_v

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

    106
  • Joined

  • Last visited

About boris_r_v

  • Birthday 06/25/1981

Контакты

  • ICQ
    170 403 684

Информация

  • Пол
    Мужчина
  • Город
    Екатеринбург
  • Интересы
    One of it is: embedded arm-device coding.

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

boris_r_v's Achievements

Повелитель коммуникационных сил

Повелитель коммуникационных сил (4/5)

0

Reputation

  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-це видимо. Надо по традиции собрать тестовое ПО которым можно поделиться и на котором воспроизводиться эта проблема. Или если есть какое-нибудь консольное тестовое ПО - поделитесь. .
×
×
  • Create New...