Просмотр полной версии : ЛОГИКА СПТ-943, 961.
Vladislav11
14.03.2025, 09:15
Добрый день, есть 1 GPRS модем для узла, где установлены 3 тепловычислителя СПТ, вопрос как можно подключить их к 1 модему?
Два СПТ 943, один - 961. Так же GPRS модем имеет аппаратный разветвитель сигнала RS-232, у нас он работает на постоянную основу в АССОИ, а так же приостанавливает запись в БД, если начать опрос через Пролог.
СПТ можно в СП-сеть повязать, соединив их через Х3/Х4 (при условии, что хотя бы один из них свободен, разумеется). Модем подключается к Х2 любого из них, разветвитель не нужен.
Назначить разные адреса NT (если не ошибся с параметром) для СПТ и опрашивать учитывая адреса. Насколько помню, там даже по RS232 можно несколько приборов опрашивать. Важна только длина линий.
Vladislav11
14.03.2025, 09:37
Хорошо, но суть в том, что для нашей схемы у двух приборов разные схемы подключений, может есть у кого пример?
Что касаемо NT и Спцфк, то они настроены, по конфигу все понятно.
Vladislav11
14.03.2025, 09:38
Да, разветвитель идет в Moxa NPort, но у нас еще есть сторонний потребитель данных - иногородний филиал. Это их инициатива, установка такой схемы.
Тогда рисуйте схему. И предоставьте схемы приборов точные. Там после 943 и 961 через точки еще модификации идут. Если ИД приборов укажете, тоже будет полезным.
Назначить разные адреса NT
NT - это не для этих приборов. В общем, я уже всё написал, что нужно сделать. Документацию прочитать, провода протянуть и настройки в 003/004 прописать - это сами.
К магистрали может быть подключено до 30 абонентов. Каждому абоненту должен быть задан уникальный адрес из диапазона от 0 до 29. Адреса рекомендуется назначать от нуля подряд, без пропусков.
из доки на -тепловычислители СПТ961, СПТ961М, СПТ961.1, СПТ961.2;
з.ы. ну может с какими-то другими перепутал. Но адресация в них есть.
943 если не ошибаюсь имеет другой протокол магистральный М4 - у него как раз и есть адрес NT
из доки на -тепловычислители СПТ961, СПТ961М, СПТ961.1, СПТ961.2;
943 если не ошибаюсь имеет другой протокол магистральный М4 - у него как раз и есть адрес NT
Ошибаетесь. NT - это у старых приборов типа 941, 741 и т.п. 943 - это из новых, у него даже эзернет есть. Сделано, правда, всё кривовато. Может и поменялось что, я пару лет назад интересовался.
ЗЫ: Судя по РЭ, ничего не поменялось:
Прием и передача данных по всем интерфейсам осуществляется в соответствии с магистральным
протоколом (www.logika.spb.ru Магистральный протокол СПСеть), по интерфейсу RS485 возможен
также обмен данными по протоколу Modbus RTU (см. там же).
А 2 года назад писали, мол "дорабатываем ещё".
из доки на -тепловычислители СПТ961, СПТ961М, СПТ961.1, СПТ961.2;
Но адресация в них есть.
Есть, конечно. Но не NT.
Ну у меня дока по протоколу где СПТ94х указано, без последнего номера. Есть отдельно на 944
Возможно от года выпуска еще зависит. я помню вы про Ethernet жаловались, они там адресацию свою натянули на Modbus как сову на глобус :) об этом речь была вроде ?
А, или это МихаилГ жаловался...?
Возможно от года выпуска еще зависит. я помню вы про Ethernet жаловались, они там адресацию свою натянули на Modbus как сову на глобус :) об этом речь была вроде ?
Не совсем. Я увидел эзернет, а подключаться по нему нужно было, подумал - щас по Modbus TCP всё заберу. Наивный чукотский вьюноша - там только магистральный протокол. Пришлось через иховый OPC тащить.
Странно, вроде МихаилГ даже добился опроса по Modbus, там кажется или тот или тот, но Modbus натянутый на их адресацию и хитро работает. Вроде темы тут на форуме были.
Блин, я слепень. 943. Они с 96х вообще очень плохо вместе живут. Мы разные модемы ставили для опроса.
Не знаю, может с коммутатором что и получится. Но скорость придётся на 2400 ограничивать у 961-го.
Странно, вроде МихаилГ даже добился опроса по Modbus, там кажется или тот или тот, но Modbus натянутый на их адресацию и хитро работает. Вроде темы тут на форуме были.
на 485-ом RTU, на эзернете только ихний магистральный.
А нет ли у кого логов обмена в СПСети?
Планирую собирать данные с СПТ961 (доступ к которому появится только при пусконаладке) в ПЛК (не ОВЕН) + шлюзовать Modbus-запросы верхнего уровня (чтобы не заморачиваться с программой в контроллере, если верху вдруг понадобится брать с тепловычислителя что-то ненужное ПЛК), однако исходя из имеющейся документации (https://www.logika-consortium.ru/wp-content/uploads/2016/03/Magistralnyj-protokol-SPSet.pdf) совершенно не ясен формат метки времени, который может присутствовать при чтении параметра – анализ логов из видео «Пример сканирования СПСети серез прибор-шлюз, подключение к шлюзу по RS232 (https://a2tech.su/product/protocols_analyzer_4_05/)» таких параметров (возвращающих метку времени) не обнаружил, попытка найти какие-нибудь другие логи успехом не увенчалась ¯\_(ツ)_/¯
89867
И вот ещё какой вопрос – кусок запроса параметра 003 из логов:
12:57:42.822 (1); * : ---- scanning device NT=01: ----
12:57:42.827 (1);COM2 ---> : $10 $01 $01 $82 $10 $1F $1D $10 $02 $09 $30 $09 $30 $30 $33 $0C $10 $03 $74 $FA
12:57:42.831 (1); * : ;Proto: SPBus message;CRC check:*OK*;with address;dstNT=1;srcNT=130;param_num=0x003;FNC=$1D( request)
12:57:43.196 (1);COM2 <--- : $10 $01 $82 $01 $10 $1F $03 $10 $02 $09 $30 $09 $30 $30 $33 $0C $09 $31 $30 $35 $30
12:57:43.196 : $30 $30 $31 $30 $33 $35 $09 $20 $0C $10 $03 $4E $A7
12:57:43.200 (1); * : ;Proto: SPBus message;CRC check:*OK*;with address;dstNT=130;srcNT=1;param_num=0x003;FNC=$03( response);param_val=1050001035
Указатель выглядит как 0\t003 – а как отреагирует прибор, если вместо 003 будет 3? Или номер параметра в запросах всегда (у всех приборов логики) число трёхзначное? Планирую в шлюзе адрес Modbus-регистра использовать как указатель (=1000 * номер канала + номер параметра), поэтому и всплыл такой вопрос (если у них ещё и длина номера параметра зависит от прибора и/или параметра – это жесть).
PS: вариант с OPC-сервером мне не подходит, поскольку контроллер должен получать данные даже в случае отсутствия компьютера или связи с ним.
МихаилГл
25.07.2026, 18:14
Странно, вроде МихаилГ даже добился опроса по Modbus, там кажется или тот или тот, но Modbus натянутый на их адресацию и хитро работает. Вроде темы тут на форуме были.
О, случайно увидел как упоминали меня... Больше года назад. Мимо меня прошло. Да, у 962го вроде, натянутый модбас рту, на глобус. Там нельзя групповые запросы делать, так как 100й регистр, например, это lword на 4 регистра, а 101й, это другой lword на другие 4 регистра. Плавающий модбас. Как раз твою любимую рапид скаду под это настраивал.
О, случайно увидел как упоминали меня... Больше года назад. Мимо меня прошло. Да, у 962го вроде, натянутый модбас рту, на глобус. Там нельзя групповые запросы делать, так как 100й регистр, например, это lword на 4 регистра, а 101й, это другой lword на другие 4 регистра. Плавающий модбас. Как раз твою любимую рапид скаду под это настраивал.Идея практически как у меня – только я ещё хочу функцию 0x17 Read/Write Multiple Registers задействовать как раз для группового запроса – вместо записываемых регистров передавать адреса. Ну и формула у них для адресации 1024 * номер канала + номер параметра – но я решил так не делать, чтобы можно было адреса регистров 0…64999 оставить под параметры каналов 0…64, а 65000…65535 в перспективе под архивы (собственно, в СПСети они так и адресуются на канале 0).
Плавающий модбасСкорее а-ля Enron Modbus (https://store.chipkin.com/articles/modbus-daniels-what-is-enron-or-daniels-modbus) (если бы параметры ограничивались четырьмя байтами) – только там такой фокус действует на ограниченном диапазоне адресов 5001…5999 для DINT и 7001…7999 для REAL.
А вы архивы собрались читать? В текущих откуда там метка времени?
А вы архивы собрались читать?Это задача верха – решать, что он там будет читать, моя задача – предоставить транспортную возможность.
В текущих откуда там метка времени?Согласно спецификации ¯\_(ツ)_/¯
89869
хм, транспортная возможность это сквозняк, зачем тогда это все читать при помощи ПЛК ?
Хотя дело ваше с извращениями.
давно дело было, не помню, чтобы я использовал метку времени. Если вообще использовал этот пункт.
а архивы на СПсеть я не реализовывал, только для М4 (з.ы. не для ПЛК, делал для scada драйвер)
зачем тогда это все читать при помощи ПЛК ?Потому что
PS: вариант с OPC-сервером мне не подходит, поскольку контроллер должен получать данные даже в случае отсутствия компьютера или связи с ним.Часть данных используется технологической программой, которая не должна и не может зависеть от наличия в системе ПК.
делал для scada драйверПо сути в данном случае это и получается драйвер, но в ПЛК + преобразователь интерфейса (Modbus TCP <=> СПСеть).
При чтении текущих данных вам метка времени и не нужна (если при текущих она там вообще есть, о чем говорит дока, что части параметров может не быть).
А если и есть, вам ее все равно игнорировать, так как часы там врать могут).
Если бы у вас на руках была Логика, могли бы поставить RapidScada и посмотреть лог. + по коду посмотреть что именно я там запрашиваю.
Общался как-то с техподдержкой, те, кто писал ОРС, их нет наверное уже, а текущие и не знают, что там было и как :)
Протокол дурацкий и не совсем логичный, написать на ПЛК будет проблематично.
Потому чтоЧасть данных используется технологической программой, которая не должна и не может зависеть от наличия в системе ПК.
Можете тогда шлюз протоколов поставить, типа такого: https://tractavt.ru/products/elektronnye-ustroystva/modbus-adapter-dlya-priborov-spt9612-i-spg7612/
Только там, по-моему, только оперативные параметры доступны будут. Мы такие используем.
1. для технологии "вчера" и не нужно, по идее как раз и нужны текущие параметры
2. а у них кроме указанных СПТ, СПГ и нет других.
Можете тогда шлюз протоколов поставитьНе решает всех задач – не позволяет подключить и ПЛК, и копьютер, к одному шлюзу, соответственно и запросы с двух устройств не разруливает – т.е. в конечном итоге всё равно RS-485 заводить на ПЛК, чтобы он уже данные верху отдавал – а уж по Modbus он будет подключен к ПЛК или по СПСеть – по большому счёту, без разницы – с последним даже интереснее свой драйвер написать – мало ли где ещё сгодится.
МихаилГл
27.07.2026, 07:20
Нигде он скорее не пригодится. Хотя если вы занимаетесь автоматизацией тепловых узлов учёта, может быть. А так достаточно онлайн показаний
Шлюз на микроПК с Linux и RapidScada решит проблему там же, вместе с ПЛК например в DIN реечном исполнении jethub d1+ (232 портов нет, или Логика с RS485 должна быть или преобразователь)
Этот же ПК будет для верхнего уровня. Программой ПЛК просто контролировать пинг или через передаваемые параметры.
На ПЛК вам придется писать жёсткий и фиксированный опрос иначе, под конкретный прибор Логики. Хотя может и fb можно сделать. Зависит от желания потратить время.
з.ы. а если взять панельный ПК, то гамузом ещё и HMI для своего ПЛК получите.
С тепловым учётом не все так просто, должны предоставить доступ на чтение архивов поставщику.
По этому я и упоминал, что должен быть сквозняк для сети Логики.
С тепловым учётом не все так просто, должны предоставить доступ на чтение архивов поставщику.
По этому я и упоминал, что должен быть сквозняк для сети Логики.Именно поэтому сторонние железяки и не подходят – не имеют нужный функционал + не предусмотрены проектной документацией (не за свой же счёт мне их устанавливать).
На ПЛК вам придется писать жёсткий и фиксированный опрос иначе, под конкретный прибор Логики.Не вижу необходимости что-то жёстко прописывать в ПЛК. Другое дело – придётся ещё один TCP-сервер на ПЛК запускать, поскольку к Modbus TCP-серверу Логику даже в виде Modbus RTU over TCP не прикрутить (как это получилось с Меркурием 230) – но это будет даже попроще Modbus'а.
А какой у вас ПЛК?
Ну раз нет возможности пропихнуть отдельную железку (на Linux кстати можно сделать и прозрачность и опрос одновременно, если определить время запроса поставщиком, то вообще наверное не сложно, хотя не пробовал) то что вам даст дополнительный TCP сервер не пойму. Поставщик должен иметь возможность читать ПРИБОР а не ваш ПЛК...
а COM over TCP не подойдет ? зачем тут Modbus то ?
А какой у вас ПЛК?Не ОВЕН. Но с Codesys 3.5 – поэтому ПЛК даже не столь важен.
что вам даст дополнительный TCP сервер не пойму. Поставщик должен иметь возможность читать ПРИБОР а не ваш ПЛК...Так он и будет читать свой прибор. Транзитом через ПЛК.
а COM over TCP не подойдет ?Вот именно через него поставщик и будет слать запросы.
зачем тут Modbus то ?Для скады. Какая скада – не скажу – на её выбор я тоже не влияю )
Ну если в этом ПЛК есть возможность сделать транзит, то и вопросов то не должно быть.
CodeSys 3.5 на Linux. Возможно там есть socat (правда есть ли возможность его как демон запускать я хз)... ну или другие способы. Если TCP сервер на COM порт создает несколько сокетов, то и поставщик может читать и вы из ПЛК можете читать текущие. А Scada уже будет забирать из ПЛК
Powered by vBulletin® Version 4.2.3 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot