UC-8112-LX ttyM0, ttyM1 принимают некорректные данные

[boris_r_v]

Доброго времени суток, сегодня наткнулся на странную проблему работы со встроенными 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 - с ним таких проблем не было.

 

 

 

[Знайка]

Добрый день. Для начала есть предложение параллельно подключить UPort 1130 и посмотреть, какие данные (в HEX) будут приниматься на нём и на UC-8112. И сравним.

[boris_r_v]

Пробовал.

Схема была такая: один порт UC-8112 шлет запросы, второй порт слушает: cat /dev/ttyUSB0 | xxd

И UPort1130 тоже пытается слушать - но у него загорается одновременно Tx и Rx и линия садится, кто-то делает подтяжку ее к логической 1-це видимо.

Надо по традиции собрать тестовое ПО которым можно поделиться и на котором воспроизводиться эта проблема.

Или если есть какое-нибудь консольное тестовое ПО - поделитесь.

 

 .

 

[Знайка]

Я думаю, что проблема тут все таки не в ПО. Ну и описываемое поведение при подключении UPort ненормально. Попробуйте собрать внешнюю подтяжку?

[boris_r_v]

Ну из меня такой себе схемотехник, как сделать внешнюю подтяжку нужно еще уметь .

Проблема в аппаратной части контроллера, потому как сейчас идут пусконаладочные работы по одному объекту где применяется UC-8112-ME-LX с версией 3.0.

И там та же проблема, не работают опрос модулей автоматики, завезли туда с другого объекта UC-21xx, тот же deb пакет и на UC-21xx опрос модулей автоматики работает.

 

[boris_r_v]

Получилось локализовать проблему.

Для этого из боевого софта был выкушен кусок кода которые отвечает за работу с ком-портами и на его основе сделан имитатор подчиненного устройства (slave). Был поставлен экперимен: на одном ком-порту UC8112-lx был запущен софт который опрашивает устройство, на втором ком-порту UC8112 был запущен имитатор. Комп порты в режиме RS-485-2W, обвязаны 2-х проводной линией к которой подключено опрашиваемое устройство. Когда работа имитатор физическое устройство выключалось, когда работало устройство - выключался имитатора, во избежание коллизий. 

Пакет запроса - 11 байт, ответа - 3 байта, скорость 19200.

Результат эксперимента: ответы имитатора принимаются, ответы устройства нет.

Почему видно из приведенных ниже осcцилограмм:

1.  имитатор начинает отвечать через 4мс, после окончания ответа (файл: имитатор_2.jpg);
2. устройство начинает отвечать через 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)

 

[Знайка]

Ну да. Большое вам спасибо за проделанную работу. Да, скорее всего это именно проблема со переключением передача/приём. Но тут возникает тонкий момент. Если мы будем отталкиваться от стандарта Modbus, как наиболее распространённого протокола для этих дел, то slave таки обязан выдерживать паузу в 3,5 символа перед началом ответа. На 19200 эта пауза составит ~ 0,73 мс. А ещё в стандарте отдельно есть оговорка, что для скоростей выше 19200 рекомендуется использовать паузу не менее 1,5 мс. И требование использовать 2х таймеры (то есть 7 символов). А если не смотреть на Modbus, то на что тогда смотреть в современном мире, где каждый производитель производит как ему вздумается? Что скажете?

ПС. Немного подредактировал, т.к. сначала неверно написал.

[boris_r_v]

 А что тут скажешь, паузы формально описаны только в Modbus, в данном случае не модбас, поэтому формальных ограничений нет.  Поэтому мы можешь оперировать только субьективными трактовками. Хотя ограничения на паузы в стандарте модбас тоже появились не просто так ...

На стороне опрашиваемых железок, кода который бы считал эту паузу и строго по прерыванию от таймера выдерживал нету. Добавить можно, но что делать с уже поставленными образцами, т.е. есть тяжелый легаси, правка которого экономически нецелесообразна, т.к. есть UC21xx который не имеет такой проблемы, его минус - это форм фактор. Это я к и тому, что есть альтернатива опять же от компании Moxa  Поэтому если все так и останется в принципе ничего страшного, UC8112-lx мы купили всего два, и заменить их на UC21xx не стоит огромных денег, а эти отправятся на склад на хранение в ожидании подходящего проекта.

