Просмотр полной версии : Как подружить ПЛК304 и Mobus
Нужна помощь. Задача такая - есть рабочая сеть Modbus на стороннем контроллере. Возникла необходимость перенести проект на ПЛК304. Системы не совместимы, т.е. проект придётся писать заново. Но это не проблема. Проблем в том, что у меня не удаётся корректно добавить устройства из сети. Что делаю:
1. Создал устройствой Modbus_Com - сделал необходимые настройки скорости, чётности и т.д.
2. Теперь создаю подустройство Modbus_Mastrer_Com_Port - насколько я понимаю этот мастер будет опрашивать подчинённые устройства в сети. Если на этом этапе запустить компиляцию - вываливает 27 ошибок и одно предупреждение... Хотя до момента создания подустройства компиляция не вызывала ошибок...
В чём проблема?35811
Евгений Кислов
24.02.2018, 09:00
Нужна помощь. Задача такая - есть рабочая сеть Modbus на стороннем контроллере. Возникла необходимость перенести проект на ПЛК304. Системы не совместимы, т.е. проект придётся писать заново. Но это не проблема. Проблем в том, что у меня не удаётся корректно добавить устройства из сети. Что делаю:
1. Создал устройствой Modbus_Com - сделал необходимые настройки скорости, чётности и т.д.
2. Теперь создаю подустройство Modbus_Mastrer_Com_Port - насколько я понимаю этот мастер будет опрашивать подчинённые устройства в сети. Если на этом этапе запустить компиляцию - вываливает 27 ошибок и одно предупреждение... Хотя до момента создания подустройства компиляция не вызывала ошибок...
В чём проблема?35811
Добрый день. Вам следует выбрать версию 3.5.3.x для Modbus Master, чтобы она не превышала версию таргет-файла. ПКМ на Modbus Master - Обновить устройство - поставить галочку Показывать устаревшие версии. Если других версий нет - то вам следует установить архив репозитория (ссылка в подписи).
следует установить архив репозитория (ссылка в подписи).
Я правильно понял - установить CODESYS Repository Archive V3.5 SP4?
Странно, я это делал, сейчас повторил ещё раз, но всё равно не появляются старые версии, только одна из стандарта 3.5.5.5
Евгений Кислов
24.02.2018, 11:52
Да, CODESYS Repository Archive V3.5 SP4. После установки попробуйте перезапустить CODESYS и не забывайте про галочки Показывать все версии/Показывать устаревшие версии.
После установки попробуйте перезапустить CODESYS и не забывайте про галочки
Вижу все библиотеки установлены на диске в папке C:\ProgramData\CoDeSys\Managed Libraries\3S - Smart Software Solutions GmbH\, нашёл там Modbus разных версий, но из программы CoDeSys я их не вижу, только стандартные последней версии... Программу перезагружал, переустанавливал не помогает. Может в ней нужно как-то указать на их местоположение?
Евгений Кислов
24.02.2018, 12:43
Вижу все библиотеки установлены на диске в папке C:\ProgramData\CoDeSys\Managed Libraries\3S - Smart Software Solutions GmbH\, нашёл там Modbus разных версий, но из программы CoDeSys я их не вижу, только стандартные последней версии... Программу перезагружал, переустанавливал не помогает. Может в ней нужно как-то указать на их местоположение?
Возможно, надо включить профессиональный режим настроек.
См. СПК. FAQ, п. 8.2 (ссылка в подписи).
надо включить профессиональный режим настроек.
"Семён Семёныч!"(c) Конечно, я же переустановил CoDeSys и по умолчанию режим настроек стандартный! Всё появилось.
Вам следует выбрать версию 3.5.3.x для Modbus Master, чтобы она не превышала версию таргет-файла.
У меня таргет 3.5.3.40
Версии устройств есть 3.5.3.0 и 3.5.3.50. Я правильно понимаю что подойдёт только первая т.к. вторая старше.
Евгений Кислов
24.02.2018, 13:27
У меня таргет 3.5.3.40
Версии устройств есть 3.5.3.0 и 3.5.3.50. Я правильно понимаю что подойдёт только первая т.к. вторая старше.
Лучше использовать первую.
Лучше использовать первую.
Всё заработало, но возникла другая проблема. Заливаю проект (делаю "создать загрузочное приложение"), запускаю, всё работает, сеть 485 опрашивается. Имитирую отключение питания, контроллер загружается, программа начинает работать, но сеть 485 отвалилась. В Modbus_Slave пишет - Ошибка шины. Помогает сброс из CoDeSys и повторный запуск. Как это реализовать в автоматическом режиме, чтобы контроллер подхватывал сеть после перезагрузки?
Евгений Кислов
24.02.2018, 19:48
Напишите, пожалуйста, на support@owen.ru - вам помогут с этим вопросом.
Напишите, пожалуйста, - вам помогут с этим вопросом.
Нашёл, что Watchdog по идее делает "холодный перезапуск", но опять какие-то грабли... Оказалось не перегружает он ничего а останавливает программу из-за "исключения". Есть идея отслеживать адреса устройств в сети 485 и в случае их недоступности делать холодный перезапуск. Осталось найти способ программного перезапуска... Но и на почту я тоже напишу)))
Напишите, пожалуйста, на support@owen.ru - вам помогут с этим вопросом.
Нашёл решение:
myBlink(ENABLE:= Modbus_Slave_COM_Port.xError, TIMELOW:= T#200MS, TIMEHIGH:= T#1S, OUT=> Modbus_Slave_COM_Port.xReset);
Теперь при восстановлении питания или восстановлении сети 485 порт отвалившегося слейва переподключается!
Появился новый вопрос. Создаю устройства Modbus_Slave. Столкнулся с проблемой. Оказывается есть ограничение на количество каналов в устройстве. Получается не могу ввести больше 10 каналов?
Евгений Кислов
02.03.2018, 07:00
Появился новый вопрос. Создаю устройства Modbus_Slave. Столкнулся с проблемой. Оказывается есть ограничение на количество каналов в устройстве. Получается не могу ввести больше 10 каналов?
В этих версиях Modbus-компонентов действительно есть такое ограничение.
действительно есть такое ограничение.
Напрашивается вопрос - есть версии с другим ограничением?
З.Ы. Немного "выкрутился" из ситуации применив вместо функции 05 на разных каналах функцию 15, правда ещё не опробовал в работе, пока на стадии добавления устройств в проект. Ещё бы разобраться в функции 23...
Евгений Кислов
03.03.2018, 08:28
Напрашивается вопрос - есть версии с другим ограничением?
Напишите в support@owen.ru - вам помогут по этому вопросу.
Ещё бы разобраться в функции 23...
наводящий вопрос, Вы встречали в наименовании своего контроллера слово шнайдер или цифровой код 984-785?
шнайдер или цифровой код 984-785?
??? Интригуете. Такого не видел...
Спасибо за наводку ))) Нашёл
Возник вопрос по использованию функции 15. У меня устройство имеет 8 выходов(реле), делаю один канал для функции 15 длинной 8, пытаюсь сопрягать "подканалы", соответствующие адресам выходов, к примеру 0001(%QX3.1) - тип указан BOOL, переменную сопрягаю BOOL. Компиляция проходит, но во время загрузки возникает ошибка "Тип канала и соотнесённой переменной не совпадают"
Евгений Кислов
03.03.2018, 14:00
Проект выложите, пожалуйста, в котором это проявляется (все не относящееся к делу можно вырезать).
Проект выложите, пожалуйста, в котором это проявляется (все не относящееся к делу можно вырезать).
Извиняйте, не досмотрел... Решил по Вашему совету выложить проект, но прежде удалить всё, не относящееся к вопросу. И... тут обнаружил что эту переменную использовал в TCP_Slave, где она определена как WORD. Из-за этого вылетала ошибка... Не внимательность... Всё поправил - работает как надо.
Новый прикол. Внёс в проект 32 Modbus_slave-устройства. Больше не получается. Как увеличить количество устройств?
Евгений Кислов
03.03.2018, 20:31
Новый прикол. Внёс в проект 32 Modbus_slave-устройства. Больше не получается. Как увеличить количество устройств?
Каких именно слэйвов - TCP или RTU?
TCP или RTU?
У меня в проекте 50 устройств RTU
Евгений Кислов
03.03.2018, 21:12
Есть возможность разнести устройства по обоим RS-485 портам контроллера?
Есть возможность разнести устройства по обоим RS-485 портам контроллера?
Уже думал, к сожалению нет. Сеть рабочая уже 5 лет, прокладывать доп провода возможности нет...
Перенёс проект на ПЛК304, всё-таки разделил сеть на две, чтобы обойти ограничение в 32 устройства. Сейчас отлаживаю работу устройств. Возникла проблема. По моему ощущению работа устройств в сети снизилась примерно в два раза, по сравнению с предыдущим контроллером. То ли это железячная проблема контроллера - тормозной опрос устройств, то ли я что-то неверно прописал... Интересуют верно ли я прописал тайминги:
1. В MainTask я сделал циклическое выполнение t#50ms
2. В каждом Slave-устройстве прописал Ожидание ответа 1000ms
3. Опрос входов-выходов, которые меня интересуют проставил в настройках каналов Slave-устройств от 100 до 300ms
В результате, к примеру при срабатывании геркона на дискретном входе Salve-устройства я вижу изменение только через пару-тройку секунд, причём обратное действие геркона фиксируется почти мгновенно. Что это может быть?
Ильнур Гибадуллин
18.03.2018, 21:57
Перенёс проект на ПЛК304, всё-таки разделил сеть на две, чтобы обойти ограничение в 32 устройства. Сейчас отлаживаю работу устройств. Возникла проблема. По моему ощущению работа устройств в сети снизилась примерно в два раза, по сравнению с предыдущим контроллером. То ли это железячная проблема контроллера - тормозной опрос устройств, то ли я что-то неверно прописал... Интересуют верно ли я прописал тайминги:
1. В MainTask я сделал циклическое выполнение t#50ms
2. В каждом Slave-устройстве прописал Ожидание ответа 1000ms
3. Опрос входов-выходов, которые меня интересуют проставил в настройках каналов Slave-устройств от 100 до 300ms
В результате, к примеру при срабатывании геркона на дискретном входе Salve-устройства я вижу изменение только через пару-тройку секунд, причём обратное действие геркона фиксируется почти мгновенно. Что это может быть?
Какова скорость опроса модулей? Попробуйте снизить время цикла задачи MainTask до 10-20 мс. Обрывы связи наблюдаются при опросе?
Обрывы связи наблюдаются при опросе?
Да, обратил внимание, некоторые Slave-устройства "отваливаются" периодически, я передёргиваю соответствующую шину в программе, связь восстанавливается, может через некоторое время повториться, причём таких устройств примерно 4-5шт из 45.
Ильнур Гибадуллин
20.03.2018, 09:17
Да, обратил внимание, некоторые Slave-устройства "отваливаются" периодически, я передёргиваю соответствующую шину в программе, связь восстанавливается, может через некоторое время повториться, причём таких устройств примерно 4-5шт из 45.
Я рекомендую стабилизировать опрос с отваливающимися устройствами - подправить карту регистров, установить соответствующие таймауты, если ошибки также будут проявляться, то реализовать программную переинициализацию COM-порта. Подробно об этой процедуре описано в документе СПК.Протокол Modbus, п.4.5., стр.55 (ссылка (https://ftp.owen.ru/CoDeSys3/11_Documentation/01_SPK/SPK_Modbus_v.1.1.pdf?_ga=2.171096224.1299502739.15 21525536-1609217972.1521113010)).
Я рекомендую стабилизировать опрос с отваливающимися устройствами - подправить карту регистров, установить соответствующие таймауты, если ошибки также будут проявляться, то реализовать программную переинициализацию COM-порта. Подробно об этой процедуре описано в документе СПК.Протокол Modbus, п.4.5., стр.55 (ссылка (https://ftp.owen.ru/CoDeSys3/11_Documentation/01_SPK/SPK_Modbus_v.1.1.pdf?_ga=2.171096224.1299502739.15 21525536-1609217972.1521113010)).
Да, я использую похожее действие для переинициализации - прописал на каждое устройство такую строку:
myBlink(ENABLE:= Term_47.xError, TIMELOW:= T#200MS, TIMEHIGH:= T#1S, OUT=> Term_47.xReset);
Частично удалил неиспользуемые каналы, некоторые перевёл в режим Rising Edge. Ситуация улучшилась. Меньше стало отвалов и одно устройство, которое вообще не работало - появилось в сети.
Второе, что сделал - уменьшил время ожидания отклика до 100мс, а время между фреймами до 1 мс. После этого временные отвалы устройств в основном прекратились. Но, кроме двух устройств.
После этих действий заметил некоторое улучшение отклика, но ещё не совсем то, которое хотелось...
Ильнур Гибадуллин
21.03.2018, 07:38
Да, я использую похожее действие для переинициализации - прописал на каждое устройство такую строку:
myBlink(ENABLE:= Term_47.xError, TIMELOW:= T#200MS, TIMEHIGH:= T#1S, OUT=> Term_47.xReset);
Частично удалил неиспользуемые каналы, некоторые перевёл в режим Rising Edge. Ситуация улучшилась. Меньше стало отвалов и одно устройство, которое вообще не работало - появилось в сети.
Второе, что сделал - уменьшил время ожидания отклика до 100мс, а время между фреймами до 1 мс. После этого временные отвалы устройств в основном прекратились. Но, кроме двух устройств.
После этих действий заметил некоторое улучшение отклика, но ещё не совсем то, которое хотелось...
Пришлите архив проекта для анализа на support@owen.ru с пометкой "Для Ильнура". Я проверю проект и дам рекомендации по улучшению обмена.
дам рекомендации по улучшению обмена.
По мере перевода записи устройств в режим Rising Edge ситуация с отвалами устройств значительно улучшилась, так же улучшилась отзывчивость всей системы. Возник вопрос по использованию этого режима (Rising Edge), если я перевожу флаг триггера записи в TRUE, через какое время мне можно сбросить флаг? Чисто подбором у меня получилось 30ms, но мне кажется это не совсем верное решение т.к. разные устройства, по идее, реагирую по разному... Т.е. нужно как-то контролировать дошла команда или нет и после сбрасывать флаг. У каждого устройства есть перечень переменных через точку (к примеру .byModbusError), возможно среди них есть флаг подтверждения записи в устройство?
Ильнур Гибадуллин
06.04.2018, 09:44
По мере перевода записи устройств в режим Rising Edge ситуация с отвалами устройств значительно улучшилась, так же улучшилась отзывчивость всей системы. Возник вопрос по использованию этого режима (Rising Edge), если я перевожу флаг триггера записи в TRUE, через какое время мне можно сбросить флаг? Чисто подбором у меня получилось 30ms, но мне кажется это не совсем верное решение т.к. разные устройства, по идее, реагирую по разному... Т.е. нужно как-то контролировать дошла команда или нет и после сбрасывать флаг. У каждого устройства есть перечень переменных через точку (к примеру .byModbusError), возможно среди них есть флаг подтверждения записи в устройство?
Режим Rising Edge подразумевает запись данных по однократному переднему фронту. Другими словами, после подачи импульса запрос кладется в очередь. Необходимости в выставлении таймеров нет.
Необходимости в выставлении таймеров нет.
Т.е. можно тупо в начале следующего цикла сбросить флаг?
Ильнур Гибадуллин
06.04.2018, 12:11
Т.е. можно тупо в начале следующего цикла сбросить флаг?
Все верно.
Все верно.
Заметил периодически появляющийся глюк. Иногда при загрузке исполняемого кода в ПЛК пропадает связь между SCADA и ПЛК, хотя индикатор сети на ПЛК моргает, в локалке сетевой адрес пингуется. Помогает только перезагрузка с отключением питания. Это, конечно не страшно, но сегодня такая неприятность повторилась независимо от загрузки программы... Внезапно пропала связь между SCADA и ПЛК, соответственно и HMI-панель, которая работает посредством SCADA так же перестала работать...
Ильнур Гибадуллин
16.04.2018, 11:25
Заметил периодически появляющийся глюк. Иногда при загрузке исполняемого кода в ПЛК пропадает связь между SCADA и ПЛК, хотя индикатор сети на ПЛК моргает, в локалке сетевой адрес пингуется. Помогает только перезагрузка с отключением питания. Это, конечно не страшно, но сегодня такая неприятность повторилась независимо от загрузки программы... Внезапно пропала связь между SCADA и ПЛК, соответственно и HMI-панель, которая работает посредством SCADA так же перестала работать...
Как часто пропадает связь между SCADA и ПЛК?
Как часто пропадает связь между SCADA и ПЛК?
Не часто. В основном после заливки проекта. Примерно на каждый третий-четвёртый раз заливки. За месяц однажды пропала связь внезапно, во время работы контроллера. Питание исключено т.к. HMI(со SCADA) и контроллер подключены к бесперебойнику.
Как часто пропадает связь между SCADA и ПЛК?
Несколько дней проблем не было. Вчера вечером вносил изменения в программу контроллера, после загрузки SCADA не отвалилась, работала, но сегодня утром обнаружил - связи нет, хотя контроллер работает, программа исполняется.
Не понятно как это диагностировать со стороны контроллера. По идее нужна функция типа Watch dogs, и при выявлении обрыва связи, перезапускать порт LAN. Либо разработчикам искать проблему в прошивке или железе контроллера.
Ильнур Гибадуллин
18.04.2018, 09:34
Не часто. В основном после заливки проекта. Примерно на каждый третий-четвёртый раз заливки. За месяц однажды пропала связь внезапно, во время работы контроллера. Питание исключено т.к. HMI(со SCADA) и контроллер подключены к бесперебойнику.
А Вы останавливаете SCADA-систему во время загрузки нового кода? Полную загрузку делаете или загрузку с онлайн-изменением?
А Вы останавливаете SCADA-систему во время загрузки нового кода? Полную загрузку делаете или загрузку с онлайн-изменением?
Нет, SCADA не останавливаю. Делаю полную загрузку, при онлайн-изменении отвалов не замечал.
Т.е. пока получается, что при полной загрузке проекта, SCADA отваливается как правило сразу, либо через некоторое время. Сейчас перегрузил контроллер - изменений делать пока не буду - понаблюдаю.
Обнаружил новые глюки. За месяц второй раз контроллер теряет несколько Slave-устройств на 485 шине. Причём строка в программе, контроллера, которая перезапускает соответствующее соединение с отвалившемся устройством, не восстанавливает связь. "Вернул" устройства с помощью холодного перезапуска контроллера, но тут же отвалилась связь со SCADA. Решил не перегружать контроллер по питанию для восстановления связи, а откатил версию Ethernet-адаптера. Предыдущая версия 3.4.0.0 не встала - посыпались ошибки при загрузке в контроллер, откатил на 3.3.0.10 - эта встала, причём связь со SCADA сразу появилась.
Спустя несколько часов работы индикация Modbus_TCP_Slave сменилась на красный треугольник "Шина не запущена", но при этом всё продолжает работать... в том числе SCADA через этот TCP...
Ильнур Гибадуллин
23.04.2018, 09:45
Обнаружил новые глюки. За месяц второй раз контроллер теряет несколько Slave-устройств на 485 шине. Причём строка в программе, контроллера, которая перезапускает соответствующее соединение с отвалившемся устройством, не восстанавливает связь. "Вернул" устройства с помощью холодного перезапуска контроллера, но тут же отвалилась связь со SCADA. Решил не перегружать контроллер по питанию для восстановления связи, а откатил версию Ethernet-адаптера. Предыдущая версия 3.4.0.0 не встала - посыпались ошибки при загрузке в контроллер, откатил на 3.3.0.10 - эта встала, причём связь со SCADA сразу появилась.
Спустя несколько часов работы индикация Modbus_TCP_Slave сменилась на красный треугольник "Шина не запущена", но при этом всё продолжает работать... в том числе SCADA через этот TCP...
Пришлите архив проекта (Файл -> Архив проекта -> Сохранить/отправить архив) на support@owen.ru. Укажите, пожалуйста, версию прошивки контроллера и версию таргет устройства.
Пришлите архив проекта (Файл -> Архив проекта -> Сохранить/отправить архив) на support@owen.ru. Укажите, пожалуйста, версию прошивки контроллера и версию таргет устройства.
Отправил проект... в ответ тишина. На вопросы по почте тоже ответа нет. Техподдержка рулит:mad:
Напишу что сам "нарыл".
Предисловие.
Первая проблема, с которой столкнулся - отвал slave-устройств в сети Modbus. Причём в течении суток у меня отваливалось практически 45 устройств из 47 подключенных в сети. Связь с ними не восстанавливалась, пока вручную не сделать сброс. На форуме нашлось множество таких же ситуаций (мне не понятно, почему ОВЕН на них не реагирует). Первым делом использовал сброс шины так:
IF SS_39.xError THEN myblink37(ENABLE:= SS_39.xError, TIMELOW:= T#200MS, TIMEHIGH:= T#1S, OUT=> SS_39.xReset); END_IF
где SS_39 это одно из slave-устройств, myblink37 - генератор BLINK.
Т.о. прописав такие строчки для каждого устройства удалось отвалившиеся возвращать в строй. Порадовался этому, но не тут-то было... Через несколько дней обнаружил несколько отвалившихся устройств, которые не хотели возвращаться с помощью моего BLINK. Так же удавалось вернуть их только ручным сбросом контроллера. Тщательно порывшись на форуме нашёл решение и этой проблемы. Используя эти строки перегружается порт:
IF modbus_master_com_port.xAllSlavesOk=FALSE THEN //сброс ком-порта
myblink00(enable:=TRUE,timelow:=T#6S, timehigh:=T#100MS,out=>);
ELSE
myblink00(enable:=FALSE,timelow:=T#6S, timehigh:=T#100MS,out=>);
END_IF
modbus_master_com_port.xResetComPort:=myblink00.OU T ;
Ну что же... Используя эти костыли вторые сутки - полёт нормальный... Ещё раз хочется передать привет техподдержке и ОВНУ в целом...
Вторая проблема возникла когда я решил подружить свой контроллер и HMI-панель со встроенной SCADA-системой. Так же использовал конфигуратор, создал подключение ModbusTCP_Slave. Панель начала получать данные. Первое время глюков не замечал. Но потом оказалось, что начало отваливаться это подключение - через 2-3 минуты после старта контроллера появлялся красный треугольник. Панель при этом вела себя не адекватно - то указывала что связи нет, то связь появлялась, но очень тормозила (время реакции на действия растягивались до 10 сек), контроллер принимая от SCADA информацию искажал её - значения переменных дико плясали, помогал сброс контроллера. Перезагрузка по питанию опять приводила к вышеописанному бардаку. Решил порыть в том же направлении - попытаться найти команды перезапуска TCP соединения. По соответсвующему названию нашёл внутренние переменные ModbusServer, которые отвечают за данное соединение, причём вручную, в режиме записи значений переменных удалось перегрузить соединение, которое опять продержалось 2 минуты и опять отрубилось. Пытался вытащить эти переменные, чтобы перегружать соединение программно но как-то не удалось - они находятся здесь: Device.Application.ModbusTCP_Slave_Device.m_Modbus Server (.xReset, .xError и т.д.), но вызвать в программе не удаётся - ругается на m_ModbusServer. Пытался создать соединение TCP с помощью функционального блока ModbusServer - сделал как в примере, ещё нашёл на форуме, но никак не удаётся прописать порт соединения т.к. переменная .wPort не доступна. Причём это конкретный глюк в программе CODESYS т.к. при наборе точки я вижу список переменных, wPort отсутствует среди них, но контекстная подсказка с wPort появляется возле другой переменной. На этом месте я уже почти отчаялся... Нахрена мне "коммуникационный контролер ОВЕН" если он не может обеспечить коммуникацию с HMI? И тут я обнаруживаю, что моё соединение работает достаточно долго и не "падает"... Решение оказалось случайным. В ходе экспериментов я создал в программе описание функционального блока ModbusServer. Воспользоваться им я не смог - не получилось прописать порт TCP соединения, но его наличие в программе оказало благотворное воздействие на соединение созданное в конфигураторе. Вот текст программы, который поддерживает моё соединение:
VAR
m_ModbusServer: ModbusServer;
END_VAR
IF m_ModbusServer.xError THEN
m_ModbusServer.xReset:=TRUE;
ELSE
m_ModbusServer.xReset:=FALSE;
END_IF;
Это соединение совершенно не привязано к моему, но почему-то держит канал... Не скажу что всё идеально, но пока (уже 2 суток без отвалов). Не идеально - связь со SCADA стрёмная - периодически, на долю секунды, панель показывает что связь отвалилась. Иногда реакция на действия на панели с небольшим запаздыванием (особенно после перезагрузки контроллера), ещё контроллер часто теряет связь со SCADA после заливки проекта и для того, чтобы восстановить связь нужно передёрнуть питание контроллера.
По первой проблеме тоже решение "так себе" - slave-устройства продолжают отваливаться с частотой раз в 2-3 минуты, благо программа их возвращает. Так и живём...:mad:
P.S. Не думал что у ОВНА будут сплошные костыли... Неужели жажда прибыли напрочь перебивает желание довести сырую поделку до нормального ПЛК?
Отправил проект... в ответ тишина. На вопросы по почте тоже ответа нет. Техподдержка рулит:mad:
Напишу что сам "нарыл".
Предисловие.
Первая проблема, с которой столкнулся - отвал slave-устройств в сети Modbus. Причём в течении суток у меня отваливалось практически 45 устройств из 47 подключенных в сети. Связь с ними не восстанавливалась, пока вручную не сделать сброс. На форуме нашлось множество таких же ситуаций (мне не понятно, почему ОВЕН на них не реагирует). Первым делом использовал сброс шины так:
IF SS_39.xError THEN myblink37(ENABLE:= SS_39.xError, TIMELOW:= T#200MS, TIMEHIGH:= T#1S, OUT=> SS_39.xReset); END_IF
где SS_39 это одно из slave-устройств, myblink37 - генератор BLINK.
Т.о. прописав такие строчки для каждого устройства удалось отвалившиеся возвращать в строй. Порадовался этому, но не тут-то было... Через несколько дней обнаружил несколько отвалившихся устройств, которые не хотели возвращаться с помощью моего BLINK. Так же удавалось вернуть их только ручным сбросом контроллера. Тщательно порывшись на форуме нашёл решение и этой проблемы. Используя эти строки перегружается порт:
IF modbus_master_com_port.xAllSlavesOk=FALSE THEN //сброс ком-порта
myblink00(enable:=TRUE,timelow:=T#6S, timehigh:=T#100MS,out=>);
ELSE
myblink00(enable:=FALSE,timelow:=T#6S, timehigh:=T#100MS,out=>);
END_IF
modbus_master_com_port.xResetComPort:=myblink00.OU T ;
Ну что же... Используя эти костыли вторые сутки - полёт нормальный... Ещё раз хочется передать привет техподдержке и ОВНУ в целом...
Вторая проблема возникла когда я решил подружить свой контроллер и HMI-панель со встроенной SCADA-системой. Так же использовал конфигуратор, создал подключение ModbusTCP_Slave. Панель начала получать данные. Первое время глюков не замечал. Но потом оказалось, что начало отваливаться это подключение - через 2-3 минуты после старта контроллера появлялся красный треугольник. Панель при этом вела себя не адекватно - то указывала что связи нет, то связь появлялась, но очень тормозила (время реакции на действия растягивались до 10 сек), контроллер принимая от SCADA информацию искажал её - значения переменных дико плясали, помогал сброс контроллера. Перезагрузка по питанию опять приводила к вышеописанному бардаку. Решил порыть в том же направлении - попытаться найти команды перезапуска TCP соединения. По соответсвующему названию нашёл внутренние переменные ModbusServer, которые отвечают за данное соединение, причём вручную, в режиме записи значений переменных удалось перегрузить соединение, которое опять продержалось 2 минуты и опять отрубилось. Пытался вытащить эти переменные, чтобы перегружать соединение программно но как-то не удалось - они находятся здесь: Device.Application.ModbusTCP_Slave_Device.m_Modbus Server (.xReset, .xError и т.д.), но вызвать в программе не удаётся - ругается на m_ModbusServer. Пытался создать соединение TCP с помощью функционального блока ModbusServer - сделал как в примере, ещё нашёл на форуме, но никак не удаётся прописать порт соединения т.к. переменная .wPort не доступна. Причём это конкретный глюк в программе CODESYS т.к. при наборе точки я вижу список переменных, wPort отсутствует среди них, но контекстная подсказка с wPort появляется возле другой переменной. На этом месте я уже почти отчаялся... Нахрена мне "коммуникационный контролер ОВЕН" если он не может обеспечить коммуникацию с HMI? И тут я обнаруживаю, что моё соединение работает достаточно долго и не "падает"... Решение оказалось случайным. В ходе экспериментов я создал в программе описание функционального блока ModbusServer. Воспользоваться им я не смог - не получилось прописать порт TCP соединения, но его наличие в программе оказало благотворное воздействие на соединение созданное в конфигураторе. Вот текст программы, который поддерживает моё соединение:
VAR
m_ModbusServer: ModbusServer;
END_VAR
IF m_ModbusServer.xError THEN
m_ModbusServer.xReset:=TRUE;
ELSE
m_ModbusServer.xReset:=FALSE;
END_IF;
Это соединение совершенно не привязано к моему, но почему-то держит канал... Не скажу что всё идеально, но пока (уже 2 суток без отвалов). Не идеально - связь со SCADA стрёмная - периодически, на долю секунды, панель показывает что связь отвалилась. Иногда реакция на действия на панели с небольшим запаздыванием (особенно после перезагрузки контроллера), ещё контроллер часто теряет связь со SCADA после заливки проекта и для того, чтобы восстановить связь нужно передёрнуть питание контроллера.
По первой проблеме тоже решение "так себе" - slave-устройства продолжают отваливаться с частотой раз в 2-3 минуты, благо программа их возвращает. Так и живём...:mad:
P.S. Не думал что у ОВНА будут сплошные костыли... Неужели жажда прибыли напрочь перебивает желание довести сырую поделку до нормального ПЛК?
т.е. этот документ (http://ftp.owen.ru/index.html/CoDeSys3/11_Documentation/01_SPK/SPK_Modbus_v.1.1.pdf?_ga=1.2977203.246264830.14223 34883) ни как не помогает?
т.е. этот документ (http://ftp.owen.ru/index.html/CoDeSys3/11_Documentation/01_SPK/SPK_Modbus_v.1.1.pdf?_ga=1.2977203.246264830.14223 34883) ни как не помогает?
У меня вопросы по использованию возможностей конфигуратора, которые, по идее, сделаны для облегчения создания программ для контроллера... А так, да, документ зачётный, но как он мне поможет? Если только организовать опрос почти пятидесяти slave-устройств через библиотеки... Занятие сомнительное... Если с конфигуратором "засада", чего ожидать от библиотек?
P.S. Да, ещё в этом документе нет ни слова про использование ФБ ModbusServer. TCP соединение только через конфигуратор и ни слова про то, что он может отвалиться через две минуты работы.
P.P.S. Ещё мне понравилось в этом документе рекомендация: "в настройках компонента поставьте галочку Автоперезапуск соединения." А у меня эта галка не активна т.к. ОВЕН, я так понимаю, прекратил поддержку ПЛК304 в плане обновления ПО.
P.P.P.S Всё же, подскажите, как мне через ФБ ModbusServer установить номер порта в переменной wPort?
Насколько помню, раздел 4.5 как раз показывает как следить за соединением, всяко по лучше чем Вы отыскали на форуме.
На счёт остального н понял, в документе ломается работа им конфигуратором и библиотекой, у Вас тоже звучит и то и то, можно Вы одновременно открываете соединение обоими способами, поэтому и проблемы
Насколько помню, раздел 4.5 как раз показывает как следить за соединением, всяко по лучше чем Вы отыскали на форуме.
На счёт остального н понял, в документе ломается работа им конфигуратором и библиотекой, у Вас тоже звучит и то и то, можно Вы одновременно открываете соединение обоими способами, поэтому и проблемы
Вы наверное не читали моё сообщение и не смотрели приведённые мной строки программы... То, что описано в 4.5 это частично решает проблему и это часть того, что я отыскал на форуме. Не понял как и из-за чего ломается? TCP соединение глючно работало пока была настроено только конфигуратором, когда я добавил ФБ стало "сносно" работать. Так что не ломается, а лечиться. Я одновременно не открываю соединение обоими способами т.к. в конфигураторе использую порт 505, а в ФБ, посокольку так и не нашёл настройки порта - по умолчанию 502.
Новые грабли от ПЛК304... Убираю ФБ с ModbusServer. Результат - TCP соединение (порт 505) "падает" через минуту (это не удивительной - уже писал об этом), создаю в конфигураторе второе TCP соединение (порт 504) - через минуту падает соединение на 505 порту, 504 продолжает работать. Создаю третье TCP соединение (порт 503) - о чудо - все соединения работают, не падают... ЧТО ЭТО???
Техподдержка прислала библиотеку для Modbus TCP Slave... Установил, но теперь ругается на TCP (не разрешено) и UDP (не разрешено). Как разрешить?
Евгений Кислов
06.05.2018, 08:58
Техподдержка прислала библиотеку для Modbus TCP Slave... Установил, но теперь ругается на TCP (не разрешено) и UDP (не разрешено). Как разрешить?
В Менеджере библиотек нажать на Заполнители и выбрать версии библиотек, не превышающие версию таргета.
В Менеджере библиотек нажать на Заполнители и выбрать версии библиотек, не превышающие версию таргета.
В заполнителях вижу проблемные библиотеки, не пойму как выбирать версии библиотек и где их брать эти библиотеки?
Евгений Кислов
06.05.2018, 11:02
Напишите на support@owen.ru - вам помогут с этим вопросом.
Библиотеки устанавливаются при установке архива репозитория.
Для выбора версии достаточно нажать на библиотеку - появится выпадающий список.
Так, по порядку, какие мои действия? Проблема с библиотекой CAA Net Base Services, установлена 3.5.4.0, таргет 3.5.3.40, соответственно мне нужно понизить до 3.5.3.х. Не пойму, где мне это искать? Удалить все и заново поставить? Там есть выбор?
Евгений Кислов
06.05.2018, 11:10
На support@owen.ru, напишите, пожалуйста. В письме достаточно указать ссылку на эту тему.
На support@owen.ru, напишите, пожалуйста. В письме достаточно указать ссылку на эту тему.
Написал...
Ещё, мне удалось удалить версию 3.5.4.0, и установить 3.5.3.0, но она встала рядом, а не вместо 3.5.4.0. Т.е. Modbus TCP Slave Library 1.0.0.8 хочет версию именно 3.5.4.0...
Евгений Кислов
06.05.2018, 11:37
Завтра вам отправят все необходимые материалы.
Получил более свежую прошивку, но прошить как-то не задалось. Всё-таки поставил библиотеку, вручную установил недостающие заполнители - система больше не ругается. Получил мастер-класс от Евгения по подключению SCADA - всё работает! Подправил программу контроллера - всё ОК, заработало как надо, HMI-панель не отваливается и не тормозит. В общем с ModbusTCP вопрос решён (надеюсь). Ещё бы разобраться с отвалами Modbus-устройств... Хотя соединение восстанавливается.
Опишите пожалуйста свое решение - что сделано.
Такая же проблема с отвалом ModbusTCP Slave (красный треугольник).
ПЛК 304, прошит на 3.949, таргет 3.5.3.40, Ethernet (v3.4.2.0), ModbusTCPSlave(v3.5.2.0, галочка "Таймаут" снята на странице конфигурации)
Powered by vBulletin® Version 4.2.3 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot