Спк107 шина не запущена

Видео:Cs-Cs: Щит котельной в Папушево на ОВЕН СПК110, часть 2: СПК110 в работеСкачать

Cs-Cs: Щит котельной в Папушево на ОВЕН СПК110, часть 2: СПК110 в работе

СПК107+МВ110. Компилятор ругается. На библиотеки или другое?

Добрый вечер, уважаемые коллеги. Продолжая самообучение Кодесису 3-ему по урокам с диска, подошел к моменту связи СПК107 с МВ110-2АС. Сразу скажу, что кодесис 3.5 сп3 патч5, СПК пару дней назад прошил последней прошивкой и поставил новые таргеты. Сколько не бился со связью-ничего не получилось, до физического уровня не доходим, уже на уровне компиляции вылетают ошибки, ссылающиеся на библиотеки (см. вложение 1), на остальных вложениях изображены объявления переменных и подключенные библиотеки, а так же прикреплен сам проект. Особо меня «вдохновляет» ошибка, обведенная красным, а так же что все ошибки ссылаются на какой-то DataGet. Все старался делать по pdf-файлу «Описание интерфейса библиотеки ФБ для работы с протоколом ОВЕН»(файл fb_v3.pdf на диске от СПК107), учитывая, конечно, что у меня СПК107 и другой МВ110. Хотелось именно с протоколом ОВЕН поиграться. Хотя кто-то может посчитать это блажью, но почему бы и нет? У меня уже был работающий проект с визуализацией и я решил подключить МВ110-ый, но что-то не заладилось. Что я делаю не так?

Коллеги, ау! Может, все-таки, что-то посоветуете? Почитал форум и понял что ничего не понял. Какое-то жонглирование версиями библиотек, прошивок и таргетов, а где взять версии более старые? Или более новые? Или какие-то очень актуальные? Я архива,например, не вел, считая это ненужной, так же как и в кдс 2.3, затеей. Или получается «помоги себе сам», в этой весьма затейливой и малопонятной ситуации?

Я бы посоветовал сохранить проект в формате .projectarchive. Файл — Архив проекта — Сохранить/отправить архив.
Так проект сохраняется полностью включая установленные библиотеки. И в таком виде выложит на форум.
Может тогда кто то и поможет.

у меня другое предложение, создать пустой проект и начать последовательно включать небольщие кусочки из проблемного и компилировать, пока не появятся вышеуказанные ошибки. И как бы через конфигурацию можно модбас поднять, зачем библиотекой то пользоваться

capzap
Дык интересно именно по ОВЕНу почитать данные. С модбасом-то понятно все

Возможно проблема в схеме подключения. В руководстве их две. первая дана таблицей. вторая картинкой. та которая вторая-не корректна. Для рс 485 используются ноги 1 и 6.

Саша, спасибо! Компилятор ругается на типы данных. Неужто такое может быть из-за кабеля? По-моему до физической связи процесс еще не доходит. А библиотеки-то корректные (см. картинку 3)?

Александр Приходько
Саша, попробовал, кабель тут явно не при чем. Дело в том, что компилятор выдает те же ошибки в режиме эмуляции, что и в онлайне. Я сначала закомментировал использование экземпляра OWEN_GET_REAL в программе, остались те же ошибки. И только когда я закомментировал и объявление этого функционального блока, ошибки исчезли. Это что, библиотека OwenNet не дружит с кодесисом 3.5?

Архив проекта в студию. Конечно если проблему не решили.

Доброе утро. Архив проекта прикреплен в первом посте темы («Test1_mv110.projectarchive») еще 3.12.2013. Проблему не решил, т.к. был в отпуске, но до отпуска все ухищрения ничего не дали.

Видео:1. Установка программного обеспечения и загрузка проекта в приборСкачать

1. Установка программного обеспечения и загрузка проекта в прибор

СПК107 + ПЛК150 по RS-485 Ошибка шины ModBus

Вводные данные:
Codesys 3.5 SP5 Patch 2
СПК 107 прошивка 3.939
Таргет СПК107 3.5.4.20
Версия COM-устройства 3.4.0.0
Версия Master 3.5.4.0
Версия Slave 3.5.4.0

Итак, СПК107 должен через свой СОМ1 по 485 получить температуру с аналогового входа ПЛК150-M-U. На стороне ПЛК150 все настроено правильно, на стороне СПК все скорости, адреса и каналы тоже. Проблема заключается в абсолютно нестабильной работе шины. Соединение появляется только когда коннектишься с компа (начинает мигать СВЯЗЬ на СПК и отображаются нормальные значения). При пропадании питания связь не восстанавливается.
Знаю, что тема избитая, но я уже перепробовал все версии устройств и все настройки. Ничего не пашет. Ставлю Мастер 3.5.5.0 — стает активна галка АВТОРЕКОННЕКТ, ставлю ее, что-то поработет до первого чиха. Вот ведь не задача Мастер должен быть младше таргета СПК! Ставлю обратно Мастер на 3.5.4.0 галка стает недоступна и вообще ничего не восстанавливается при обрыве.

