У большинства ПЧ есть параметр минимальный таймаут обмена, а так же параметр определяющий поведение ПЧ при превышении этого таймаута. Мне кажется, что отправлять задание лучше с той частотой, с какой позволяет ПЛК. А вот если, наоборот, в назначенной время очередная команда не пришла на ПЧ, то принимать меры. У меня ПЧ останавливаются через 2 секунды.
Спасибо.
Таймаут ПЧ - это другое. Может быть еще с этим столкнусь.
А здесь, рассуждаю с позиции программиста. Modbus работает медленней цикла ПЛК. ПЛК позволяет нам каждый цикл менять исходящие переменные. Не будет это выглядеть так, что каждую итерацию я буду менять значение выходной modbus-переменной. И каждое из этого множества значений, вроде как забъется в буфер к отправке, допустим ограниченного размера, но все же неприятно. И будет тянуться этот хвост запоздалых значений.
Вы определитесь, через конфигурацию или через библиотеку. Если первое то по какому варианту Вы собрались посылать управляющие пакеты боясь что мастер захлебнется, документацию читали или методом тыка программируетеСообщение от программист_с_паяльником
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Через конфигурацию.
Если вы про Work mode (poll time, value change, и т.д.), вроде вопросов нет.
При использовании отправки "при изменении значения", если не сдерживать мастера, есть риск создать, вроде как, очередь заданий к отправке, в которой более ранние задания уже неактуальны.
Или же, может, если отправка еще не выполнена, то новое значение его затирает? Это было бы очень хорошо.
В противном случае, нужно контролировать частоту отправки заданий в modbus-сеть.
capzap, благодарю. Практика покажет, что получится
На счет этого не беспокойтесь. Пока очередь до этого параметра не дошла ОС ПЛК даже не взглянет на нее. Можете сколько угодно раз менять и использовать ее внутри цикла. Главное чтобы в конце цикла значение параметра определяло именно то, что возможно может быть принято к передаче через порт. А возможность передачи ОС определяет сама в соответствии со своими внутренними алгоритмами.
Ваши слова, в многом, бальзам на душу.
В конце 1-го цикла я выдам значение modbus-переменной к отправке. А в конце 2-го цикла, уже немного другое значение этой же переменной. Допустим, по истчении 2-го цикла, значение modbus-переменной, заданное в 1-ом цикле, так и не была отправлено. Но уже есть новое задание и значение modbus-переменной скорректировано, хотя за 1 цикл ПЛК врят ли для этого возникнут предпосылки извне.
Мне видится это следующим образом:
- нужно фиксировать время цикла плк (допустим 200 мс или сколько там получится);
- направлять задания в модбас раз в цикл или, если все будет плохо, реже.
Ерунду пишите, цикл ПЛК может быть 1-3-10 ms, а передача каждые 20-200 ms, как зададите. Никакой буфер не забьётся. Конфигурация спокойно справится. И библиотека тоже.
На вашем месте, лучше задаться вопросом, как бороться с помехами от частотников. Нужен комплекс мер, по экранированию проводов, заземлению, разнесение силовых кабелей и измерительных (управляющих) проводов, резисторы 120 Ом по сети RS485, помехи по питающей сети и т. д.
Последний раз редактировалось kondor3000; 17.03.2023 в 16:35.
kondor3000, спасибо за ответ.
Что касается помех от ПЧ, это да.
Для двигателей, ПЧ - больше зло, чем добро.
ПЛК может начать передачу значения из переменной в любой момент (хоть на 200-м цикле)
да и передавать его он может несколько циклов подряд (Slave не ответил, будут повторы в передаче и т.д. и т.п.)
поэтому хоть тысячу раз за цикл меняйте, ПЛК сам в нужный ему момент заберет и отправит
даже когда стоит режим "По изменению", а к моменту как придет очередь, и значение будет таким же как при прошлой передаче, ПЛК не будет его передавать, хотя несколько циклов подряд значение переменной менялось
Последний раз редактировалось EFrol; 17.03.2023 в 16:32.
Ваши права
Ответить с цитированием