Просмотр полной версии : Подключение ТРМ202 по RS-485 к компьютеру и общение с ним по COM-порту.
Здравствуйте дорогие коллеги.
Подскажите, пожалуйста. Хочу разобраться и научится с данной темой.
Стоит задача подключить ТРМ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
04.07.2025, 20:14
Конфигуратор работает по протоколу Овен, для работы по Модбас RTU нужна перезагрузка по питанию. Одновременно работать не будет. Так же надо проверить последовательность байт и регистров.
Проверить обмен с ТРМ по Модбас, можно любым ОРС сервером. https://owen.ru/catalog/opc_serveri
Проверить настройки, функции обмена и адреса регистров, последовательность байт и регистров.
В РЭ (https://owen.ru/uploads/rie_trm202_1924.pdf) на ТРМ202 сказано, что протокол надо указать в настройках:
84674
84675
и что означает пакет 00 01 00 05 00 01 EC 1A?
Допустимый адрес Modbus (https://owen.ru/uploads/ki_prm_trm202_033.pdf) 1..247, а допустимые функции:
84676
Вашу команду ТРМ202 скорее всего не понимает?
Ещё добавлю, что подключение через USB не всегда устойчиво для длительного соединения.
Сам не проверял, но на форуме были сообщения о прерывании.
Т.е. связке с компьютером лучше не доверять.
Если требуется какое-то двухпозизионное управление и обработка датчика - я бы склонялся в сторону программируемых устройств, типа ПР или ПЛК, и тем самым, исключил бы лишний ТРМ.
Сразу примите к сведению, что ПР работают с термосопротивлениями по 2-проводной схеме, т.е. требуются высокоомные датчики (Pt1000, NTC и прочие из диапазона 1000-4000 Ом), и погрешность будет 1-5 гр.С (в зависимости от температуры проводов).
Из ПР лично мне импонируют ПР205 и ПР225, но они дорогие.
Если хотите ограничиться Arduino по материальным соображениям и целесообразности - встречал для них шилды работы с датчиками и с реле. Наверное, есть смысл обратить внимание на них.
Ардуино общалась по UART, получала ответ с той же хеш суммой, но само содержимое DATA(PDU) искривлено на два бита 0b11xxxxxx, а не как в спецификации modbus при ошибке на 0b1xxxxxxx. Значит она работает.
Вопрос, почему моя программа не может отправляет через АС4 пакет данных на ТРМ, но конфигуратор Овна работает?
У ТРМ нет UART, есть только RS-485. Различия в физической форме сигнала. Они на физическом уровне несовместимы.
А ошибку в программе легче найти сниффером/логгером COM порта - посмотреть реальную отправку и приём. А в длинной простыне кода копаться нет желания.
kondor3000
05.07.2025, 09:34
Ещё добавлю, что подключение через USB не всегда устойчиво для длительного соединения.
Сам не проверял, но на форуме были сообщения о прерывании.
Не путайте соединение ПР по USB на длинном кабеле (для программирования и онлайн отладки) и
переходник USB-RS485 (для обмена).
Переходник типа АС4 может работать сутками без выключения
Читал о неустойчивости соединения по USB
https://owen.ru/forum/showthread.php?t=13248&ysclid=mcq5lb58sq418866208
это не единственная тема - были и другие, там соединение "отваливалось" от перехода компьютера в "сон" - найти быстро не смог.
поэтому никогда и не пытался повторить соединение, в котором есть сомнения.
Если у Вас личный опыт говорит о нормальном длительном соединении (24/7 месяц+) - значит хорошо и я признаю ошибочность своего совета.
А у вас во сне идёт какая-то работа программ на ПК? :)
Чего бы не отвалиться то
После "пробуждения" соединение не восстанавливалось.
Но, если в новых операционках этой проблемы больше нет, а соединение работает 24/7 по многу дней - это просто чудесно.
Я противник управления простыми приборами (типа ТРМ) от компьютера, т.к. при обрыве соединения ТРМ не переключится в безопасное состояние.
На мой взгляд, автоматика должна быть самодостаточной, а компьютер использоваться для визуализации, изменения параметров, режимов (влиять, но не управлять). Поэтому и предложил дальше ПР и ПЛК, а для ПР пояснил некоторые ограничения измерений, чтобы потом вопросов не было.
Явно же видно, что автор темы - очередной самоделкин без профильного системного образования.
FPavel ну, ваши желания это одно, а реальность другое. Сейчас тенденции в сторону виртуальных ПЛК, другой вопрос, что они должны быть на ОС реального времени. Впрочем возьмите тот же ПЛК200 - это оно и есть... там linux на борту.
Моя ошибка, что я поспешил и купил ТРМ202.
По скольку мне казалось, что на ТРМ есть контакты RS-485, то можно задать любую функцию управления с компьютера при помощи программы не разобравшись в вопросе конкретно.
Потом понял, что да, действительно было проще приобрести, например, ПР200 и в ОвенЛоджике написать программу. Он так же бы смог выполнять работу терморегулятора.
Но пути назад нет. Если чего-то не знаешь, то это повод научиться :)
В панелях оператора - тоже Linux.
Видимо, удобно многообразие процессоров приводить к единообразию обращению с ними, реализации востребованных функций (времени, параллельности процессов, работе с интерфейсами, протоколами и т.д.).
Процессор поменял, скорректировал ядро ОС, а потом общеизвестными методами настройки распространённой ОС уточнил конфигурацию.
У Weintek множество линеек панелей оператора, на разных процессорах, но программируются из единой среды и имеют единообразные возможности (почти единообразные - различия в настройках разных линеек всё же присутствуют).
В принципе, я ещё застал и обслуживал ЭВМ, которые построены без драйверов - весь обмен с внешними устройствами неизменен и является частью ОС. Дальше развивались более гибкие решения - программные драйверы для новых устройств и стало возможно аппаратное обновление ЭВМ.
В АСУ те же процессы.
Пусть автор темы строит виртуальный ПЛК на C/C++...
У меня своё мнение, у него - своё.
Teijo, ставится ПК с программой внутри сети и создаётся кольцевая схема сети. Все.
Ваш ПК по сути ни чем не отличается от нынешних ПЛК. Особенно от ПЛК+ модули ввода/вывода на интерфейсе, которым ваш трм и является.
Кстати на каком языке страдаете?
По скольку мне казалось, что на ТРМ есть контакты RS-485, то можно задать любую функцию управления с компьютера при помощи программы не разобравшись в вопросе конкретно.
Как-то очень давно, когда ПР-ок еще не было. Я брал старый добрый ТРМ138 и прилеплял к нему ATtiny13.
Представьте себе 8 универсальных аналоговых входа + 8 дискретных выходов + маленькая платка, висящая на корпусе сзади и вот вам готовая ПР-ка.
С ТРМ202 можно (было можно) работать по протоколу ОВЕН, а там для обмена есть библиотека ввода-вывода. Она работает стабильно.
Для программирования взаимодействия с прибором ТРМ202 обычно достаточно было использовать функции - OpenPort, ClosePort, ReadFloat24.
При записи уставки в прибор используется команда WriteFloat24. Попадались приборы с нарушенной индексацией поэтому приходилось программно, в случае отказа, менять индекс с -1 на 0.
Из опыта: работал с приборами ТРМ101, ТРМ201, ТРМ202, ТРМ210, ТРМ251, ТРМ138, ТРМ148. Разрабатывал ПО на Delphi.
На Си проблем тоже не будет.
Powered by vBulletin® Version 4.2.3 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot