Созданные ответы форума
-
Сообщения
-
Что в журнале линии при получении первого значения, у которая не получается записаться в тег? И что в журнале при получении второго значения, с которым всё нормально?
Разбивка тегов по группам в Modbus Slave не важна. Так сделано для полной совместимости шаблона с Modbus Master. Но группы для чтения нужны, если Ваше устройство запрашивает данные из скады.
Если устройство передаёт данные на компьютер, то используются команды из шаблона.
Кроме написанного выше, сейчас разрабатывается экспериментальный модуль, который позволит устанавливать границы через веб-интерфейс и хранить в отдельной БД, а затем обрабатывать статусы каналов в зависимости от этих границ. Разработка ведётся в фоновом режиме, поэтому прогнозов по срокам не делаю.
В первую очередь нужно избавиться от ошибки «Метод не найден». Должна быть обновлена не только KpModbusSlave.dll, но и KpModbus.dll. Кроме того, продублируйте KpModbus.dll в C:\SCADA\ScadaAdmin\Lib — Администратор ищет её там при открытии интерфейса драйвера.
В шаблоне Модбас создайте команду, соответствующую Вашему регистру. И введите имена регистров. Это должно повлиять на состав тегов КП. На странице данных КП должны появиться группы IN и OUT.
Попутная идея: возможно имеет смысл реализовать создание подобных каналов-границ неявно, чтобы их не нужно было нигде прописывать. Но это пока отложим на будущее.
я имею ввиду аварийные и предупредительные пределы входных каналов. Хранить их в других входных каналах — это просто дичь. Для маленького цеха допустим, но для систем с тысячами каналов заводить ещё десятки тысяч каналов для границ, это нереально. Или я что-то не так понял?
Каналы самое удобное место для хранения уставок, т.к. каналы — это по сути переменные. В 6-й версии выполнена следующая оптимизация для работы с границами каналов:
— Для границ создана отдельная таблица в базе конфигурации. То есть одна и та же граница может использоваться многими каналами. Это актуально для типовых границ.
— Не обязательно записывать значения границ в минутные архивы. Их можно записывать только в текущий и часовые архивы, чтобы экономить место на диске.
— Механизм расчёта выхода за границы, которые созданы на основе каналов, встроен в сервер.
— Ограничение на количество каналов (65535) снято.Кроме того, каналы удобно выводить на график, то есть вывести канал и его границы. Не требуется разработка специальной функциональности для границ.
Ответ по уставкам в этой теме.
доводилось писать на FoxPro (если кто знает что это такое :))
Слышал, но уже не застал, тогда технологии менялись быстрее
По описанию системы — драйвер Modbus Slave должен отработать данную конфигурацию.
По настройке интерфейса — создайте отдельную тему, чтобы не путаться. Если кратко, то права назначаются на представления. Если нет прав, то соответствующего представления просто не будет в дереве. Стартовая страница выберется автоматически из доступных. Скрыть кнопку на схеме в зависимости от прав нельзя.
Что было бы полезно в плане уставок — это менять их онлайн. Может какой-то микросервис. Планируется ли что-то в этом плане в 6 версии?
Значения уставок должны храниться во входных каналах. Вроде бы и сейчас это можно сделать. Давайте обсудим в отдельной теме — напишите, что именно нужно по уставкам.
Можете объяснить механизм работы в режиме Slave? Скада создаёт конкретные регистры, указанные в шаблоне и ждёт что в них придёт или там изначально есть пространство регистров?
На основе шаблона создаётся карта регистров. Они все отображаются на странице данных КП. Если удалось получить корректную карту регистров, то далее надо смотреть, привязались ли они к входным каналам.
Опишите подробнее архитектуру Вашей системы. Сколько устройств должно подключатся? Какой алгоритм взаимодействия с ними?
Убедитесь, что у Вас свежие обновления драйверов Модбас и Модбас Слейв, которые есть в этой теме. Там были важные исправления.
В настройках канала связи лучше поставить общее подключение, чтобы КП постоянно слушал TCP-порт.Если мы навяжем ему еще сложные расчеты и всяческие отчеты — о реальном времени можно забыть.
Верно. Сервисы, которые относятся к обработке данных с приборов должны работать на отдельном сервере при сколь-нибудь крупной системе. Отчёты и веб-оболочка — на отдельном оборудовании (физическом или виртуальном).
Согласен с @a80808
По сути, если разрабатывать, это и получился бы отдельный уровень пирамиды, как на известной картинке. При этом с точки зрения пользовательского интерфейса можно реализовать единую веб оболочку с общим входом в систему.Важно ещё смотреть на задачу с точки зрения бизнеса. Сейчас мы фокусируемся на SCADA, чтобы получить качественный продукт. Если распылять усилия, то можно не успеть везде.