Вопросы:
1 Как настроить этот проект, чтобы добиться устойчивой связи?
2 Какую версию мастера мне можно использовать и как вообще обновлять/добавлять эти ModBus устройства?

готов оказать посильную помощь.. стукни в skype: ladimko

Пробовал еще позавчера менять Задачи цикла шины как во вкладке ModBus Com, так и в ModBus Slave. Не помогает.

Загрузил проект ваш в СПК105, опрос идет нормально. Но у меня просто SP5.

У меня тоже нормально стало, но после пропадания питания ПЛК при работающей СПК связь не хочет восстанавливаться. На что все таки влияет опция «Задача цикла шины» в настройках ModBus и Установках ПЛК?

У меня опрос восстанавливается в вашем проекте.

Все получилось, пока работет. Спасибо.

А что получилось если не секрет. Просто у меня тоже есть проблемы с СПК и модбасом. Зависает периодически МАСТЕР, причем не хорошо так. Симптомы следующие обмен не останавливается, модули принимают и получают значения от СПК, но СПК шлет в сеть одни и те же значения, не зависимо от того как они меняются в программе и отдает в управляющию программу те значения которые получил на момент зависания. Как следствие модули думают что все нормально, программа тоже получает какие то цифры, но реальности они уже не соответствуют. При этом если физически переподключить спк к RS-485, все оживает. А так ни галка автореконект ни программная перезагрузка слейвов не помогает. Немного спасает уменьшение таймаута мастера до 20мс. Зависания так же случаются, но мастер через какое то время выходит из своего не документированного состояния.Но все же это плохо, так как иногда на это уходит полчаса. А все это время модуль вывода продолжает греть тэны по старой уставки шима ( на спк реализовано 10 пид регуляторов). Я понимаю что проблемы всего скорее связанны с помехами так как в шкафу инверторов на 100 кВт, но вот такое поведения модбас мастера печалит. Пока пробую перезагружать программно не слейв а сам мастер при наличие проблем со слейвами. Вроде как вторые сутки без нареканий. Сложность еще в том что оборудование работает 24 часа и переписать обмен с модулями при помощи другой библиотеки на ходу моих знаний не хватает. А проблема именно в библиотека мастера от codesys, так как на другом порту спк крутиться самописный мастер(работает через SysCom) который управляет инверторами, там таких проблем нет

Видео:Овен СПК 107 работа с COM1 подключение модуля МВ110-32ДНСкачать

Овен СПК 107 работа с COM1 подключение модуля МВ110-32ДН

Тема: Ошибка при настройке modbus slave «Шина не запущена»

Опции темы
Отображение

Видео:Овен СПК 107 работа с COM1 подключение модуля вывода МУ110-32ДНСкачать

Овен СПК 107 работа с COM1 подключение модуля вывода МУ110-32ДН

Ошибка при настройке modbus slave «Шина не запущена»

11_.JPG
Согласно предложенному примеру по настройке modbusTCP slave в codesys v3 проделал все действия.
Однако возникает сообщение: «Шина не запущена», которое на рисунке выделено красным.

Вообще идея такая:
Создать эмулятор ПЛК с modbusSlave и соединить его с Lectus OPC.

Прочитал все инструкции по этому поводу предложенные Owen. Но по инструкции не работает.
Помогите кто делал что-то подобное.

в случае с 485 модбасом подобная ошибка у меня вылазила, когда адреса опрашивать пытался не те, что в приборах прописаны

Для начала советую посмотреть этот документ. В нем все очень подробно с видео расписано как настраивать.
http://www.owen.ru/forum/showthread. l=1#post117771

Что касается ошибки шины, то как правило это связано с неправильной настройкой адресов или регистров.
Плюс есть такая фишка в CDS, если устройство долго не отвечает CDS его вообще исключает из опроса.

Поэтому нужно вводить дополнительный пересброс модуля.

Я делал пример для RS-485, думаю для TCP это правило тоже работает, пример смотрите тут:
http://www.owen.ru/forum/showthread. l=1#post118310

Добрый день.
Столкнулся с похожей проблемой.
Работаю с ПЛК304 (во вкладке информация версия 3.4.0.10). Среда Codesys V3.4 SP2 Hotfix 1. Добавляю Modbus COM (версия 3.4.0.0), затем добавляю Modbus Serial Device (версия 3.4.0.0), более ранних версий в списке нет.
Все успешно компилится, без ошибок и предупреждений. Однако при загрузке программы в ПЛК вижу сообщение что «Шина не запущена».

Как быть в данной ситуации?

Добрый день.
Столкнулся с похожей проблемой.
Работаю с ПЛК304 (во вкладке информация версия 3.4.0.10). Среда Codesys V3.4 SP2 Hotfix 1. Добавляю Modbus COM (версия 3.4.0.0), затем добавляю Modbus Serial Device (версия 3.4.0.0), более ранних версий в списке нет.
Все успешно компилится, без ошибок и предупреждений. Однако при загрузке программы в ПЛК вижу сообщение что «Шина не запущена».

