Pull to refresh

Comments 13

Serial - to - LAN (Moxa uPort, например) работает абсолютно прозрачно, безо всяких конвертацией и вмешательства в данные. В Windows просто появляется виртуальный порт, ничем не отличимый от железного.

У меня на одном uPort висит 8 устройств разных вендоров, каждое со своими причудами и разными протоколами, включая "типа MODBUS" вроде вашего. И все замечательно работает.

To - LAN - это nPort, uPort - это USB. Что касаемо "ничем не отличимый от железного", могут быть нюансы. У нас, например, используются Advantech EKI в связке с железкой, которая отличает адрес от данных по 9-у биту. EKI не умеет в 9-битные посылки (и nPort, кстати, тоже), поэтому используется переключение режимов четности mark/space. При этом смена режима занимает время, достаточное для того, чтобы железка, приняв адрес и не дождавшись данных, отвалилась по тайм-ауту. На "железном" порту, разумеется, все работает нормально.

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

Вот такое оно, прикладное айти в непрофильных организациях.

До мастерской мне еще далековато...
Если Вы утверждаете что в статье велосипед, то как бы Вы решили данную проблему с теми ресурсами и условиями которые описаны в статье не прибегая к велосипедам?
Я только учусь, и для меня важно выслушать аргументированное мнение сообщества, собственно по этому я и опубликовал статью

Если чудная железка принимает запрос на адрес 9 бит, а весь остальной обмен идёт по 8битному формату, то это очень странная железка.

Если же она в принципе работает по 9 битному протоколу (но вначале использует все 9 бит для определения адреса, а потом девятый это бит чётности), то ничто не мешает вам реализовать 8+1(программный бит чётности), а в первом пакете слать адрес, а в остальных добавлять к 8 битам бит чётности, используя всегда 9битный формат.

ПС. так кстати фирма энергомера работает (электросчётчики), только у них всегда 8 бит = 7+1(программно чётность) для совместимости с другим оборудованием на линии.

Чудная железка всегда использует посылку длиной 9 бит (ну и старт-стоп, естественно). Если 9-й бит в единице, то она считает младшие 8 бит адресом; если в нуле, то младшие биты считаются данными. Железок на шине может быть несколько, отвечать может только та, которая поймала свой адрес.

Соответственно, "честный" бит чётности к данным добавлять нельзя - могут возбудиться другие железки на линии, посчитав чужие данные своим адресом.

Ну а поскольку, как я уже говорил, наши адаптеры EKI не умеют в посылки с 9-битными данными, единственный способ программно управлять 9 битом - переключать режим чётности mark/space, что, внезапно, занимает время.

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

Встречался у одного из вендоров с протоколом весов с контрольной суммой, для вычисления которой был приведен код на ассемблере. Т.е. без байта с контрольной суммой весы ничего не вернут. Вес закодирован в пакете несколькими байтами.

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

Иногда "документация" такая, что без сниффера никак. Пример из нашего опыта - немецкий блок питания для магнетронного напыления. В мануале потокол гордо именуется MODBUS. Внутри ASCII-HEX с контрольной суммой, закодированной по своему алгоритму. В пакете передаются 12 параметров, и целых, и float, и битовые маски. При этом в каком формате закодирован float в мануале написать забыли. Ну хоть алгоритм контрольной суммы описали,и на том спасибо.

Sign up to leave a comment.

Articles