Далее ряд замеченных странностей, которые оставляют надежду на решение проблемы:

1. Хорошо бы понять это на время переключения, или что-то иное т.к. на тестовм столе было два однотипных устройства, и картинки которые были ранее - это с того с которого данные не приходят, но был еще один с которого приходили, но не корректные, причем если паралельно читать пакеты из другого tty через python - то там данные приходят верные. Походит на проблему в моем софте, НО есть еще одна странность.
2. Есть еще одно устройство другого типа (назовем его УНС), у которого ответ порядка 140байт, а не 3 как у ранее рассмотренных и оно опрашивается без проблем. 
3.  При этом интервал между окончанием запроса и началом ответа на УНС: 80мкс - первая картинка, приложенная к данному посту, вторая - тот же запрос и ответ с большей ценой деления по оси времени. 

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

Поэтому прошу донести эту информацию до разработчика может еще раз заглянут в код tty-драйвера.

Сейчас можно сказать, что комбинация: короткий ответ и малый интервал - не работает, а длинный ответ и малый интервал - работает.

 

[Знайка]

Да, разумеется Modbus я привёл для примера. Он потому на мой взгляд и популярен, что обычно работает. Но у нас как всегда принято идти своим путём, зачем нам проверенные решения По большей части я написал это для того, что бы вы не расстроились, если разработчик даст схожий ответ. Но ситуация с длинным ответом интересная, да, такого пока не видел, напишу, как что прояснится - сообщу.

[Знайка]

И поясните мне ещё по осциллограммам с УНС: вы осциллограф по другому включили, так? Или почему запрос отображается в инвертированном виде?

[Знайка]

Ещё хотел бы сразу уточнить какими битами, включая стартовый, начинаются короткий и длинный ответы? По осциллограммам?

[boris_r_v]

Да на двух последних осцилограммах полярность обратная по сравнению с первыми двумя.

Слова которыми обмениваемся:

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-х, когда интернет был редким и дорогим зверем.

 

 

[Знайка]

Вы писали: Со 2-го пакет ответа 3 байта, должно быть 0 2 96 приходит 0 32 249 . Верный ответ, я так понимаю, приведён в HEX, а фактический в чём?

[boris_r_v]

On 12/17/2020 at 7:50 PM, boris_r_v said:

Со 2-го пакет ответа 3 байта, должно быть 0 2 96 приходит 0 32 249

Согласен тут не совсем корректно: "0 2 96" должно быть написано 0х0 0х2 0х96 - тогда б не было путаницы

Ожидаемый ответ 0х00 адрес 0х96 (0х96 - это константа)

 

[Знайка]

Я про 0 32 249 имел в виду - это в чём?

[Знайка]

И ещё :
#kversion -a
#uname -a
И SN с обеих UC-8112, с которыми проблема. Поведение ведь не зависит от используемого порта, верно?

 

 

[boris_r_v]

On 12/29/2020 at 4:21 PM, Знайка said:

Я про 0 32 249 имел в виду - это в чём?

Это в dec

[boris_r_v]

On 12/30/2020 at 12:07 PM, Знайка said:

И ещё :
#kversion -a
#uname -a
И SN с обеих UC-8112, с которыми проблема. Поведение ведь не зависит от используемого порта, верно?

 

 

Первый:  это тот на котором эксперименты проводятся:

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
 

 

 

 

[Знайка]

On 1/7/2021 at 12:27 PM, boris_r_v said:

Это в dec

То есть получается, что неверно принимается только 3тий байт, первые 2 принимаются верно?

[boris_r_v]

1 hour ago, Знайка said:

То есть получается, что неверно принимается только 3тий байт, первые 2 принимаются верно?

С конкретно этого устройства должно быть 0х00 0x02 0x96 приходит 0x00 0x20 0xF9 (в десятичной форме 0 32 249), т.е. верно принимается только стартовый бит.