Как быть в данной ситуации?

Читайте также: Шины для прицепа нлмк

Прошивка ПЛК расчтана на то , что по последовательным портам ПЛК будет мастером, используя стандартные устройства Codesys. потому у Вас и появляется окно, что шина не запущена. к Сожалению, чтобы сделать ПЛК слэйвом по последовательному порту, придётся работать через библиотеки по работе с портом.

Видео:Как исправить ошибку "Служба Base Filtering Engine (BFE) не запущена"Скачать

Как исправить ошибку "Служба Base Filtering Engine (BFE) не запущена"

Спк107 шина не запущена

Коллеги, ау! Может, все-таки, что-то посоветуете? Почитал форум и понял что ничего не понял. Какое-то жонглирование версиями библиотек, прошивок и таргетов, а где взять версии более старые? Или более новые? Или какие-то очень актуальные? Я архива,например, не вел, считая это ненужной, так же как и в кдс 2.3, затеей. Или получается «помоги себе сам», в этой весьма затейливой и малопонятной ситуации?

Я бы посоветовал сохранить проект в формате .projectarchive. Файл — Архив проекта — Сохранить/отправить архив.
Так проект сохраняется полностью включая установленные библиотеки. И в таком виде выложит на форум.
Может тогда кто то и поможет.

capzap
Дык интересно именно по ОВЕНу почитать данные. С модбасом-то понятно все

Доброе утро. Архив проекта прикреплен в первом посте темы («Test1_mv110.projectarchive») еще 3.12.2013. Проблему не решил, т.к. был в отпуске, но до отпуска все ухищрения ничего не дали.

Особо в Вашем проекте не разбирался, но обновил библиотеку OwenNet до версии 3,2,0 и все заработало.
Попробуйте.
11175

Особо в Вашем проекте не разбирался, но обновил библиотеку OwenNet до версии 3,2,0 и все заработало.
Попробуйте.
11175

аналогично, обновление до версии 3.2.0 решило проблему компиляции

Несмотря на то, что компилятор перестал ругаться, связь между СПК107 и МВ110-224.2АС по протоколу ОВЕН установить не удалось. Сразу скажу, что кабель нормальный, поскольку ничего не меняя в подключении приборов, по Модбасу все нормально работает. Еще интересный момент-при всем том, что связи между СПК и МВ нет, сетодиод «СОМ» на СПК моргает как ему и положено, а на МВ светодиод «RS485» не мигает совсем (при связи по Модбасу мигают и «СОМ» на СПК, и «RS485» на МВ). Не зная чего уже и думать, я решил вместо МВ110 поставить ТРМ101 с соответствующими изменениями в проекте. Получилось то же самое — сетодиод «СОМ» на СПК моргает, а на ТРМке светодиод «RS» молчит, связи соответственно тоже нет. Причем пробовал пользоваться функциями OWEN_GET_REAL и OWEN_UNI_IO — бесполезно. Короче, как-то все это странно. Подскажите пожалуйста, может кто в курсе проблемы? Архив проекта СПК107-ТРМ101 прилагается.

А в режиме конфигуратора вы портам выставили режим работы RS-485?
По умолчанию там 232 используется.

И момент второй.
До недавнего времени у нас в руководстве была не корректная схема контактов для RS-485.

Для RS-485 используются ноги 1 и 6.

Новую версию РЭ можно скачать тут:
http://www.owen.ru/uploads/re_spc1xx_1590.pdf

Новое РЭ будет поставляться в новых приборах, выпущенных после Новогодних праздников.

Добрый вечер, коллеги! После ряда экспериментов у меня появилась информация, которую, наверное, можно использовать в качестве пищи для размышлений. Когда я экспериментировал с модбасовским подключением модулей к СПК107, в какой-то момент я увидел надпись «Шина не запущена! Данные могут быть не актуальны». Действительно, данные были неверны. Однако светодиод СОМ исправно мигал. Но это не явилось проблемой, холодный перезапуск СПК все исправил. Да и не об этой ситуации речь, а о том, что при работе по ОВЕНу светодиод СОМ тоже исправно мигает, а связи нет. Так может это шина не запускается? Вообще кто-нибудь работоспособность библиотеки OwenNet проверял? Или проблема с компиляцией решилась и на том все проверки закончили? Если я неправ, то хотелось бы услышать где у меня косяки, архив проекта прикреплен (пара постов ранее).

Что то у Вас огород огородный.
Если Вы работаете через библиотеку, то, простите, откуда взялась шина?
Вы порты в таком случае через библиотеку должны открывать и закрывать.

Если даже вы обмен настроили через шину, предположим по протоколу Modbus, то если устройсто длительное время не отвечает, то CDS делает его неактивным, если на шине все устройства неактивны, то CDS говорит, что шина не активна.
Но даже в таком случае есть возможность программного перезапуска шины.

Так, что поразмыслить на самом деле есть над чем.

