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

[spectrum48k]

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

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

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

[capzap]

Если изучить тему: 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, все оживает. А так ни галка автореконект ни программная перезагрузка слейвов не помогает

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

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