С другого подобного устройства не принимается ничего.  принимается 0х0 0х96 - когда ожидали 0х0 0хFF 0х96, т.е. не приняли второй байт

[boris_r_v]

Наметился прогресс: 

1. на переходнике UPort-1130, контроллерах Moxa W321, UC-2110 - прием устойчиво работает когда выставлено 2 стоп бита ( как устройства и отправляют)
2. на переходнике UPort-1130 прием также работает когда выстален один стоп бит, контроллеров w321 uc2110  нет под рукой - проверит не могу
3. а вот на uc-8112 - прием заработал только при одном стоповом бите (и длинного и короткого ответов), когда ставлю два стоповых бита - происходит некорректный прием короткого ответа, и корректный прием длинного.

Опрашивал реальные устройства которые по документации (и по исходникам софта который с ними работает с прошлого века) настроены на отправку двух стоповых битов.

[Знайка]

Интересное наблюдение. То есть с 1 стоповым битом короткий ответ всегда принимается верно? Независимо от того, есть в линии ещё устройства (тот же UPort 1130) или нет?

[boris_r_v]

1 hour ago, Знайка said:

Интересное наблюдение. То есть с 1 стоповым битом короткий ответ всегда принимается верно? Независимо от того, есть в линии ещё устройства (тот же UPort 1130) или нет?

Да когда поставил 1 стоп бит все за отвечало, устройства друг другу не мешают работать, отвечают штатно все 3 (два коротким ответом, один длинным).

Но все еще интересней:

1. Девайсы у которых короткий ответ не имеют в своей прошивке для PIC16F873A указания количества стоповых битов, там по-умолчанию один стоп бит, второй добавляли руками и для этого устройства это не сделано, т.е. стоп бит один. Поэтому логично, что UC-8112 не может корректно вычитать ответ, когда ожидает 2 стоп бита, т.к. неверная настройка ком-порта: на мастере 2 стоп бита, на slave 1 стоп бит. Тут чуда не случилось, все стало ясно.
2. Устройства с коротким ответом, конвертеру UPort1130, контроллерам W321, UC-2110 и PCI-платам Moxa CP-132, CP-114 отвечают хорошо при 2-х стоповых битах настройки  мастера, хотя на устройстве 1 стоп бит. Почему при неверной настройке работает стоповых битов все работает? - драйвера устройств по-любому причастны
3. Далее: девайс у которого длинный ответ, имеет настройку в прошивке на 2 стоповых бита и с ним прием штатный на UPort1130 и UC8112, не зависимо от того сколько стоп битов ожидает мой софт хоть 1 хоть 2, а в легаси-софте везде и всегда 2 стоповых. Почему UC8112 настроенный на 1 стоповый бит успешно принимает длинный ответ с двумя стоповыми битами?
4. Итог: для ответа в 3 байта (короткий ответ) нужно чтобы на UC8112 было верно указано кол-во стоп битов, на остальных устройствах не важно, а для длинного ответа (порядка 130 байт) настройка кол-ва стоп битов не важна на всех устройствах.

Т.е. мое виденье, что ранее во всех устройствах моха были послабления на количество стоповых битов в принимаемых пакетах (как это сделать не знаю), а в UC8112 их убрали и прием коротких ответов на нем логично сломался (не совпали стоп биты). Тут налицо наличие технического долга в софте мастера, т.е. проблема на моей стороне, а не на стороне Moxa. Но почему длинный ответ хорошо принимается на UC8112 с 1 стоп-битом?

И коль уж так углубились в дебри, как-то можно выяснить в чем отличия в драйверах ком-портов в части работы со стоповыми битами между рядом устройств: UPort1130, W321, UC2110, CP132. CP114 и контроллером UC8112?

Просто если в UC8112 инженеры Моха подчистили свой технический долг и это исправление будет тиражироваться на остальные устройства, конкретно меня и моих коллег ждут тяжелые времена ...

Тут везде используются linux драйвера, коллега проверит на windows подскажет.

[Знайка]

10 minutes ago, boris_r_v said:

