Тс 90к корректор руководство по эксплуатации

ЭЛЬСТЕР ГАЗЭЛЕКТРОНИКА

Записей ещё нет — вы станете первым.

Записей ещё нет — вы станете первым.

Всем доброго времени суток.

Я не знал в какой раздел обратиться, решил что этот будет более подходящим.

У меня имеется газовый корректор «TC — 90/K». У него имеется интерфейс RS232 через 6 PIN DIN 45322, к устройству прилагается родное программное обеспечение Win PADS. Оно прекрасно работает и устройство с помощью родной программы прекрасно читается. Но меня интересует вопрос написания своего арограммного обеспечения для чтения данного устройства. К данному устроству имеется документация в которой описан протокол опроса, я испробовал всё что там описано, но устройство либо молчит, либо отвечает мне b’00’.

Прошу помощи понять как(или скорей какой) правильно отправить запрос корректору что бы он выдал мне информацию хранимую в себе. Скрипт для опроса его я сделал на языке python. С другими устройствами скрипт прекрасно общается как через com порт, так и через сеть. Я обычно меняю только запрос или вариант подключеия.

Документацию к устройству прилагаю.

pelathaon писал(а): ↑15 сен 2020, 21:22
Его запросы описаны в документации, по факту он шлет запрос «L4=.», я уже его перехватил и точно такой же отправил ему. В ответ не получил ничего. Скорее всего это особенности опроса по RS232, там задесйтвованы CTS и RTS. Скорее всего их надо как-то правильно использовать.

значит Ваш запрос не точно такой же. Только и всего.
Отличия могут быть не только в данных, но и в таймингах и в физике. Например контроль передачи по CTS/RTS/DTR, ни один сниффер этого не покажет, нужен терминал с отображением их не просто лампочками, а на диаграмме общего потока данных.

В кабеле связи оторвите все провода, кроме Tx, Rх и GND, даже если там перемычки (их тоже убрать). Если родной софт без них продолжит общаться с прибором — значит дело не в этом.

Jackson писал(а): ↑15 сен 2020, 22:57
В кабеле связи оторвите все провода, кроме Tx, Rх и GND, даже если там перемычки (их тоже убрать). Если родной софт без них продолжит общаться с прибором — значит дело не в этом.

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

Jackson писал(а): ↑15 сен 2020, 22:57
значит Ваш запрос не точно такой же. Только и всего.

Я опирался на то, что в ПО «Serial Port Monitor Free» у меня запрос полностью совпадал с тем, что посылал родной софт.

Jackson писал(а): ↑15 сен 2020, 22:57
Отличия могут быть не только в данных, но и в таймингах и в физике. Например контроль передачи по CTS/RTS/DTR, ни один сниффер этого не покажет, нужен терминал с отображением их не просто лампочками, а на диаграмме общего потока данных.

Скорее всего еще нужны определенные тайминги запроса и приема ответа, это я тоже допускаю. Но я не знаю как это выяснить, к сожалению.
Не могли бы подсказать название такого ПО которым я могу подсмотреть как же все таки происходит обмен?

pelathaon писал(а): ↑16 сен 2020, 01:13
у меня запрос полностью совпадал с тем, что посылал родной софт.

ну как же он совпадал, если Вы выше пишете что там аппаратный контроль трафика (об этом говорит необходимость перемычек). Теперь надо сходить в настройки порта в виндовсе и посмотреть, что стоит там — там установить контроль трафика «отсутствует» и снова проверить связь только с тремя проводами Rx Tx GND. Если и на этот раз для связи понадобится установить перемычки, а без них никак — значит родной софт это (аппаратный контроль через прямой доступ к порту) и делает и анализирует CTS/RTS/DTR и это зачем-то ему очень надо. Вот и первое возможное отличие.
Второе возможное отличие — это тайминги. Надо посмотреть, с какой задержкой уходит каждый байт в провода, это не сниффером делается, а другим COM-портом. Есть вероятность что буфер в UARTе вмешивается и вы шлёте данные через него, а родной софт, получив прямой доступ к порту, этот буфер не использует. Если первая проверка окажется положительной (перемычки нужны при отключённом контрой траффика в виндовсе), то скорее всего так и есть.