Да, я работаю через библиотеку. Я только предположил, что может быть при работе по ОВЕНу возникает ошибка, аналогичная незапуску шины при работе по Модбасу. Чтобы это ни было — факт налицо-светодиод СОМ мигает, связи нет вообще (соответствующий ФБ выдает ошибку 0хFFFF, ошибка тайм-аута). Порты открываются, и вообще я ничего экзотического не придумывал, а просто адаптировал пример из документации. Поэтому еще раз повторю вопрос: кто-нибудь работоспособность библиотеки OwenNet проверял? И если она вполне работоспособна, то что я делаю не так? Хотелось бы какой-то конкретики. Еще раз повторю, что кабель нормальный, порты в режиме RS485, по Модбасу все работает нормально.

Можете выложить актуальную версию проекта, попрошу ребят из поддержки решить вашу проблему. Сам по протоколу ОВЕН в CODESYS 3.5 еще не работал.

Видео:Видео 16. Работа по протоколу Modbus в режиме Slave в среде OwenLogicСкачать

Видео 16. Работа по протоколу Modbus в режиме Slave в среде OwenLogic

Спк107 шина не запущена

Вводные данные:
Codesys 3.5 SP5 Patch 2
СПК 107 прошивка 3.939
Таргет СПК107 3.5.4.20
Версия COM-устройства 3.4.0.0
Версия Master 3.5.4.0
Версия Slave 3.5.4.0

Итак, СПК107 должен через свой СОМ1 по 485 получить температуру с аналогового входа ПЛК150-M-U. На стороне ПЛК150 все настроено правильно, на стороне СПК все скорости, адреса и каналы тоже. Проблема заключается в абсолютно нестабильной работе шины. Соединение появляется только когда коннектишься с компа (начинает мигать СВЯЗЬ на СПК и отображаются нормальные значения). При пропадании питания связь не восстанавливается.
Знаю, что тема избитая, но я уже перепробовал все версии устройств и все настройки. Ничего не пашет. Ставлю Мастер 3.5.5.0 — стает активна галка АВТОРЕКОННЕКТ, ставлю ее, что-то поработет до первого чиха. Вот ведь не задача Мастер должен быть младше таргета СПК! Ставлю обратно Мастер на 3.5.4.0 галка стает недоступна и вообще ничего не восстанавливается при обрыве.

Вопросы:
1 Как настроить этот проект, чтобы добиться устойчивой связи?
2 Какую версию мастера мне можно использовать и как вообще обновлять/добавлять эти ModBus устройства?

Пробовал еще позавчера менять Задачи цикла шины как во вкладке ModBus Com, так и в ModBus Slave. Не помогает.

Все получилось, пока работет. Спасибо.

Не могли бы рассказать как устранили ошибку шины. У меня те же проблемы.

Симптомы следующие обмен не останавливается, модули принимают и получают значения от СПК, но СПК шлет в сеть одни и те же значения, не зависимо от того как они меняются в программе и отдает в управляющию программу те значения которые получил на момент зависания.

опачки. а это уже «косяк» среды исполнения / библиотеки мастера, а не пользовательской программы. Почему техподдержка ничего не ответила по проблеме? Пост старый, а проблемы остались, судя по всему те же в теме по подулям Mx110.

опачки. а это уже «косяк» среды исполнения / библиотеки мастера, а не пользовательской программы. Почему техподдержка ничего не ответила по проблеме? Пост старый, а проблемы остались, судя по всему те же в теме по подулям Mx110.

опаньки, а с чего это косяком стало непонятно что.
Например как понимать слова принимают и получают
Где описание диагностики неисправности, только выдергивание проводов? Почему не приходит в голову, что это в слейве остается последнее записанное в него значение и ни какой мастер ни чего не передает

опаньки, а с чего это косяком стало непонятно что.
Например как понимать слова принимают и получают
Где описание диагностики неисправности, только выдергивание проводов? Почему не приходит в голову, что это в слейве остается последнее записанное в него значение и ни какой мастер ни чего не передает

Диагностика есть озвученный результат анализа передаваемых данных. Сергей, Вам-таки приплачивают ? Мне, например, это приходит в голову.

Диагностика есть озвученный результат анализа передаваемых данных. Сергей, Вам-таки приплачивают ? Мне, например, это приходит в голову.

где эта диагностика, про цитируйте
мне не приплачивают, просто бесит когда с чьих то слов.делают какие то выводы, Вы хотябы смогли повторить у себя подобную ситуацию и получить такие же результаты