Да когда поставил 1 стоп бит все за отвечало, устройства друг другу не мешают работать, отвечают штатно все 3 (два коротким ответом, один длинным).

Но все еще интересней:

1. Девайсы у которых короткий ответ не имеют в своей прошивке для PIC16F873A указания количества стоповых битов, там по-умолчанию один стоп бит, второй добавляли руками и для этого устройства это не сделано, т.е. стоп бит один. Поэтому логично, что UC-8112 не может корректно вычитать ответ, когда ожидает 2 стоп бита, т.к. неверная настройка ком-порта: на мастере 2 стоп бита, на slave 1 стоп бит. Тут чуда не случилось, все стало ясно.
2. Устройства с коротким ответом, конвертеру UPort1130, контроллерам W321, UC-2110 и PCI-платам Moxa CP-132, CP-114 отвечают хорошо при 2-х стоповых битах настройки  мастера, хотя на устройстве 1 стоп бит. Почему при неверной настройке работает стоповых битов все работает? - драйвера устройств по-любому причастны
3. Далее: девайс у которого длинный ответ, имеет настройку в прошивке на 2 стоповых бита и с ним прием штатный на UPort1130 и UC8112, не зависимо от того сколько стоп битов ожидает мой софт хоть 1 хоть 2, а в легаси-софте везде и всегда 2 стоповых. Почему UC8112 настроенный на 1 стоповый бит успешно принимает длинный ответ с двумя стоповыми битами?
4. Итог: для ответа в 3 байта (короткий ответ) нужно чтобы на UC8112 было верно указано кол-во стоп битов, на остальных устройствах не важно, а для длинного ответа (порядка 130 байт) настройка кол-ва стоп битов не важна на всех устройствах.

Т.е. мое виденье, что ранее во всех устройствах моха были послабления на количество стоповых битов в принимаемых пакетах (как это сделать не знаю), а в UC8112 их убрали и прием коротких ответов на нем логично сломался (не совпали стоп биты). Тут налицо наличие технического долга в софте мастера, т.е. проблема на моей стороне, а не на стороне Moxa. Но почему длинный ответ хорошо принимается на UC8112 с 1 стоп-битом?

И коль уж так углубились в дебри, как-то можно выяснить в чем отличия в драйверах ком-портов в части работы со стоповыми битами между рядом устройств: UPort1130, W321, UC2110, CP132. CP114 и контроллером UC8112?

Просто если в UC8112 инженеры Моха подчистили свой технический долг и это исправление будет тиражироваться на остальные устройства, конкретно меня и моих коллег ждут тяжелые времена ...

Тут везде используются linux драйвера, коллега проверит на windows подскажет.

Глубоко копаете Естественно, что драйвера (если вы про программную часть) никакие стоп-биты не считают. Этим занимается драйвер интерфейса (микросхема). А дальше уж как в ней зашито -  она может проверять наличие (точнее значение) второго стоп бита (ранние реализации) или не проверять (современные реализации), просто отсчитывая его как пустой такт. Естественно, что в такой огромной линейке продукции микросхемы используются разные. Отсюда и результат.

[boris_r_v]

24 minutes ago, Знайка said:

Глубоко копаете Естественно, что драйвера (если вы про программную часть) никакие стоп-биты не считают. Этим занимается драйвер интерфейса (микросхема). А дальше уж как в ней зашито -  она может проверять наличие (точнее значение) второго стоп бита (ранние реализации) или не проверять (современные реализации), просто отсчитывая его как пустой такт. Естественно, что в такой огромной линейке продукции микросхемы используются разные. Отсюда и результат.

Возможно, я с вами бы и согласился если не одно, но: оба контроллера UC21xx & UC81xx построены на одном и том же процессоре Armv7 Cortex-A8, (на UC8112 распаян am3352bzcza100) который имеет 6 штук UART на микросхемах TL16C550 согласно документации:

1. 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
2. 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а в разных контроллерах может приводить к тому эффекту о котором идет речь, как бы все таки выяснить есть ли отличия в драйверах у разных контроллерах?