Проблемы при обмене

[kmm]

Просто для инфо: возможно, кому то пригодится:

Lectus 3.9 (133)
Организовали обмен таким образом: Lectus установлен на сервер с фикс. внешним IP.
Каждый из множества ПЛК хранит данные и передает (modbus rtu) пакетами функцией modbus 16:
каждый ПЛК в свой узел все время по одному адресу и одной длиной посылки:
в посылке необходимые поля для ключа записи базы данных и данные.
При записи последнего регистра в посылке инициируется запись в SQL переменную и вызов встроенной процедуры MySQL
с параметрами-данными посылки.

Видимо, из-за очереди задач и неверных приоритетов, ко времени новой посылки в тот же узел (Через несколько секунд )
предыдущая может не успеть записаться, также возможна запись с измененными данными - событие для записи не инициирует запись сразу и не фиксирует данные для записи. Происходят потери или искажения данных.
Также осталась старая проблема с увеличением объема занимаемой памяти и зависанием в итоге.
Обойти проблему пока не удалось

Ищем альтернативу Lectusу

[admin]

1) Пробовали на текущей версии 3.10 сборка 6 ?
http://www.lectussoft.com/programs/opcserv.zip

2) Вышлите на lectussoft@gmail.com
- Суть проблемы;
- Используемую конфигурацию *.cfg;
- Лог работы *.log из каталога Log папки профиля (через меню "Настройка" - "Папка профиля");
- Время некорректной ситуации
- Отчеты об ошибке *.txt из каталога BugReport папки профиля (если есть).

[kmm]

1) Пробовали на текущей версии 3.10 сборка 6 ?
http://www.lectussoft.com/programs/opcserv.zip

2) Вышлите на lectussoft@gmail.com
- Суть проблемы;
- Используемую конфигурацию *.cfg;
- Лог работы *.log из каталога Log папки профиля (через меню "Настройка" - "Папка профиля");
- Время некорректной ситуации
- Отчеты об ошибке *.txt из каталога BugReport папки профиля (если есть).

Попробовал сейчас на 3.10 : по сравнению с 3.9 кол-во задач в очереди упало.
Тем не менее, проблемы остались. Например, порядка 17-ти посылок с одного ПЛК с интервалом в несколько секунд. Отвечено на все (ПЛК получает ответ), записано 13 (4 последних записи не инициировали запись в базу, но модбас ответ послан и ошибок в логе нет). Одна из записанных с данными предыдущей посылки.

[admin]

Ждем данные и время некорректной ситуации.

[admin]

1) Расположите SQL сервер на том же компьютере что и OPC сервер.
Чтобы не было задержек с исполнением.

2) Периодически из SQL сервера приходит ошибка:
Скрипт: SELECT volume FROM main.vol100 where height <= Item(Var5333) order by volume desc
Ошибка: Could not convert variant of type (Null) into type (OleStr)

[admin]

По поводу пропуска исполнения SQL скрипта на запись.
Такое может быть, т.к. при добавлении операции в очередь на выполнение проверяется наличие идентичной задачи.
Если такая задача уже есть, то добавляемая задача отбрасывается, чтобы не забивать очередь однотипными задачами.

[kmm]

1) Расположите SQL сервер на том же компьютере что и OPC сервер.
Чтобы не было задержек с исполнением.

2) Периодически из SQL сервера приходит ошибка:
Скрипт: SELECT volume FROM main.vol100 where height <= Item(Var5333) order by volume desc
Ошибка: Could not convert variant of type (Null) into type (OleStr)

1. SQL на том же сервере
2. Спасибо, посмотрим, но вряд ли решит наши проблемы.

[admin]

Судя по строке подключения используется подключение к удаленному SQL сервер, а не локальному.
DSN=MYSQL;SERVER=x.y.z.t;UID=...;PWD=...;DATABASE=...;PORT=...
где x.y.z.t - IP адрес.
Если это IP адрес самого компьютера, то логичнее использовать localhost или 127.0.0.1

[kmm]

По поводу пропуска исполнения SQL скрипта на запись.
Такое может быть, т.к. при добавлении операции в очередь на выполнение проверяется наличие идентичной задачи.
Если такая задача уже есть, то добавляемая задача отбрасывается, чтобы не забивать очередь однотипными задачами.

Можете подсказать вариант алгоритма работы с гарантированно достоверной записью данных из ПЛК в базу через Лектус?

Например, у нас есть такой вариант алгоритма посылки ПЛК:
1) запись всех переменных в Лектус одной посылкой (как и в разбираемом логе) - ПЛК делает посылку с контролем ответа
2) чтение той же области данных для контроля идентичности посланных и принятых данных

Получается, данный вариант не гарантирует записи этой посылки в SQL.

Если бы, к примеру, после пункта 1 процедура записи в SQL изменяла определенным образом какой либо служебный регистр в этом узле?

(С учетом той проблемы, что любые записи и чтения переменных, инициирующих запись в SQL переменной, всегда вызывают повторное срабатывание SQL переменной (запись в SQL) )

[kmm]

Судя по строке подключения используется подключение к удаленному SQL сервер, а не локальному.
DSN=MYSQL;SERVER=x.y.z.t;UID=...;PWD=...;DATABASE=...;PORT=...
где x.y.z.t - IP адрес.
Если это IP адрес самого компьютера, то логичнее использовать localhost или 127.0.0.1

Спасибо, проверим.

С наступающим! Всего доброго всем!