опаньки, а с чего это косяком стало непонятно что.
Например как понимать слова принимают и получают
Где описание диагностики неисправности, только выдергивание проводов? Почему не приходит в голову, что это в слейве остается последнее записанное в него значение и ни какой мастер ни чего не передает
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Вроде заработало. Разберусь окончательно, отпишусь.
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Если изучить тему: http://www.owen.ru/forum/showthread.php?t=21365
, и сопоставить "симптомы" каждой проблемы в отдельности, становится ясно, что другого более разумного объяснения описанных сбоев не найти. Очевидно, что контроллеры СПК не являются оборудованием для построения надежной связи по протоколу Modbus-RTU при использовании "мастера через конфигурацию" по причине недоработки. В Somachine (Sch. El.) практически такой же мастер (по интерфейсу настроек, а значит это часть инструментария Codesys, а не разработка Овен) и работает без каких-либо нареканий.
По-Вашему автор предполагает ситуацию, а не оперирует результатами диагностики? Это тоже Ваши догадки, не нужно им предавать такой вес.
А поскольку эта тема давно забыта, считаю необходимым своим собщением поднять ее наверх для актуальности. Возможно изготовитель обратит внимание на мое сообщение, и наконец-то проведет тесты с использованием инструментов анализа передаваемых данных, после чего сможет устранить проблему. По своему опыту могу судить, что подобные тесты вообще не проводятся изготовителем перед тем, как начать серийное производство.
http://www.owen.ru/forum/showthread....l=1#post169075
В этой теме Ваши замечания и советы были бы очень актуальны.
У меня также есть основания предполагать, что за регулярно предлагаемые Вами кустарные, но по-Вашему очевидные решения, изготовитель предлагает выгодные условия. По-другому этот нездоровый яростный энтуазиазм ничем не объяснить.
спокойствие только спокойствие
Разберем
а) работа мастера через конфигуратор:
добираемся до окошечка модбас-kaнал, ищем поле обработка ошибок, меняем с сохранить последнее значение на установить в ZERO, при получении каких то значений, но не нуля, убеждаемся что ошибок нет и мастер получает ответы на свои запросы корректно (кустарщины ни какой)
б) через библиотеку, получив комплит и error равный нулю убеждаемся что ошибок нет (кустарщины ни какой)
в) по поводу самой работы протокола: будете спорить о том, что для того чтоб увидеть изменение какого то параметра, мастер отправляет запросы слейву для чтения одного/двух регистров по фиксированному адресу? Думаю что нет. А теперь читаем авторасчитаете что мастеру заняться нечем и он сам себе придумывает ответы и главное так ловко что и контрольную сумму правильно подбирает. Для таких случаев ставят снифер в сеть и доказывают наглядно логом что на отправленный набор байт приходит в качестве ответа правильный набор байт, а в программе байтовый буфер имеет совершенно другие значения. Вот это была бы диагностика,а не предположения. (тут какая кустарщина)программа тоже получает какие то цифры, но реальности они уже не соответствуют.
г) тоже самое и с записью в слейва шлет ли, где доказательства. При отсутствии связи слейв в большинстве случаев сохраняет последнее значение, проверяется тем же снифером, который покажет что именно отправлялось и правильный ли ответ выдал слейвшлет в сеть одни и те же значения, не зависимо от того как они меняются в программе и отдает в управляющию программу те значения которые получил на момент зависания
я по моему как раз таки потребовал предоставить доказательства, а не делаю догадки из пустых разговоровПо-Вашему автор предполагает ситуацию, а не оперирует результатами диагностики? Это тоже Ваши догадки, не нужно им предавать такой вес.
вот одно мое умозаключение, когда происходит реальный обрыв связи и последующее подключение, как раз таки галка реконнекта сработала и соединение заработало, всё остальное, пока не увидим творение в виде проекта, так называемое зависание может происходить из-за программы пользователя , а не мастера или слейвовПри этом если физически переподключить спк к RS-485, все оживает. А так ни галка автореконект ни программная перезагрузка слейвов не помогает
ЗЫ объекты которые я запускаю, работают на семене, овен это единичные случаи, так скажем раз в год может быть, поэтому улыбнуло Ваше предположение о выгодных условиях. Не буду отрицать у меня есть бесплатные образцы, взятые для тестирования, не знаю правда в чем тут выгода
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Доброго дня. Внесу немного ясности. У меня обмен падает двумя способами
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 каналов нагрева и охлаждения экструдера, на втором управление инверторами митсу. Но для себя я сделал вывод что использовать связку модули+СПК для управления механизмами где критична реакция на событие я не стану.
Я не занимаюсь профессионально ПЛК. Просто год назад на предприятие где я главный инженер выгорел родной проприетарный контроллер, и необходимо было в кротчайшие сроки восстановить оборудование. В самописной библиотеке для управления инверторами(там не модбас) вообще нет обработчика ошибок и не разу и не пригодился, все и так работает,а тут прям беда и напасть. Хотя я вполне допускаю что мне досталась просто больная панель....
to spectrum48k Ну, ноль же, значит нет ни какого зависания и ошибки обрабатываются.Штатно. Срабатывает триггера вида mu110_16k_50.xError. Значения при установке "установить в ZERO" устанавливаются в 0. Обмен с потерянным слейвом не идет. как следствие слейв может отработать аварию по таймауту. Выйти из этого можно либо при помощи галочки автореконект либо программно перегрузить слейв
Вот тут особенно важно посмотреть снифером что приходит или не приходит от слейва, главное это второй и третий байты, конечно за одно убедится что запрос отправлен
дурость контроллера можно победить более коротким способом, как мне кажется кустарщику, например модуль 8А взять, считывая измерение кaнaла захватывать циклическое время измерения, при каждом опросе оно гарантировано должно изменятся, так что такая слепота вычисляется уже при следующем запросеНе штатно...
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Можно. Но ввиду отсутствия дискретных выходов у панели. Кроме как стоять и мигать экраном она ничего не может, исполнительные механизмы так и продолжают работать, что меня первый раз в шок повергло(температура тогда, успела с 200 градусов уползти до 240, хорошо все обошлось без последствий. Вот тут мне кажется сильно не хватает в спк одного релейного выхода, который.в случае чего смог бы обеспечить аварийный останов. Была даже мысль разобрать и сделать релейный выход вместо пищалки, но так руки и не дошли. Вообще мне кажется, раз уж это СПК, а не просто панель, то хотя бы одна "живая рука" должна быть
Последний раз редактировалось artvhm; 01.10.2015 в 08:07.