Поздний вопрос: а протокол-то какой? Какой-то свой или там модбас? Может Вы CRC забыли или считаете её некорректно?

Отправлено спустя 3 минуты 50 секунд:

pelathaon писал(а): ↑16 сен 2020, 01:13
Скорее всего еще нужны определенные тайминги запроса и приема ответа, это я тоже допускаю. Но я не знаю как это выяснить, к сожалению.

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

Я исхожу из того, что раз на родной софт прибор отвечает, а на Ваш софт — нет — значит есть разница, просто Вы её ещё не нашли. Чудес-то не бывает.

Как-то лично столкнулся с тем что кривой драйвер (в смысле чип) UARTа определённые байты воспринимал как собственные команды и просто глотал их из запроса, они исчезали, а CRC оставалась неизменной, соответственно приёмник считал посылку ошибочной потому что CRC посылке уже не соответствовала, и просто игнорировал и не отвечал.

Это удалось выяснить только прослушав саму физическую линию на стороне приемника и последующего ручного анализа трафика: в логе трафика передатчика находили запросы без ответов, затем искали эти запросы в логе трафика со стороны приемника.

И пока не ткнули носом производителя передатчика (а не приемника) в это — он естественно считал что мы ему сказки рассказываем, да мы и сами не считали это возможным пока не увидели.

В общем, не ленитесь и проверяйте абсолютно всё. Если и не найдёте, то как минимум солидно поднимете свои познания и квалификацию.

pelathaon писал(а): ↑16 сен 2020, 01:13
Не могли бы подсказать название такого ПО которым я могу подсмотреть как же все таки происходит обмен?

ComRead от SoftElectro

Всем спасибо за ответы, всё получилось все прекрасно. Теперь интересует вопрос устройства которое позволит передавать всё это по сети передачи данных. В руках был planet ICS-100 с поддержкой RS232/RS485 но через него не заработало, хотя в принципе должно было т.к. он поддерживает все необходимые параметры.

Может кто-то посоветует простое и недорогое устройство которое позволит работать с корректором через сеть передачи данных?

Sokolov_Dmitry писал(а): ↑19 сен 2020, 12:29
если у вас проблема была только в посылаемых в корректор байтах, а не в паузах, rts/cts или еще в чем-то хитром (с чем простой преобразователь Eth/rs232 может не справиться), то например er108 от teleofice . Если нужно по беспроводным сетям — promodem.ru.

Проблема в RTS/CTS, по спецификации ICS-100 это дело умеет. Однако, не работает почему-то. Может через преобразователи нужно каки-то особым способом опрос делать?

pelathaon писал(а): ↑25 сен 2020, 09:38
Проблема в RTS/CTS, по спецификации ICS-100 это дело умеет. Однако, не работает почему-то. Может через преобразователи нужно каки-то особым способом опрос делать?

Не исключено. Если, как Евгений выше писал, драйвер управляет линиями CTS/RTS, то с преобразователем и тем что у него в мозгах можно разбираться долго. По мне бы проще было свой сделать на Raspberry или чем подобном, чем пытаться чужое творение заставить работать так как мне надо.

Но, есть еще момент: у Вас, если я верно понял, корректор с батарейным питанием. Да на последовательном интерфейсе еще и оптосоединитель нарисован.
Очень похоже на то, что прибор (или непосредственно оптосоединитель) не умеет формировать уровни для RS-232. И просто коммутирует оптопарой на rx компьютера напряжение с какой-то другой ноги его же порта. Достаточно часто встречающаяся схема. Кстати, штатные оптопорты практически всех счетчиков работают точно по тому же принципу, только в одном случае оптопара впаяна в плату, а в другом она образуется при поднесении головки ку прибору. Часто для этого используется сигнал DTR, но возможны варианты. И в этом случае, как опрос не реализуй, если в преобразователе на эту ногу ничего не подается — поможет только паяльник.
Крайний раз сталкивался с этим для опроса через родной кабель с опторазвязкой теплосчетчика от Kamstrup посредством Adam4520. Пришлось вскрыть Adam, найти внутри него развязывающий DC-DC преобразователь и от него кинуть перемычку на какую-то (сейчас уже не вспомню) ногу 232-го порта. Тогда заработало, но гарантия на adam, естественно, слетела. Хотя, вроде работает до сих пор.
Попробуйте найти схему родного кабеля и проверить, все ли используемые в кабеле провода задействованы в ICS-100. Можно цешкой, RS-232 не предусматривает в нормальном состоянии нулевых напряжений.

