Добрый день.
ПЛК-100. Использую модуль Archiver в файл, переменная Status выдает 2, а спустя некоторое время принимает значение 8.
2 - ошибка записи в устройство. C чем это связано?
8 - такой ошибки в plc_configuration_owen.pdf не указано. Что это?
Модуль Archiver
Добрый день.
ПЛК-100. Использую модуль Archiver в файл, переменная Status выдает 2, а спустя некоторое время принимает значение 8.
2 - ошибка записи в устройство. C чем это связано?
8 - такой ошибки в plc_configuration_owen.pdf не указано. Что это?
Высылайте проект и лог гипертерминала на support@owen.ru
Уже выслал 31 мая. Только не лог гипертерминала, а лог Lectus + конфигурация Lectus + проект CodeSys. Жду ответа.
Но все же вопрос заданный здесь более короткий и прямой, а ответа нет..?
Ну вопросов все больше, а ответов по Email все нет..
1) Вышеуказанная ошибка возникала после того как я записывал в переменную "Status" 255 - запуск архивирования (согласно РП), т.к. Status=0 (Модуль "Архиватор" остановлен). Но время идет вперед и в порядке эксперимента выяснилось, что несмотря на то то что Status=0, архив на самом деле все равно ведется и ошибок не возникает (пока), хотя немного странные разногласия с РП.
2) Далее.. Читаю архив Lectus. Архив пишется со сдвигом (Shift mode) Периодически OPC выдавал ошибку связи, тех поддержка Lectus констатировала, что с ПЛК идут неверные данные, а именно - в середине архивного файла был заголовок архива, чего быть не должно. Вероятно данное обстоятельство возникало вследствие неоднократного изменения программы-конфигурации ПЛК. После загрузки новой программы ПЛК начинал запись в файл с того места, где остановился. Данное обстоятельство не критично, когда архив небольшой, перезаписывается и далее идет все ровно. Но все же..
3) Следующее обстоятельство мне вообще непонятно. Данные считываю MatrikonOPS HDA Explorer и наблюдаю картину: считываются 5 записей, потом пауза (то 4 минуты, то 8...) и опять 5 записей и так регулярно. Скрин ниже. Выгружал архивный файл с ПЛК, в нем данные идут последовательно, пропусков нет.
В Lectus период опроса=5 секунд, хотя мне кажется это не должно влиять на количество получаемых данных. Последняя запись=100.
В ПЛК архивирование по времени, 5 секунд, размер файла 100 текстовых записей.
4) Только что, пока набирал сообщение, в Matrikon несколько минут качество было Bad, Non-Specific, потом все вернулось как указывал выше. Чем может быть вызвано? ПЛК подключен по Ethernet напрямую с ПК.
Это конечно все мои домыслы, полученные экспериментальным путем.. Господа, у кого есть опыт работы с HDA данными, окажите пожалуйста посильную помощь.Вероятнее всего где то-что то я упустил?
В архиве конфигурация Lectus, проект КДС, файл архива их ПЛК
PLCInfo
PLC model MODEL PLC 100
Binary VERSION 2.14.0
Need Target version 2.10
Compiled: 14:31:08 Apr 28 2011
MAC 6A:77:00:00:5E:07
IP 10.0.6.10
GATE 10.0.6.1
MASK 255.255.255.0
PIC upper version is 07
Licence unlimited
No DAC
PIC lower version is 0a
Как то грустно
И уже не смешно....
Служба поддержки ОВЕН за неделю не помогла ничем. Редкие переговоры по email раз в 1,5-2 дня... без информационные..
Мои результаты:
Связь по RS485 идеальна, за 2 дня никаких проблем. Как только переключаю на TCP - ошибки обмена. Напутать что то в настройках сложно, т.к. там всего то порт и IP. Если бы ошибся, связи бы не было вообще. А она есть, только ошибки в данных. Остальные настройки идентичны по RS485 и TCP. Измучив в течении недели техподдержку Lectus, которая (спасибо!) отвечала и терпеливо объясняла мне, что проблема в ОВЕН (Причем на каждый вопрос, ответ поступал чуть ли не мгновенно - камень в техподдержку ОВЕН.)
Привожу цитату очередного ответа Lectus и логи. Может кто то поможет..
Код HTML:От кого: Евгений Япаров<lectussoft@gmail.com> Кому: Трофимов Иван<@mail.ru> Сегодня, 09:54 Начало нормально. Нормально считалось 4 порции данных. с временем истории от 07.06.12 09:37:16 до 07.06.12 09:39:35 на 5-ый запрос ответ не корректный 09:43:34.593 [5556] (192.168.1.150:502) Tx: [16] 00 05 00 00 00 0A 01 14 07 06 00 00 01 E4 00 79 09:43:34.687 [5556] (192.168.1.150:502) Rx: [41] 00 05 00 00 00 F7 39 3A 34 35 20 23 30 30 30 3D 33 32 65 31 0A 0D 32 30 31 32 2E 30 36 2E 30 37 20 30 39 3A 33 39 3A 35 30 Видно что заместо параметров Modbus ответа (адрес устройства, номер функции и др.) сразу идут данные, в текстовом виде: "9:45 #000=32e1 2012.06.07 09:39:50" Такого не должно быть. Не получая в ответ нужный ответ сервер делает 3 попытки получения корректного ответа и выдает ошибку связи. В данном случае со стороны сервера уже ничего не сделаешь. Нужно чтобы Овен исправлял эту ошибку.
Почему очень даже смешно получилось с ответом. Евгений видимо перепутал клиента с сервером. Сервер это тот кто получая запрос спешит на него ответить. И ни как у него не получиться сделать три попытки получить ответ потому что сам только и делает что отвечает. Если же это клиент, тогда совсем становиться не понятно, Вы вроде писали что пропадает каждое пятое сообщение, а чем тогда отличается шестой запрос, от указанной выше попытки еще раз добиться ответа после неудачи с пятым запросомСообщение от kait-volga
Я лично считаю что под архивом понимается существенный объем данных, а та строчка которая считается ответом, её легко передать и третьей функцией, получится даже быстрее чем сто миллисекунд, может кстати во времени все дело, увеличте период опроса
Насколько я понимаю, Евгений имел ввиду OPC Server - в котором также присутствует клиент... Так что здесь не вижу ничего смешного..
А отвечает - ПЛК100.И ни как у него не получиться сделать три попытки получить ответ потому что сам только и делает что отвечает.
После того как я писал, прошло несколько дней, куча писем на Support и различных попыток. Ошибки за это время так же были разнообразные. В чем логика их появления мне бы и хотелось выяснить.Если же это клиент, тогда совсем становиться не понятно, Вы вроде писали что пропадает каждое пятое сообщение, а чем тогда отличается шестой запрос, от указанной выше попытки еще раз добиться ответа после неудачи с пятым запросом
Это пример для установления обмена, дабы не возникало вопросов в правильности конфигурирования чего то еще. В нем всего одна переменная и есть. А в задаче стоит гораздо большее кол-во переменных и времени их хранения. Если у Вас есть опыт работы с HDA данными и Lectus, то милости просим, помогите.Я лично считаю что под архивом понимается существенный объем данных, а та строчка которая считается ответом, её легко передать и третьей функцией, получится даже быстрее чем сто миллисекунд,
Период опроса в Lectus = 5 минутможет кстати во времени все дело, увеличте период опроса
Кстати насчет пятого запроса. В том случае отсутствовала часть данных, но ошибки не возникало. Т.е. дело не в пятом или шестом запросе, так как все данные-строки считываются за ОДИН запрос. Дело в количестве считываемых строк - в Lectus номер последней записи, а в КДС - Max Size. Вот в пропорции данных параметров все и дело. В примере "Передача архивов из ОВЕН ПЛК" данному моменту не уделено должного внимания, на скриншотах видно что Max Size=20000, а в Lectus=5000. По тексту (если количество записей в файле меньше указанного, то чтение корректно прекратиться на последней записи файла), а что будет если наоборот, в ПЛК записей больше чем значение в Lectus, не сказано. По моему опыту - часть данных не будет читаться, как происходило у меня. Вот только запись в ПЛК и запись в Lectus не равные величины (опять же найдено опытным путем) и их соотношение примерно ПЛК 1/ Lectus 10.
И даже на этот вопрос, должного ответа от техподдержки я до сих пор не получил.
Опыт только базовый, потому как таким способом не архивировал ни когда. Могу предложить пойти следующим путем, отказаться от конфигуратора, программным путем открыть сокет, анализировать приходящий запрос и отправлять примерный ответ, если со стороны лектуса ошибки пропадут значит виноват овен, если останутся значит либо канал связи между устройствами либо орс-сервер
К сожалению на данном этапе, для такого пути моего опыта недостаточно.
Ваши права
Ответить с цитированием