- В этой теме 34 ответа, 4 участника, последнее обновление 6 лет, 10 месяцев назад сделано
.
-
Записи
-
Привязать номер канала к тегу можно. Так сделано для KpOpc.
Но в данном случае, возможно, более удобно будет задать набор контролируемых IP в настройках КП, которые хранятся в XML файле, и для каждого адреса создать тег. То есть будет один КП на все IP.Можно и через файл, для Ping-a пойдет.
Просто раньше столкнулся с похожим, когда из-за разного времени опроса счетчика создавал отдельный КП для каждого опроса, вот там было бы удобно задавать один КП, а в Коммуникаторе делать привязку еще и к нумерации каналов, кроме КП и задавать диапазон.
Тоже был бы один КП на прибор, на разделенный по времени.
Чтобы создавалось что-то вроде ID опроса, который так же можно было опрашивать в разное время а так же выполнять внеочередной опрос. То есть выполнять внеочередной опрос не по КП а именно по его ID.Тогда в базе бы мусорки такой не было. Одно устройство — один КП. а при помощи ID разруливаем время опроса, привязку тегов и так далее.
Немного может не туда, но все о старом.
Пока нет дополнительных баз, текстовых или смешанного типа для редко опрашиваемых параметров. Но речь больше о текстовых.
Сейчас я так понимаю сам Коммуникатор обрезает любой текст до 8 байт, превращая выходное значение в double. Это возможности SetCurData.
То есть передать в сервер всю строку не получится никак.
Может для простоты доработать Коммуникатор, например добавив ему функцию SetTextData ?
Ну и чуть доработать Сервер, если мы привяжем данный сигнал к обычной базе, то видя, что там SetTextData уже сервер обрежет до 8-ми байт, непосредственно при записи в базу, но даст возможность полную строку получать в Схему ?
А потом, при добавлении новых баз уже будет понятно, что всю строку записывать… ?С длинными строками нужно какое-то решение. Может быть их в несколько каналов записывать или в отдельный архив.
Так отдельный архив давно просится.
Я же писал ранее, нужна смешанная база в которой можно назначить например 10 ячеек для переменной и переписывать их циклически с меткой времени, и какой оператор сделал изменение.
для другой переменной например 20 последних и так далее.
Ну или количество сделать общим для всех переменных или разделить по типам.
Например текстовым 10, целочисленным 20, булевым 30, float 10 и т.д.Ну и тогда в Коммуникаторе сделать не SetTextData а скажем SetConfigData или еще как.
А в тегах помечать их просто звездочкой или решеткой на номере сигнала напримерМихаил, добрый день!
А нельзя ли научить коммуникатор открывать несколько TCP сессий (к нескольким серверам)?
Задача актуальна для полного резервирования серверов.
В случае MODBUS TCP или SNMP это неактуально, можно обойти созданием произвольного кол-ва линий связи на коммуникаторе каждого сервера.
А вот с ОРС так не получится.
И с MODBUS RTU, если порт включен в удаленный комп, на котором стоит коммуникатор.И еще вопрос, касающийся коммуникатора.
Точнее — KPModbus.
Некоторые производители контроллеров используют нестандартные команды MODBUS. Как правило, для записи в контроллер. Например: 01 11 — старт процесса, 01 12 — останов.
Или 01 11 0000 0001 — старт, 01 11 0000 000f — останов.
Можно ли реализовать возможность произвольного выбора команды?Данный режим работы Коммниукатора не планируется ввиду его неоднозначности. Однако Вы можете использовать модуль Быстрый Шлюз, который позволит дублировать данные на 2-й экземпляр Rapid SCADA.
Также для этой цели рекомендую использовать шлюзы Modbus, которые выдают Modbus TCP нескольким клиентам.Можно ли реализовать возможность произвольного выбора команды?
Технически это возможно. Наиболее реально это реализовать на коммерческой основе.
Вспомнились мои эксперименты читать данные из одного устройства двумя Scada.
Возможно ли реализовать такое в будущих версиях. А именно.
Сделать шаблон для времени опроса в секундах, минутах или часах.
В шаблоне указываются (например нам надо разнести опрос в течении минуты) секунды, на которых Коммуникатор одной Scada будет производить опрос на 0, 10, 20, 30, 40, 50 сек каждой минуты.
А на второй Scada для этого же прибора 5, 15, 25, 35, 45, 55 сек каждой минуты.Прибор подключен например через TCP сервер. ПК с установленными Scada синхронизируют время по NTP. Соответственно каждая Scada не будет мешать опрашивать прибор друг другу.
Коммуникатор не может брать время опроса из шаблона. Но Вы же можете задать период опроса в настройках Коммуникатора. Период отсчитывается от начального времени опроса, т.е. если задать 10 секунд, то опрос будет ровно в 0, 10, 20 и т.д. секунд.
Так что по идее должно сейчас так заработать.Не будет работать, уже проверял, происходит накладка времени опроса с двух точек рано или поздно. А если задать 5 сек то будет 0, 5, 10, 15, 20
я не говорю про существующий шаблон, я предлагаю добавить функционал для временных интервалов вообще в принципе.
Сейчас есть:
«Время» — это чтение один раз в сутки в определенное время, как я понимаю
«Период» — это циклический опрос через указанный промежуток времени, когда он равен 00:00:00 то опрос идет без остановок по кругу.Добавить к этому чтение из шаблона ВРЕМЕНИ (не устройства, так как у устройства шаблон может быть у каждого свой и научить всех создавать его для драйвера будет тяжко). Отдельным открытием файла или где-то еще, не суть…
У нас есть «Период» не строго фиксированный — ЧЕРЕЗ N секунд (минут, часов) от запуска…
я предлагаю сделать хитрость, фиксированное время, что-то типа маски. если указали
5, 15, 25 то Коммуникатор никогда не запустит опрос в 0, 10, 20 секунд минуты.
То же для минут и для часов. Или прописать 7, 12, 17, 22 секунд и так далее.з.ы. это просто хотелка, которая позволит без ухищрений разнести во времени опрос двумя Scada системами одно устройство. Сейчас можно вывернуться при помощи установки чтения в определенное время и формулами, используя Модуль автоуправления выполнять внеочередной опрос. Думаю это сработает, но жутко не удобно 🙂
- Для ответа в этой теме необходимо авторизоваться.