Симптомы следующие обмен не останавливается, модули принимают и получают значения от СПК, но СПК шлет в сеть одни и те же значения, не зависимо от того как они меняются в программе и отдает в управляющию программу те значения которые получил на момент зависания.
Если изучить тему: http://www.owen.ru/forum/showthread.php?t=21365
, и сопоставить «симптомы» каждой проблемы в отдельности, становится ясно, что другого более разумного объяснения описанных сбоев не найти. Очевидно, что контроллеры СПК не являются оборудованием для построения надежной связи по протоколу Modbus-RTU при использовании «мастера через конфигурацию» по причине недоработки. В Somachine (Sch. El.) практически такой же мастер (по интерфейсу настроек, а значит это часть инструментария Codesys, а не разработка Овен) и работает без каких-либо нареканий.
По-Вашему автор предполагает ситуацию, а не оперирует результатами диагностики? Это тоже Ваши догадки, не нужно им предавать такой вес.
А поскольку эта тема давно забыта, считаю необходимым своим собщением поднять ее наверх для актуальности. Возможно изготовитель обратит внимание на мое сообщение, и наконец-то проведет тесты с использованием инструментов анализа передаваемых данных, после чего сможет устранить проблему. По своему опыту могу судить, что подобные тесты вообще не проводятся изготовителем перед тем, как начать серийное производство.
http://www.owen.ru/forum/showthread.php?t=21139&p=169075&viewfull=1#post169075
В этой теме Ваши замечания и советы были бы очень актуальны.

Читайте также: Если увеличить профиль шины

У меня также есть основания предполагать, что за регулярно предлагаемые Вами кустарные, но по-Вашему очевидные решения, изготовитель предлагает выгодные условия. По-другому этот нездоровый яростный энтуазиазм ничем не объяснить.

Если изучить тему: http://www.owen.ru/forum/showthread.php?t=21365
, и сопоставить «симптомы» каждой проблемы в отдельности, становится ясно, что другого более разумного объяснения описанных сбоев не найти. Очевидно, что контроллеры СПК не являются оборудованием для построения надежной связи по протоколу Modbus-RTU при использовании «мастера через конфигурацию» по причине недоработки. В Somachine (Sch. El.) практически такой же мастер (по интерфейсу настроек, а значит это часть инструментария Codesys, а не разработка Овен) и работает без каких-либо нареканий.
По-Вашему автор предполагает ситуацию, а не оперирует результатами диагностики? Это тоже Ваши догадки, не нужно им предавать такой вес.
А поскольку эта тема давно забыта, считаю необходимым своим собщением поднять ее наверх для актуальности. Возможно изготовитель обратит внимание на мое сообщение, и наконец-то проведет тесты с использованием инструментов анализа передаваемых данных, после чего сможет устранить проблему. По своему опыту могу судить, что подобные тесты вообще не проводятся изготовителем перед тем, как начать серийное производство.
http://www.owen.ru/forum/showthread.php?t=21139&p=169075&viewfull=1#post169075
В этой теме Ваши замечания и советы были бы очень актуальны.

У меня также есть основания предполагать, что за регулярно предлагаемые Вами кустарные, но по-Вашему очевидные решения, изготовитель предлагает выгодные условия. По-другому этот нездоровый яростный энтуазиазм ничем не объяснить.

спокойствие только спокойствие
Разберем
а) работа мастера через конфигуратор:
добираемся до окошечка модбас-kaнал, ищем поле обработка ошибок, меняем с сохранить последнее значение на установить в ZERO, при получении каких то значений, но не нуля, убеждаемся что ошибок нет и мастер получает ответы на свои запросы корректно (кустарщины ни какой)
б) через библиотеку, получив комплит и error равный нулю убеждаемся что ошибок нет (кустарщины ни какой)
в) по поводу самой работы протокола: будете спорить о том, что для того чтоб увидеть изменение какого то параметра, мастер отправляет запросы слейву для чтения одного/двух регистров по фиксированному адресу? Думаю что нет. А теперь читаем автора
программа тоже получает какие то цифры, но реальности они уже не соответствуют.считаете что мастеру заняться нечем и он сам себе придумывает ответы и главное так ловко что и контрольную сумму правильно подбирает. Для таких случаев ставят снифер в сеть и доказывают наглядно логом что на отправленный набор байт приходит в качестве ответа правильный набор байт, а в программе байтовый буфер имеет совершенно другие значения. Вот это была бы диагностика,а не предположения. (тут какая кустарщина)
г) тоже самое и с записью в слейв
шлет в сеть одни и те же значения, не зависимо от того как они меняются в программе и отдает в управляющию программу те значения которые получил на момент зависанияа шлет ли, где доказательства. При отсутствии связи слейв в большинстве случаев сохраняет последнее значение, проверяется тем же снифером, который покажет что именно отправлялось и правильный ли ответ выдал слейв

По-Вашему автор предполагает ситуацию, а не оперирует результатами диагностики? Это тоже Ваши догадки, не нужно им предавать такой вес.я по моему как раз таки потребовал предоставить доказательства, а не делаю догадки из пустых разговоров

При этом если физически переподключить спк к RS-485, все оживает. А так ни галка автореконект ни программная перезагрузка слейвов не помогаетвот одно мое умозаключение, когда происходит реальный обрыв связи и последующее подключение, как раз таки галка реконнекта сработала и соединение заработало, всё остальное, пока не увидим творение в виде проекта, так называемое зависание может происходить из-за программы пользователя , а не мастера или слейвов

ЗЫ объекты которые я запускаю, работают на семене, овен это единичные случаи, так скажем раз в год может быть, поэтому улыбнуло Ваше предположение о выгодных условиях. Не буду отрицать у меня есть бесплатные образцы, взятые для тестирования, не знаю правда в чем тут выгода

