правда конечно у меня библиотека была серым цветом. установил заново, пока что дольше обычного работает.
правда конечно у меня библиотека была серым цветом. установил заново, пока что дольше обычного работает.
Ахтунг!
Для тех, кто так же как и я поимел проблемы с нестабильной работой 485 интерфейса, подтверждаю - приведённые в цитате версии таргетов и библиотек нормально работают. Т.е. слейвы перезапускаются как положено. Переменные срабатывают как нужно.
Другие варианты версий мастера и слейвов имеют те или иные проблемы (у меня). Набор проблем изменяется в зависимости от набора версий!
Подскажите, где посмотреть коды ошибок xError и byModbusError?
Если еще не разобрались то МВА8 с групповым запросом и МВУ-И вместе не работают. СПК тут не причем, проблема в МВУ-И. Способ лечения - разбивать групповой запрос на МВА8 на 2..3 части.
Столкнулся с такой-же проблемой: ошибки RESPONSE_TIMEOUT и RESPONSE_WRONG_SLAVE. Сначала меня это не сильно беспокоило, поскольку ошибок было не много. Потом случился незаметный обрыв витой пары, в результате легла вся сеть и все 16 устройств отвечали ошибкой RESPONSE_WRONG_SLAVE.
Сначала я попробовал выяснить что не так с передачей данных непосредственно на линии rs485, для этого подключился к ней с помощью китайского преобразователя rs485-usb и терминала: как ни странно передача и ответ были полностью корректными и никаких посторонних данных в линии не наблюдалось.
Поскольку на линии всё казалось исправным, решил поиграть с версиями библиотек - результат нулевой. Плюнул, решил реализовать функционал IoDrvModbus самостоятельно и работать с библиотекой SysCom напрямую, чтобы было видно что работает не так. Спустя несколько часов, библиотека была готова и тут выяснилось, что перед каждым ответом от устройства принимается несколько байт со значением 0xff, именно на них IoDrvModbus ругается RESPONSE_WRONG_SLAVE, хотя я в этом случае почему-то ожидал RESPONSE_CRC_FAIL или что-то подобное.
Далее я решил просто читать все данные приходящие на COM порт, при этом ничего не отправляя. Трудно передать моё удивление когда я увидел, что ПЛК исправно принимает непрерывный поток данных, сожержащих 0xff в количестве примерно 10 байт в секунду. Причём поток этот прекращался, если отключить шину rs485 от контроллера.
После такого разворота событий ничего не оставалось кроме как исследовать внутренности ПЛК, ведь китайский преобразователь, да и другие устройства на шине не видели никаких лишних данных на шине и исправно работали. После некоторого времени с помощью осциллографа и мультиметра был найден главный виновник: микросхема 75176B, после замены которой на max485 поток мусора в COM порт иссяк.
Сразу же после этой модификации стало очевидно, что шина rs485 оборвана и место обрыва быстро удалось найти. Причиной мгогократно услилившегося потока мусора в сети послужил тот факт, что на оборванном конце шины отсутствовал терминальный резистор.
Всем привет,подскажите пожалуйста,как связать ПЧ на прямую с панелью ОВЕН СПК 107, как это вообще все делается? Знаю только,что по Modbus как-то.
Вам наверно в ветку про ПЧВ. И задавайте вопрос конкретнее, или так и пишите: "Сделайте за меня все".
http://www.owen.ru/uploads/rp_pcv_ver_06.pdf Приложение В вам в помощь.
Да нет,делать за меня ничего не надо, я сам хочу в этом разобраться. Только вот у меня ПЧ TWERD, а не ОВЕН. И еще один вопрос, можно ли это сделать в CODESYS?
готов удаленно через TeamViewer помочь за небольшое вознаграждение