- В этой теме 11 ответов, 2 участника, последнее обновление 2 года, 2 месяца назад сделано
.
-
Записи
-
1. Добавить настройку срабатывать при передаче данных Серверу и загрузке (раньше так срабатывало все, независимо от перехода с Нормализации к Сработке)
Оказалось что это иногда нужно.2. Добавить (исправить) контроль Сервером статуса Коммуникатора и Линий перед отправкой команд в Устройства из очереди. При включении или перезагрузке требуется выставлять большую задержку, которая не всегда нужна в обычной работе. Скажем так вообще не нужна в обычной работе.
3. Сделать функционал сравнения нескольких разных каналов и более сложных условий.
Чисто мысли, что-то вроде расширенного режима на примере «Параметры Линии» — «Пользовательские» можно добавлять много строк с различными условиями триггеров
Которые будут иметь соответственно номера условий, условно Усл1, Усл2, Усл3 и т.д.
Потом в окне ввода «формулы» пишем условное выражение, которое приведет к сработке в виде
(Усл1 & Усл2) || (Усл3 > Усл4)где МАУ и должен проверять результирующее условие на сработку.4. Ну собственно одним из условий должно быть ЕСЛИ (IF)
Да, вот из-за пустых логов при запуске на Linux (ПК на ARM процессоре) возможная причина отправки команд в пустоту, так как еще некуда писать файлы и команды соответственно. Типа Сервер честно отработал, но записал в никуда файл….
Так на Linux это в var/log/scada
По идее сперва должен fstab отрабатывать, потом все остальное. Как проверить не знаю?Тестирую запуск с зависимостями. Но, чтобы не было ошибок в ScadaComm он требует сперва запуска ScadaServer. А вот ScadaServer никаким образом не ждет запуска ScadaComm перед отправкой команд, что не есть хорошо.
Это как-то можно вылечить в коде ScadaServer ?
По идее сперва должен fstab отрабатывать, потом все остальное. Как проверить не знаю?
По идее так. Записать что-нибудь на диск при старте системы, например.
Это как-то можно вылечить в коде ScadaServer ?
Подключение Коммуникатора для Сервера — это подключение одного из пользователей. Причём Коммуникаторов может быть множество, некоторые подключатся, некоторые нет — нельзя блокировать работу команд только потому, что один из Коммуникаторов не подключился. Здесь нужно как-то усложнять механизм доставки команд, делать его более адресным.
Так команды записываются в очередь, Сервер же знает кому? Это его задача, проверять, подключен «пользователь» для получения команды или нет, и отправлять из очереди команды по мере подключения.
Сервер же знает кому?
Нет, сейчас ему неоткуда взять эту информацию. Команда отправляется на канал или на устройство. Какой клиент способен её исполнить, неизвестно. Команда передаётся всем подключенным Коммуникаторам.
А, даже так. Не совсем правильно конечно. Например мы перегружаем удаленный Коммуникатор и в этот момент ему надо передать команду и она ушла в пустоту получается.
Как я писал раньше, успешность команды проверяется по результату её выполнения. Например, изменилось считанное положение реле.
Реализовать адресные команды, которые должны быть доставлены конкретному подключенному клиенту и которые хранятся в очереди пока не доставлены — была бы полезная доработка.
- Для ответа в этой теме необходимо авторизоваться.