Доброго дня. Внесу немного ясности. У меня обмен падает двумя способами

1. Штатно. Срабатывает триггера вида mu110_16k_50.xError. Значения при установке «установить в ZERO» устанавливаются в 0. Обмен с потерянным слейвом не идет. как следствие слейв может отработать аварию по таймауту. Выйти из этого можно либо при помощи галочки автореконект либо программно перегрузить слейв.

2. Не штатно. Флаг mu110_16k_50.xError не поднимается. Значения в 0 не падают. Слейвы продолжают получать запросы от мастера и отвечать ему. Но не в программе, не при онлайн режиме кдс актуальных ответов нет. Стоят последние цифры( сброс в 0 стоит). Перезагрузка слейвов не помогает. Опытным путем было найдено решение. В момент такой вот дурости мастера срабатывает флаг modbus_master_com_port.xAllSlavesOk. Как следствие как костыль было найдено такое решение

IF modbus_master_com_port.xAllSlavesOk=FALSE THEN
blink_01(enable:=TRUE,timelow:=T#6S, timehigh:=T#100MS,out=>);
ELSE
blink_01(enable:=FALSE,timelow:=T#6S, timehigh:=T#100MS,out=>);
END_IF
modbus_master_com_port.xResetComPort:=blink_01.OUT ;

Ошибки первого типа, достаточно часты. Причем зависят от загрузки панели(если включить экран со сложной визуализацией, то падает чаще). Но тут я сам виноват, в погоне за максимальной отзывчивость обмена, установил все задержки по минимуму.

Второго типа много реже. Пока вариант с перезагрузкой мастера не был найден, где то раз в два дня. Теперь я уже и не слежу.
Так оно и работает, практически круглосуточно уже скоро год. Кратковременная потеря связи для меня не особа критична. На этой панели на одном com порту крутится 14 каналов нагрева и охлаждения экструдера, на втором управление инверторами митсу. Но для себя я сделал вывод что использовать связку модули+СПК для управления механизмами где критична реакция на событие я не стану.

Я не занимаюсь профессионально ПЛК. Просто год назад на предприятие где я главный инженер выгорел родной проприетарный контроллер, и необходимо было в кротчайшие сроки восстановить оборудование. В самописной библиотеке для управления инверторами(там не модбас) вообще нет обработчика ошибок и не разу и не пригодился, все и так работает,а тут прям беда и напасть. Хотя я вполне допускаю что мне досталась просто больная панель.

Штатно. Срабатывает триггера вида mu110_16k_50.xError. Значения при установке «установить в ZERO» устанавливаются в 0. Обмен с потерянным слейвом не идет. как следствие слейв может отработать аварию по таймауту. Выйти из этого можно либо при помощи галочки автореконект либо программно перегрузить слейвto spectrum48k Ну, ноль же, значит нет ни какого зависания и ошибки обрабатываются.
Вот тут особенно важно посмотреть снифером что приходит или не приходит от слейва, главное это второй и третий байты, конечно за одно убедится что запрос отправлен

Не штатно. дурость контроллера можно победить более коротким способом, как мне кажется кустарщику, например модуль 8А взять, считывая измерение кaнaла захватывать циклическое время измерения, при каждом опросе оно гарантировано должно изменятся, так что такая слепота вычисляется уже при следующем запросе

[I]
дурость контроллера можно победить более коротким способом, как мне кажется кустарщику, например модуль 8А взять, считывая измерение кaнaла захватывать циклическое время измерения, при каждом опросе оно гарантировано должно изменятся, так что такая слепота вычисляется уже при следующем запросе

Можно. Но ввиду отсутствия дискретных выходов у панели. Кроме как стоять и мигать экраном она ничего не может, исполнительные механизмы так и продолжают работать, что меня первый раз в шок повергло(температура тогда, успела с 200 градусов уползти до 240, хорошо все обошлось без последствий. Вот тут мне кажется сильно не хватает в спк одного релейного выхода, который.в случае чего смог бы обеспечить аварийный останов. Была даже мысль разобрать и сделать релейный выход вместо пищалки, но так руки и не дошли. Вообще мне кажется, раз уж это СПК, а не просто панель, то хотя бы одна «живая рука» должна быть

Читайте также: Шины 104h что значит

to spectrum48k Ну, ноль же, значит нет ни какого зависания и ошибки обрабатываются.
Вот тут особенно важно посмотреть снифером что приходит или не приходит от слейва, главное это второй и третий байты, конечно за одно убедится что запрос отправлен

Имеется ввиду до аварии? Тогда скажу так АС4 ничего патологического не видет. Мастер отправил корректный запрос, слейв корректно ответил и все. Но возможно АС4 обладает банально лучшим трактом RS-485, и может корректно считать данные с шины а спк нет?. Потому что такое пропадание связи целиком и полностью связанно с помехами, при их отсутствие проблем не наблюдал.
Ну а после авраии тишина там, мастер молчит, слейв тоже. Соответственно модули с дискретными выходами могут отработать авраию по тайм ауту. И так пока все это не перезапустить.

Имеется ввиду до аварии? Тогда скажу так АС4 ничего патологического не видет. Мастер отправил корректный запрос, слейв корректно ответил и все. Но возможно АС4 обладает банально лучшим трактом RS-485, и может корректно считать данные с шины а спк нет?. Потому что такое пропадание связи целиком и полностью связанно с помехами, при их отсутствие проблем не наблюдал.
Ну а после авраии тишина там, мастер молчит, слейв тоже. Соответственно модули с дискретными выходами могут отработать авраию по тайм ауту. И так пока все это не перезапустить.

Вы называли два вида аварийной ситуации, второй случай когда приходят «неправильные» ответы, что наблюдаете через АС-4 тишину или те самые пакеты?
Я уже написал про метки времени, считывайте их сравнивайте с предыдущим значением и пересбрасывайте порт

ЗЫ какая витая пара используется, экранированная ли, заземлена ли она?

Вы называли два вида аварийной ситуации, второй случай когда приходят «неправильные» ответы, что наблюдаете через АС-4 тишину или те самые пакеты?

ЗЫ какая витая пара используется, экранированная ли, заземлена ли она?

Второй вариант «послушать» не получилось. Но обмен идет, мастер последовательно опрашивает слейвы. И слейвы получают уставку от мастера. Речь идет о уставки шим и она не меняется все время пока СПК в такой вот прострации.
Витая пара не экранированная

Я уже написал про метки времени, считывайте их сравнивайте с предыдущим значением и пересбрасывайте порт

Я на это отвечал выше, но это костыль. Тогда уж надо подставить второй костыль и заменить модули вывода на ПР или ПЛК и если от СПК долго идут одни и те же данные, передернуть питание СПК. Но зачем вообще в этой схеме тогда СПК?

Но зачем вообще в этой схеме тогда СПК?
? так это Вас надо спросить, зачем такую панель взяли, можно было обойтись плк160 и любую чисто-панель от других производителей, не достающие входы/выходы через модуля на которые посадить второстепенные датчики и ИМ

to spectrum48k Ну, ноль же, значит нет ни какого зависания и ошибки обрабатываются.
Вот тут особенно важно посмотреть снифером что приходит или не приходит от слейва, главное это второй и третий байты, конечно за одно убедится что запрос отправлен

дурость контроллера можно победить более коротким способом, как мне кажется кустарщику, например модуль 8А взять, считывая измерение кaнaла захватывать циклическое время измерения, при каждом опросе оно гарантировано должно изменятся, так что такая слепота вычисляется уже при следующем запросе

никакое плохое качество физического уровня не объясняет природу ошибки из второго варианта. Это самая опасная ситуация, когда управляющее воздействие слишком велико (интенсивность нагрева/задание частоты ПЧ) и может привести к аварийным ситуациям и материальному ущербу. Посколько сброс теперь происходит автоматически и объект давно в работе, снять данные с порта скорее всего не представляется возможным? Очень жаль. Мое мнение не поменялось. СПК не является надежным устройством для связи. Автосброс это лишь очередной костыль, да-да, костыль, не кустарщина, согласен. Кустарщина в других ветках форума. ))

? так это Вас надо спросить, зачем такую панель взяли, можно было обойтись плк160 и любую чисто-панель от других производителей, не достающие входы/выходы через модуля на которые посадить второстепенные датчики и ИМ

Если вам действительно интересно: ?

1. Опыта с плк нет, а нужно восстановить оборудование ибо заказы стоят. Поэтому выбор пал на овен. Он, в наличие в городе+большой русскоязычный форум. Надеялся что будет проще разобраться
2. Второстепенных входов\выходов нет. Нужно 10 аналоговых входов, 14 выходов на ттр и один свободный порт для инверторов. Как следствие связка плк+панель не подходит, нужны еще модули. Ну а дальше кривая вывернула на СПК+4 модуля. Вариант ПЛК+панель+модули, показался сложнее.

ну не бывает так, цена устройства относительно низкая, а комплектующие из топовой серии.

Стоимость rs-485 драйвера в ценообразование СПК мне видеться крайне низкой.

Так к слову, значит вина КЛС-овского мастера не доказана?
Кем не доказана? мной? Так я и задачу такую никогда не ставил, у меня возникла проблема, в процессе поиска было найдено какое-никакое решение, я озвучил обстоятельства и проблему как мог. А сидеть сутками в шкафу и искать момент ошибки снифиром? Что мне это даст. я считаю что оборудование так работать не должно и точка. На этом считаю свою миссию полностью выполненной. Поиском остальных виноватых как мне кажется надо бы овену заниматься. Это у него раз в неделю, на форуме, всплывает тема про проблемы со связью.

А сидеть сутками в шкафу и искать момент ошибки снифиром? Что мне это дастя имел ввиду сбор логов в файл, чтоб потом можно было проанализировать в какой момент времени это произошло, ни кто же не мешает собирать так же включение других механизмов, раз грешите на частотники

плк160 имеет на борту как дискретные так и аналоговые входы/выходы, на них можно было бы прицепить что наиболее важно и чувствительно к пропаданию связи, остальное на модули. Панель, если не придираться к красоте картинки, из бюджетных вариантов подошла бы ИП320. Сейчас еще появился такой прибор, как ПР200
понятно что сейчас уже ни чего не изменить, но как бы наличие форума не означает, что изучить предмет стоило бы повнимательнее. Возьмите хотя бы профибасный кабель от семена, может поможет справиться с помехами

Это экструдер с выдувной головой в нем полторы тонны разогретого металла по которому движется расплав полиэтилена при давление 25 атм и температурой 200 градусов. Состоит из десяти зон нагрева общей мощностью 60 кВт и четырех зон охлаждения. Нет там не чувствительных к пропаданию связи мест. Если массу не разогреть и попытаться запустить шнековый пресс давление уходит в небеса, что способно натворить не мало дел.Если перегреть начнется деструкция материала, если перегреть сильно поплывут прокладки из коксанаполеного фторопласта. Они мало того что денег стоят, так и чтобы поменять их надо разобрать практически все, что само по себе неделю удовольствия. Вопрос финансов так остро не стоял, можно было бы и в два раза дороже взять. Вопрос времени и моего отсутствия опыта в программирование плк, тут овен с кдс показался оптимален.

ИП320 сейчас в связке в делтой прилаживаю вместо еще одной тайваньской платы(тут сильно не нравится штатный функционал)
ПР200 есть, спасибо овену за образец. Но пока беда с софтом, ждет своего часа.

За кабель спасибо, но мне кажется мы сильно ушли от темы.

я имел ввиду сбор логов в файл, чтоб потом можно было проанализировать в какой момент времени это произошло, ни кто же не мешает собирать так же включение других механизмов, раз грешите на частотники

Частотники не включаются, они работают всегда).

