Подключение ТРМ202 по RS-485 к компьютеру и общение с ним по COM-порту.

[Teijo]

Здравствуйте дорогие коллеги.
Подскажите, пожалуйста. Хочу разобраться и научится с данной темой.
Стоит задача подключить ТРМ202 к компьютеру и в дальнейшем управлять с него написанной программой для данного терморегулятора.
Для подключения ТРМ202 был приобретен конвертор АС4-М, чтобы преобразовать сигнал RS-485 в USB.
С официального сайта был скачен драйвер для АС4-М и конфигуратор для ТРМ202. Всё работает.
Для начала на языке СИ была написана программа для работы COM-порта и ТРМ202.
В ходе отправки пакетов данных(например, 00 01 00 05 00 01 EC 1A) по modbus RTU или ascii судя по всему АС4 воспринимал данные, но не отправлял на ТРМ202. Ради спортивного интереса, подключил TPM к ардуино. Ардуино общалась по UART, получала ответ с той же хеш суммой, но само содержимое DATA(PDU) искривлено на два бита 0b11xxxxxx, а не как в спецификации modbus при ошибке на 0b1xxxxxxx. Значит она работает.
Вопрос, почему моя программа не может отправляет через АС4 пакет данных на ТРМ, но конфигуратор Овна работает?

[kondor3000]

Конфигуратор работает по протоколу Овен, для работы по Модбас RTU нужна перезагрузка по питанию. Одновременно работать не будет. Так же надо проверить последовательность байт и регистров.

Проверить обмен с ТРМ по Модбас, можно любым ОРС сервером. https://owen.ru/catalog/opc_serveri
Проверить настройки, функции обмена и адреса регистров, последовательность байт и регистров.

[EFrol]

В РЭ на ТРМ202 сказано, что протокол надо указать в настройках:


и что означает пакет 00 01 00 05 00 01 EC 1A?
Допустимый адрес Modbus 1..247, а допустимые функции:

Вашу команду ТРМ202 скорее всего не понимает?

[FPavel]

Ещё добавлю, что подключение через USB не всегда устойчиво для длительного соединения.
Сам не проверял, но на форуме были сообщения о прерывании.

Т.е. связке с компьютером лучше не доверять.

Если требуется какое-то двухпозизионное управление и обработка датчика - я бы склонялся в сторону программируемых устройств, типа ПР или ПЛК, и тем самым, исключил бы лишний ТРМ.
Сразу примите к сведению, что ПР работают с термосопротивлениями по 2-проводной схеме, т.е. требуются высокоомные датчики (Pt1000, NTC и прочие из диапазона 1000-4000 Ом), и погрешность будет 1-5 гр.С (в зависимости от температуры проводов).
Из ПР лично мне импонируют ПР205 и ПР225, но они дорогие.

Если хотите ограничиться Arduino по материальным соображениям и целесообразности - встречал для них шилды работы с датчиками и с реле. Наверное, есть смысл обратить внимание на них.

[FPavel]

Ардуино общалась по UART, получала ответ с той же хеш суммой, но само содержимое DATA(PDU) искривлено на два бита 0b11xxxxxx, а не как в спецификации modbus при ошибке на 0b1xxxxxxx. Значит она работает.
Вопрос, почему моя программа не может отправляет через АС4 пакет данных на ТРМ, но конфигуратор Овна работает?

У ТРМ нет UART, есть только RS-485. Различия в физической форме сигнала. Они на физическом уровне несовместимы.

А ошибку в программе легче найти сниффером/логгером COM порта - посмотреть реальную отправку и приём. А в длинной простыне кода копаться нет желания.

[kondor3000]

Ещё добавлю, что подключение через USB не всегда устойчиво для длительного соединения.
Сам не проверял, но на форуме были сообщения о прерывании.

Не путайте соединение ПР по USB на длинном кабеле (для программирования и онлайн отладки) и
переходник USB-RS485 (для обмена).
Переходник типа АС4 может работать сутками без выключения

[FPavel]

Читал о неустойчивости соединения по USB
https://owen.ru/forum/showthread.php...b58sq418866208
это не единственная тема - были и другие, там соединение "отваливалось" от перехода компьютера в "сон" - найти быстро не смог.

поэтому никогда и не пытался повторить соединение, в котором есть сомнения.

Если у Вас личный опыт говорит о нормальном длительном соединении (24/7 месяц+) - значит хорошо и я признаю ошибочность своего совета.

[melky]

А у вас во сне идёт какая-то работа программ на ПК?
Чего бы не отвалиться то

[FPavel]

После "пробуждения" соединение не восстанавливалось.

Но, если в новых операционках этой проблемы больше нет, а соединение работает 24/7 по многу дней - это просто чудесно.

Я противник управления простыми приборами (типа ТРМ) от компьютера, т.к. при обрыве соединения ТРМ не переключится в безопасное состояние.
На мой взгляд, автоматика должна быть самодостаточной, а компьютер использоваться для визуализации, изменения параметров, режимов (влиять, но не управлять). Поэтому и предложил дальше ПР и ПЛК, а для ПР пояснил некоторые ограничения измерений, чтобы потом вопросов не было.
Явно же видно, что автор темы - очередной самоделкин без профильного системного образования.

[melky]

FPavel ну, ваши желания это одно, а реальность другое. Сейчас тенденции в сторону виртуальных ПЛК, другой вопрос, что они должны быть на ОС реального времени. Впрочем возьмите тот же ПЛК200 - это оно и есть... там linux на борту.