хм, транспортная возможность это сквозняк, зачем тогда это все читать при помощи ПЛК ?
Хотя дело ваше с извращениями.
давно дело было, не помню, чтобы я использовал метку времени. Если вообще использовал этот пункт.
а архивы на СПсеть я не реализовывал, только для М4 (з.ы. не для ПЛК, делал для scada драйвер)
Потому чтоСообщение от melky
Часть данных используется технологической программой, которая не должна и не может зависеть от наличия в системе ПК.По сути в данном случае это и получается драйвер, но в ПЛК + преобразователь интерфейса (Modbus TCP <=> СПСеть).
При чтении текущих данных вам метка времени и не нужна (если при текущих она там вообще есть, о чем говорит дока, что части параметров может не быть).
А если и есть, вам ее все равно игнорировать, так как часы там врать могут).
Если бы у вас на руках была Логика, могли бы поставить RapidScada и посмотреть лог. + по коду посмотреть что именно я там запрашиваю.
Общался как-то с техподдержкой, те, кто писал ОРС, их нет наверное уже, а текущие и не знают, что там было и как
Протокол дурацкий и не совсем логичный, написать на ПЛК будет проблематично.
Можете тогда шлюз протоколов поставить, типа такого: https://tractavt.ru/products/elektro...612-i-spg7612/
Только там, по-моему, только оперативные параметры доступны будут. Мы такие используем.
1. для технологии "вчера" и не нужно, по идее как раз и нужны текущие параметры
2. а у них кроме указанных СПТ, СПГ и нет других.
Не решает всех задач – не позволяет подключить и ПЛК, и копьютер, к одному шлюзу, соответственно и запросы с двух устройств не разруливает – т.е. в конечном итоге всё равно RS-485 заводить на ПЛК, чтобы он уже данные верху отдавал – а уж по Modbus он будет подключен к ПЛК или по СПСеть – по большому счёту, без разницы – с последним даже интереснее свой драйвер написать – мало ли где ещё сгодится.
Нигде он скорее не пригодится. Хотя если вы занимаетесь автоматизацией тепловых узлов учёта, может быть. А так достаточно онлайн показаний
Шлюз на микроПК с Linux и RapidScada решит проблему там же, вместе с ПЛК например в DIN реечном исполнении jethub d1+ (232 портов нет, или Логика с RS485 должна быть или преобразователь)
Этот же ПК будет для верхнего уровня. Программой ПЛК просто контролировать пинг или через передаваемые параметры.
На ПЛК вам придется писать жёсткий и фиксированный опрос иначе, под конкретный прибор Логики. Хотя может и fb можно сделать. Зависит от желания потратить время.
з.ы. а если взять панельный ПК, то гамузом ещё и HMI для своего ПЛК получите.
С тепловым учётом не все так просто, должны предоставить доступ на чтение архивов поставщику.
По этому я и упоминал, что должен быть сквозняк для сети Логики.
Именно поэтому сторонние железяки и не подходят – не имеют нужный функционал + не предусмотрены проектной документацией (не за свой же счёт мне их устанавливать).Не вижу необходимости что-то жёстко прописывать в ПЛК. Другое дело – придётся ещё один TCP-сервер на ПЛК запускать, поскольку к Modbus TCP-серверу Логику даже в виде Modbus RTU over TCP не прикрутить (как это получилось с Меркурием 230) – но это будет даже попроще Modbus'а.
А какой у вас ПЛК?
Ну раз нет возможности пропихнуть отдельную железку (на Linux кстати можно сделать и прозрачность и опрос одновременно, если определить время запроса поставщиком, то вообще наверное не сложно, хотя не пробовал) то что вам даст дополнительный TCP сервер не пойму. Поставщик должен иметь возможность читать ПРИБОР а не ваш ПЛК...
а COM over TCP не подойдет ? зачем тут Modbus то ?
Ваши права
Ответить с цитированием