Вроде заработало. Разберусь окончательно, отпишусь.

В моем случае проблема со связью возникала тогда, когда я пользовался в конфигураторе каналом «Read/Write Multiple Registers (Код функции 23)». Видимо, функцию 23 не поддерживает ПЛК110 (у меня СПК207-мастер опрашивал ПЛК110-слейв). После того как я создал 2 канала один «Read Holding registers (Код функции 03)», второй «Write Multiple Registers (Код функции 16)», которые ссылались на одни и те же регистры, связь заработала стабильно.

  • Свежие записи
    • Нужно ли менять пружины при замене амортизаторов
    • Скрипят амортизаторы на машине что делать
    • Из чего состоит стойка амортизатора передняя
    • Чем стянуть пружину амортизатора без стяжек
    • Для чего нужны амортизаторы в автомобиле


    🎥 Видео

    3. Использование модулей ввода/вывода Mx110Скачать

    3.  Использование модулей ввода/вывода Mx110

    Овен СПК 107 работа с COM1 подключение второго модуля МВ110-32ДНСкачать

    Овен СПК 107 работа с COM1 подключение второго модуля МВ110-32ДН

    Семинар и мастер-класс «Программируемые реле ОВЕН ПР». Часть 1.Скачать

    Семинар и мастер-класс «Программируемые реле ОВЕН ПР». Часть 1.

    Овен СПК 107 программа "перелистывания" визуализацийСкачать

    Овен СПК 107 программа "перелистывания" визуализаций

    Owen ОРС ServerСкачать

    Owen ОРС Server

    Видео 5. Подключение модулей Мх210 в среде программирования CODESYS v3.5Скачать

    Видео 5. Подключение модулей Мх210 в среде программирования CODESYS v3.5

    Ошибка 61(не видит акб или нет связи с BMS) при подключении инвертора AxiomaEnergy и акб Pylontech.Скачать

    Ошибка 61(не видит акб или нет связи с BMS) при подключении инвертора AxiomaEnergy и акб Pylontech.

    СПК. Подключение ПЧВ через шаблоны (съемка экрана)Скачать

    СПК. Подключение ПЧВ через шаблоны (съемка экрана)

    Настройка Modbus Slave в системе Телемеханика ЛайтСкачать

    Настройка Modbus Slave в системе Телемеханика Лайт

    ОВЕН СПК1xx. Подключение модулей ОВЕН Мх110 и Мх210Скачать

    ОВЕН СПК1xx. Подключение модулей ОВЕН Мх110 и Мх210

    Cs-Cs: Щит котельной в Папушево на ОВЕН СПК110, часть 1: Тест периферииСкачать

    Cs-Cs: Щит котельной в Папушево на ОВЕН СПК110, часть 1: Тест периферии

    Подключение частотника Кастон к ПР200 по интерфейсу RS-485Скачать

    Подключение частотника Кастон к ПР200 по интерфейсу RS-485

    3. Прием и отправка траповСкачать

    3. Прием и отправка трапов

    Протокол MODBUSСкачать

    Протокол MODBUS
Поделиться или сохранить к себе:
Технарь знаток