Ответы в темах
-
Сообщения
-
Было такое, кончилось место на диске, т.к сам себе Буратино, не ограничил глубину истории. И, ничего.. Хм, что-то тренды уже весь день не пишутся. Проверяю, места на диске 0 байт. Почистил и все пошло дальше.
Надо в UA и все-тут!
С модбасом на больших объемах будут трудности с раскладкой по адресам, особенно, если в середине что-то надо поменять.
В UA таких проблем нет, а красивые структуры тегов очень порадовали, можно передавать имена параметров как угодно, хоть на кириллице. Думаю, вышестоящие интеграторы оценятОпробовал вариант с подключением текущего архива в PostgreSQL к коммуникатору, работает!
Дополнительные плюсы такого решения:
— Возможность не нагружать Сервер обменом по OPC UA
— За счет представлений в PostgreSQL и комбинации запросов в драйвере, получается очень удобно и красиво представить данные в OPC UAОстановился на этом варианте, справится-ли он с нагрузкой, время покажет
Кстати, можно ведь подключить к каналам архив во внешней СУБД и завернуть как источник в коммуникатор. Или даже в отдельный коммуникатор
Источник — это коммуникатор на том-же сервере, он опрашивает шлюзы TCP/485 по modbus TCP. Скорее всего, в будущем, мы спустим коммуникаторы вниз, к полевому уровню.
50 тыс это теоретический максимум, в реальности будет тысяч 30, что не сильно меняет дело.
Сейчас, мы имеем дело примерно с 10 тысячами каналов (с живыми данными), интегрируемся наверх через экспорт в базу SQL. Работает это хорошо, на довольно скромной машине, узких мест пока не видно. Cтоит задача сильно увеличить количество опрашиваемых параметров с тех-же устройств, обработать это (уровень сервера) и отдать дальше, но уже через OPC UA.
Отдавать сырые данные с коммуникатора совсем не хочется, т.к. при изменении конфигурации поля, будут меняться привязки в OPC UA, масштабирование и прочее.Думаю использовать экспорт/импорт c внешней БД. Каналов получится порядка 50 тысяч, с периодичностью в минуты. В модбас, наверное не пропихну, с mqtt не работал на таких масштабах
Нашел решение.
В каждом шаблоне, на любой неиспользуемый регистр (все равно запрашиваем пачкой, а промежутки между нужными данными всегда есть) вписываем код тега, который не будет повторяться в других шаблонах, например в
«чрп_тип1.xml» будет параметр с кодом «sign_fcd_type1», а в шаблоне «чрп_тип2.xml» соответственно «sign_fcd_type2».
Далее, в каналах этих параметров прописываем вызов функций, которые и установят нужный код в канал с типом.
По итогу, вызывается функция только в одном канале, код которого прописан в активном шаблоне.Особенно порадовало, что вызов функции происходит всегда, даже если устройство не на связи.
Благодарю за ответы!
Вы можете сделать перечисление типов, в ячейках будет значение 0,1,2 и т.д.
Делать расчетным/выходным.
Чтобы было в одном месте, делаются формулы. Пихаются в каналы с одним номером с одинаковым смещением.
Ну например у вас в частотниках по 100+ каналов, но не доходят до 200-т например.
Можно 1000, 2000, 3000 сделать. а 1200, 2200, 3200 это ваше перечисление.
Каждому можно назначить через формулу значение по умолчанию, на случай перезапусков и т.д.Сделано по другому. В разных шаблонах коммуникатора прописаны одинаковые коды тега. При смене шаблона, данные попадают туда-же куда и до этого, дальше в дело вступают скрипты, они достают биты статусов и масштабируют аналоговые значения. Для их работы и нужен тип шаблона. Это отлажено и работает, просто тип ЧРП хотелось получать автоматически.
Была надежда на статусы каналов:
На уровне шаблона коммуникатора задаем код тега, уникальный для устройства, а на уровне сервера проверяем статусы каналов всех устройств.
Почему-то не сработало, статусы каналов оказываются одинаковыми, несмотря на то, что в шаблоне прописан только один.Есть парк частотных преобразователей разных производителей. Мы запрашиваем с каждого по несколько параметров: признак работы, частота, ток и еще несколько.
В коммуникаторе созданы шаблоны «чрп_тип1. xml», «чрп_тип2.xml».. Всего пять, но возможно добавятся еще.Одни скрипты уже обрабатывают разные устройства, на switch case это легко делается.
Устройства передают аналоговые параметры с разными множителями, а статусы лежат в разных битах, это учтено в скриптах каналов, но скриптам нужно знать, с какой моделью чрп имеем дело.
Сейчас, если чрп одного типа заменят на другой, нужно сделать два действия:
1.Выбрать соответствующий шаблон в коммуникаторе
2. Выбрать тип устройства в канале (для скриптов)При эксплуатации, обязательно будет путаница, поэтому нужно сделать так, чтобы тип устройства задавался в одном месте.
Уйти от выбора шаблона в коммуникаторе мы все равно не сможем (карты регистров модбас отличаются), а вот сделать так, чтобы при выборе шаблона «чрп_тип1. xml» в канале было 1, а при «чрп_тип2. xml» в канале было 2 кажется вполне вероятным
