Товарищи форумчане, всем доброго времени суток.
Подскажите, пожалуйста, кто-нибудь пробовал опросить тепловычислитель СПТ940 по протоколу Modbus RTU или эта затея - утопия и пора начинать "копать" в сторону протокола М4?
Вид для печати
Товарищи форумчане, всем доброго времени суток.
Подскажите, пожалуйста, кто-нибудь пробовал опросить тепловычислитель СПТ940 по протоколу Modbus RTU или эта затея - утопия и пора начинать "копать" в сторону протокола М4?
А у него есть Modbus?
з.ы. чем опрашивать собираетесь? я просто для Логики писал драйвер, но он пока без поддержки протокола М4. Если он у вас на столе, то могу доработать.
Сделать для него шлюз в Modbus или в OPC UA вполне возможно...
Согласно одно из мануалов, протокол Modbus RTU есть, но опросить им тепловычислитель не получается (родной OPC работает без проблем), особенно по порту RS232 (отвечу наперёд, один из кругов ... пройден, интерфейс "побежден", путем доработки преобразователя AC3-M).
Пока пытаюсь опросить СПТ940 Owen OPC Server'ом, но всё тщетно.
Какое-то нарушение здравого смысла: пишите, что поддерживает протокол Модбас, а опрашиваете(пытаетесь опросить) по протоколу Овен, мне так кажется!Цитата:
Сообщение от Spawn
Сергей, где я написал, что пытаюсь опросить прибор протоколом ОВЕН?:)
В названии ОРС-сервера!Цитата:
Сообщение от Spawn
Дык он (Owen OPC Server) и с Modbus "дружит"...Цитата:
Сообщение от Сергей0308
Вот же: https://owen.ru/product/new_opc_server
Тогда непонятно зачем у Овена два ОПС-сервера, Овен и Модбас?Цитата:
Сообщение от Spawn
Ну, если, сервер, что у вас используется поддерживает модбас - нет проблем!
Подозреваю, что нет там никакого Modbus. Либо должна быть определенная модификация, либо возможно (с трудом верится) надо включить Modbus. Но не помню, чтобы у них такое было. Остается М4, раз родной OPC работает.
Написать опрос в ПЛК63 думаю будет крайне сложно, учитывая протокол. Хотя бы потому, что прибор немного конфигурируемый.
Ссылку на документацию именно вашей версии покажите, откуда вы взяли, что там Modbus есть ?
ну я не увидел по нему наличия Modbus, где вам это приснилось?
Вполне явная информация в документе "РАЖГ.421412.035 Д7", и в ответе тех. поддержки годичной давности (собственно, на основании их ответа и был приобретён данный тепловычислитель).Цитата:
ну я не увидел по нему наличия Modbus, где вам это приснилось?
Если я правильно понял, то Приборист (по информации из ветки ПЛК1хх) справился с этой задачей...Цитата:
Написать опрос в ПЛК63 думаю будет крайне сложно, учитывая протокол. Хотя бы потому, что прибор немного конфигурируемый.
Spawn не путайте ПЛК100 и 63, а то может оказаться памяти не хватит.
Если будете корячить все таки в ПЛК 63, то помогу чем смогу. По крайней мере расчет CRC без проблем. Ну и некоторое понимание определения местоположения данных, они там поддаются расчету.
Вы задали адрес NT ? и я нашел по Modbus таблицу, но сам документ имеет имя СПТ941 хотя по самому тексту везде 940
Задал адрес (NT), задал скорость и "идентификатор оборудования" (КИ).Цитата:
Сообщение от melky
С CRC, вроде, разобрался, по крайней мере с алгоритмом ее расчета. Расчеты CRC из документации совпадают с моими.Цитата:
Сообщение от melky
Все-таки пишите на ST для ПЛК63?
из того, что помню. Если переменная не влазит в страницу памяти, то она разрывается на две страницы. Начало переменной в конце одной страницы, конец переменной в начале следующей.
Страницы памяти имеют заголовок и контрольную сумму. Если вы считаете две страницы памяти, то будет так
заголовок1 - данные_страницы1 - CRC_стр1 - заголовок2 - данные_страницы2 - CRC_стр2
В общем чутка попляшите с бубном :)
В общем, получилось достучаться до прибора по протоколу Modbus RTU, но осталась незавершенная работа с протоколом М4. Никак не могу установить сеанс связи с прибором.
При попытке записать в порт абракадабру вида "16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#10, 16#02, 16#3F, 16#00, 16#00, 16#00, 16#00, 16#BE, 16#16", прибор в ответ шлет всего четыре байта: "16#32, 16#09, 16#04, 16#16", а должен присылать восемь байт: "16#10, 16#02, 16#3F, 16#92, 16#28, 16#00, 16#04, 16#16". Если значения 16#04 и 16#16 еще можно хоть как-то отнести к "хвосту" ответа, то от куда берутся 16#32 и 16#09 и почему ответ всего из четырех байт, не понятно...
Если в этом же (моем) коде переписать значения буфера на запрос Modbus RTU, то ответы от СПТ940 приходят "адекватные".
Не пойму в чем затык...
Вот лог опроса тепловычислителя OPC-сервером ЛОГИКА:
Вложение 59813
Пробовал и с паузой, и без, и вообще без 16-ти FF - результат одинаковый: "16#32, 16#09, 16#04, 16#16"...:)
Причем, если, например, в запросе изменить адрес прибора (NT) с 02 на 03 (в приборе адрес оставить без изменений - 02), с пересчетом КС8, соответственно, то прибор молчит, значит, можно сделать вывод, что данные до прибора доходят, но в ответ он шлет какую-то несуразицу. Если КС8 "похе..ть", прибор тоже молчит...
Попробую заслать абракадабру с ПК.
В терминале на запрос "16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#10, 16#02, 16#3F, 16#00, 16#00, 16#00, 16#00, 16#BE, 16#16" нормальный ответ приходит: "16#10, 16#02, 16#3F, 16#92, 16#28, 16#00, 16#04, 16#16".Цитата:
Попробую заслать абракадабру с ПК.
melky, помогайте. :)
Куда копать?
Spawn начните с изучения протокола в первую очередь, есть документация на него.
Ориентироваться на лог обмена между OPC сервером и прибором надо осторожно, так как он посылает много служебной информации.
И да, он посылает первый раз 16-ть байт FF для инициализации линии или что-то вроде этого. Причем насколько помню, при обмене с ПК через интерфейс может работать и без этого. + пауза скорее всего должна быть.
// отправка стартовой последовательности
Connection.Write(ProtoRS.StartSequence, 0, ProtoRS.StartSequence.Length);
Thread.Sleep(Math.Min(ReqParams.Timeout, 1050)); // TODO !!!
Пауза нужна. глянул в свой код...
Что его изучать-то? Запрос сеанса связи "как на ладони". :)Цитата:
Spawn начните с изучения протокола в первую очередь, есть документация на него.
Затолкал в порт "16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#FF, 16#10, 16#02, 16#3F, 16#00, 16#00, 16#00, 16#00, 16#BE, 16#16", получил (должен получить) "16#10, 16#02, 16#3F, 16#92, 16#28, 16#00, 16#04, 16#16".
С терминала в порт отправлял запрос без всяких задержек (25 байт подряд одной "строкой"), ответ от СПТ приходит нормальный. Не пойму, в чем принципиальная разница использования задержки при отправке в порт данных с ПК и с ПЛК?
О какой служебной информации идет речь? В логе обмена (пост #16) ничего об этом не "сказано". :cool:Цитата:
так как он посылает много служебной информации.
поверьте, вам это только кажется.Цитата:
Что его изучать-то? Запрос сеанса связи "как на ладони".
Когда вы согласно документации составите один запрос, то увидите разницу. OPC отправляет часто повторяющиеся запросы. Например на каждую переменную в странице отправляет по одному одинаковому запросу, хотя в странице памяти сразу несколько переменных, которые прочитав страницу можно разобрать. Экономится время на запросах.\
пЕсатели протокола Логика и в том числе OPC сервера те еще извращенцы оказались :)
Вы сами задержкой являетесь, достаточной для прибора, если вы кодом отправляете, то задержки уже программные, которых может не быть.Цитата:
С терминала в порт отправлял запрос без всяких задержек
Вот здесь у вас почему-то в блоке данных запроса нули. а по своим логам глянул у меня тоже нули... Это всего лишь запрос версии ПО и идентификатора прибораЦитата:
16#10, 16#02, 16#3F, 16#00, 16#00, 16#00, 16#00, 16#BE, 16#16
Вот же ш:Цитата:
Это всего лишь запрос версии ПО и идентификатора прибора
1.
Вложение 59853
2.
Вложение 59854
3.
Вложение 59855
Получается, что запрос "составлен" корректно (сокращенный формат сообщений):
Вложение 59856
Я специально "слушал" порт при работе OPC-сервера, чтобы посмотреть то, что шлет он, а он шлет тоже самое, что написано в мануале и тоже самое, что шлю и я с ПЛК и с ПК (терминала). Только ответ на ПК (что в OPC, что в терминале) приходит корректный, а на ПЛК, такое ощущение, что какой-то битый, причем, судя по двум последним байтам ответа, приходит только конец, начало где-то теряется...
Ну это вопрос к ПЛК, почему он херит ответ
Ну осталось самое простое - понять что и где не так...:DЦитата:
Ну это вопрос к ПЛК, почему он херит ответ
Я где-то вначале писал, что пробовал в своем коде менять только "наполнение" буфера на отправку, писал (руками побайтно, для М4 тоже буфер заполнен побайтно) значения запроса протокола Modbus RTU - ответ приходит тот, который и должен быть.
Жаль, что нет под рукой другого ПЛК, чтобы проверить работу протокола М4 на нем...
Если стать на прослушку между ПЛК и СПТ940 вы увидите полный ответ или так же битый ?
Подключился к шине RS-485 (ПЛК-СПТ):Цитата:
Сообщение от melky
Вложение 59873
:confused:
"Худой конец": либо код "кривой" :D (вопрос - как тогда Modbus RTU работает?), либо ПЛК63...
Да, я уже и сам к этому "пришел"...:DЦитата:
Сообщение от Валенок
В коде "небольшой" рабочий беспорядок, прошу громко не материться...
Spawn честно не представляю, как такие вещи писать на ПЛК. Вызывать соответствующие методы на обработку и так далее.
Это вы еще до float не добрались, который в СПТ совсем не IEEE754
Валенок, эта "редакция" проекта на проверку работы Modbus RTU, там и в 4-м шаге массив заполнен байтами для этого протокола.Цитата:
Сообщение от Валенок
Во вложении вариант с паузой для М4. Для запроса без паузы, нужно править шаг 2.
Я же говорю - рабочий беспорядок...:)
Который появился в результате проверки всевозможных вариантов.
melky, проблемы нужно решать в порядке их поступления, тут бы, для начала, с сеансом связи разобраться...:)Цитата:
Это вы еще до float не добрались, который в СПТ совсем не IEEE754
А зачем в запросе OPC-сервера ЛОГИКА их 20 (а не 16)? Что 16, что 20, что 30 FF ничего не меняют, это я уже в самом конце их 30 сделал, с целью посмотреть что изменится в ответе СПТ...Цитата:
Вроде речь о 16-ти
Чтобы смотреть, что там в них происходит.Цитата:
Зачем 3 буфера ?
2 таймера, 3 буфера и нули никак на результат не влияют, он всегда один и тот же, а весь этот обоз - результат безуспешных экспериментов, в самом начале был фен-шуй...:)
У меня складывается впечатление, что проблема в ПЛК (толи порт не успевает "развернуться", толи проблема из разряда Modbus ASCII на ПЛК63/73), потому как, даже этот бардак в коде, протоколу Modbus RTU не мешает корректно работать.
Думаю еще на UNM попробовать, или смысла нет?
Достал СПК110[М01]...
Тупо скопировал код (со всем имеющимся в нем бардаком) в проект CDS 3.5:
Вложение 60265
Spawn судя по скрину порт успевает развернуться ? :)
Да... и судя по нему же, на 63-м не успевает...:)Цитата:
Сообщение от melky