Sokolov_Dmitry писал(а): ↑25 сен 2020, 13:07
Подается ли питание при использовании ic-100 (при отключенном от корректора кабеле тестером измерить на контактах 1-6) ?

Подается, 4.2 вольта.

Никита писал(а): ↑25 сен 2020, 10:36
Но, есть еще момент: у Вас, если я верно понял, корректор с батарейным питанием. Да на последовательном интерфейсе еще и оптосоединитель нарисован.

Да, там внутри батарейка на 3.6V, 2700mah

Никита писал(а): ↑25 сен 2020, 10:36
По мне бы проще было свой сделать на Raspberry или чем подобном

К сожалению, нужно именно готовое решение.
Я еще раз перечитал внимательно технические спецификации ICS-100, и кажется я нашел проблему. Скриншот приложил.

Выше мне накидали названий приборов которые я просил, но они не подходят в виду своей высокой цены, поэтому может кто-то подскажет максимально недорогое решение?

pelathaon писал(а): ↑30 сен 2020, 08:06
Подается, 4.2 вольта.

Подозрительно мало. При подключении от того, с чем заведомо работает (от компа или чего подобного) там сколько?
Что на других ногах порта ICS-100? Относительно 5-го вывода?
Режим порта в ics, надеюсь, верно установлен, rs-232.
Осциллографом нет возможности глянуть Rx и Tx при попытках обмена?
Что касается управления потоком — если это делается аппаратно, то никакой пареобразователь тут, скорее всего, не заработает. Потому как прямое управление RTS/CTS делается на уровне API Windows, и само собой, по линии связи не передается. Т.е. как только Вы переходите с RS-232 на что-то другое — эти линии физически обрываются.

Совет

Jackson писал(а): ↑15 сен 2020, 22:57
В кабеле связи оторвите все провода, кроме Tx, Rх и GND, даже если там перемычки (их тоже убрать). Если родной софт без них продолжит общаться с прибором — значит дело не в этом.

скорее всего не сработает, прибор вообще потеряет питание. Но вот поотрывать все, что не нужно, кроме этих 4,2В (придется вызвонить, откуда эти провода приходят) можно попробовать. Т.е. на заведомо работающей схеме соорудить «удлинитель» RS-232 «мама-папа», оставив только Rx, Tx, GND и ту линию, откуда берутся эти 4,2В.

В общем, судя по няпряжению, у Вас в ICS нестандартные уровни используются. И это не классический 232, а TTL. Замерьте, если есть возможность, что на Rx-Tx относительно пятой ноги COM-порта.

А про скрипт пока можно забыть — проблема похоже аппаратная. Если с родным софтом все заработает через ICS, то можно уже и свой опрос писать.

Никита писал(а): ↑30 сен 2020, 09:42
скорее всего не сработает

Пока не проверено — всё остальное пустое, видимо. Но автор похоже либо решил проблему либо не решил — нам в любом случае не рассказал.

Jackson писал(а): ↑30 сен 2020, 10:15
Но автор похоже либо решил проблему либо не решил — нам в любом случае не рассказал.

Судя по тому, что подыскивает недорогое решение — не решил.
Но в любом случае, на мой косой взгляд, проблема не локализована — проблема может быть либо в уровнях, либо в управлении потоком. И это требует разных подходом. Проблема с аппаратным управлением потоком при управлении линиями RTS/CTS средствами драйвера исключает применение любого преобразователя интерфейсов в принципе. А вот если проблема с другой стороны — корректор не успевает за компом и пытается опустить CTS — шансы есть, возможно удастся подобрать преобразователь, который умеет это корректно обрабатывать. А может иметь место и сочетание. Вот схему кабеля бы увидеть…