Я ещё руководству не говорил что при потери соединения slave (частотники) остаются в последнем состоянии. Надо переделывать под дискрету управление
Я ещё руководству не говорил что при потери соединения slave (частотники) остаются в последнем состоянии. Надо переделывать под дискрету управление
Комментарии: 21
Evgeniy
У Danfoss нет контроля связи по сети?
Aleksey
Нет
Evgeniy
Вот это хлам))
Maksim
Не баг, а фича ©
Aleksey
Благодоря этому, я смог на работающей учтоновке экспериментировать с сетью
Alexey
там дело не в контроле сети, а в том что интерфейс обслуживается по низшему приоритету. в итоге все тайминги плавают хаотически
Kirill
Есть, но оно предельно косое
Evgeniy
Алтивары четко отрабатывают Вот это самые матерые машины что касается сетевых коммуникаций и сервисов
Kirill
Жирный жир
Evgeniy
Я так и не нашел достойной альтернативы в Китае Да и у других европейцев в то время ничего подобного не было
Aleksey
Я ещё знаете че встретил, при просадке иногда обмен останавливается на одном устройстве, и нет подтверждения или ошибки обмена. Пришлось таймер корячить, что если за определённое время не обменялся с устройством, переводить обмен на несуществующее устройство. После чего выходит ошибка обмена, и возврат обратно в обмен с существующими slave Мне кажется Сименс и модбас не очень идут. Работал с дельтой, ваще проблем не было Кстати, кто то пользовался контроллерами от EKF?
Anonim
А сетевые адреса на повторяются случаем? Какими? Фото, ссылку
Jury
Да
Evgeniy
Как говорится, главная проблема в прокладке между рулем и сидением
Zoo35
Кстати он в чем-то прав. Недавно думал, почему у 1200 модбас такой медленный. Если кто-то объяснит подробнее буду благодарен, ибо в поиске не нашёл. Почему после выполнения MB_Master я должен пропустить один цикл, чтобы сбросился бит done прежде, чем опросить второе устройство?
Evgeniy
Не помню что там у SI, но скорее всего чтобы организовать задержку между фреймами, по стандарту не менее 3.5 символов. Я обычно 10мс использую для скорости 19200 А так конечно прав, хороший отлаженный конфигуратор/сканнер, где большинство процессов автоматизировано или колупаться в библиотечных блока и выстраивать обмен в ручную
Gabrrr
Ты новый реквест не должен посылать, пока старая телеграмма не отработала. Порт то физически занят. А узнаешь ты это по done или error
Zoo35
В том и дело, что done это ж конец запроса, что всё чётко и блок отработал. Видим done, затем обрабатываем данные. Но далее мы не переходим на следующий slave и не ставим req. Мы просто пропускаем цикл, чтобы бит сбросился и только в следующем цикле начинаем новый опрос. Имею ввиду, что модуль коммуникации простаивает в это время. А может я просто не понимаю чего-то.
Maksim
А где то этот пункт прям в ТЗ указывают: "при потери связи со слейвом оставить слейв в последнем состоянии". И эта фича данфоса сыграла на руку)
Anonim
И что нет состояния при потере связи? Как у нормальных ЧП.
Aleksey
Нету