Буду управлять по Modbus RTU разными ПЧ одного номинала мощности при помощи ПЛК150

[программист_с_паяльником]

Здравствуйте.

Есть ПЛК150 и несколько разных ПЧ одинаковой мощности (все Modbus-протоколы "на руках").
Собираюсь задавать частоту работы на каждый ПЧ по Modbus RTU.
ПЛК - мастер, ПЧ - слейвы. Программа на ST.
Modbus собираюсь настроить через Конфигурацию ПЛК Codesys. Разумеется, если все пойдет нормально, оставлю как есть (т.е. внешнюю modbus-библиотеку использовать не буду).

Поскольку опыта в этом мало, возник вопрос: Насколько часто можно отправлять задание с рассчитанной частотой (Гц) по modbus rtu?

Кажется, очевидным, не стоит этого делать каждый цикл ПЛК.

Наверное, логично привязаться к моментам изменения аналоговых входов 4-20 мА, а у ПЛК150 они достаточно медленные - минимальный интервал измерений 0,8 сек. Таким образом, при получении нового (отличающегося от предыущего) значения с аналогового входа выполнять расчет выходной частоты ПЧ и только тогда посылать её на ПЧ через modbus.

Заранее благодарен.

[EFrol]

У большинства ПЧ есть параметр минимальный таймаут обмена, а так же параметр определяющий поведение ПЧ при превышении этого таймаута. Мне кажется, что отправлять задание лучше с той частотой, с какой позволяет ПЛК. А вот если, наоборот, в назначенной время очередная команда не пришла на ПЧ, то принимать меры. У меня ПЧ останавливаются через 2 секунды.

[программист_с_паяльником]

Спасибо.

Таймаут ПЧ - это другое. Может быть еще с этим столкнусь.

А здесь, рассуждаю с позиции программиста. Modbus работает медленней цикла ПЛК. ПЛК позволяет нам каждый цикл менять исходящие переменные. Не будет это выглядеть так, что каждую итерацию я буду менять значение выходной modbus-переменной. И каждое из этого множества значений, вроде как забъется в буфер к отправке, допустим ограниченного размера, но все же неприятно. И будет тянуться этот хвост запоздалых значений.

[capzap]

Спасибо.

Таймаут ПЧ - это другое. Может быть еще с этим столкнусь.

А здесь, рассуждаю с позиции программиста. Modbus работает медленней цикла ПЛК. ПЛК позволяет нам каждый цикл менять исходящие переменные. Не будет это выглядеть так, что каждую итерацию я буду менять значение выходной modbus-переменной. И каждое из этого множества значений, вроде как забъется в буфер к отправке, пусть и ограниченного размера, но все же неприятно. И будет тянуться этот хвост запоздалых значений.

Вы определитесь, через конфигурацию или через библиотеку. Если первое то по какому варианту Вы собрались посылать управляющие пакеты боясь что мастер захлебнется, документацию читали или методом тыка программируете

[EFrol]

Спасибо.

Таймаут ПЧ - это другое. Может быть еще с этим столкнусь.

А здесь, рассуждаю с позиции программиста. Modbus работает медленней цикла ПЛК. ПЛК позволяет нам каждый цикл менять исходящие переменные. Не будет это выглядеть так, что каждую итерацию я буду менять значение выходной modbus-переменной. И каждое из этого множества значений, вроде как забъется в буфер к отправке, допустим ограниченного размера, но все же неприятно. И будет тянуться этот хвост запоздалых значений.

На счет этого не беспокойтесь. Пока очередь до этого параметра не дошла ОС ПЛК даже не взглянет на нее. Можете сколько угодно раз менять и использовать ее внутри цикла. Главное чтобы в конце цикла значение параметра определяло именно то, что возможно может быть принято к передаче через порт. А возможность передачи ОС определяет сама в соответствии со своими внутренними алгоритмами.

[программист_с_паяльником]

Вы определитесь, через конфигурацию или через библиотеку. Если первое то по какому варианту Вы собрались посылать управляющие пакеты боясь что мастер захлебнется, документацию читали или методом тыка программируете

Через конфигурацию.
Если вы про Work mode (poll time, value change, и т.д.), вроде вопросов нет.
При использовании отправки "при изменении значения", если не сдерживать мастера, есть риск создать, вроде как, очередь заданий к отправке, в которой более ранние задания уже неактуальны.
Или же, может, если отправка еще не выполнена, то новое значение его затирает? Это было бы очень хорошо.
В противном случае, нужно контролировать частоту отправки заданий в modbus-сеть.

[программист_с_паяльником]

На счет этого не беспокойтесь. Пока очередь до этого параметра не дошла ОС ПЛК даже не взглянет на нее. Можете сколько угодно раз менять и использовать ее внутри цикла. Главное чтобы в конце цикла значение параметра определяло именно то, что возможно может быть принято к передаче через порт. А возможность передачи ОС определяет сама в соответствии со своими внутренними алгоритмами.

Ваши слова, в многом, бальзам на душу.
В конце 1-го цикла я выдам значение modbus-переменной к отправке. А в конце 2-го цикла, уже немного другое значение этой же переменной. Допустим, по истчении 2-го цикла, значение modbus-переменной, заданное в 1-ом цикле, так и не была отправлено. Но уже есть новое задание и значение modbus-переменной скорректировано, хотя за 1 цикл ПЛК врят ли для этого возникнут предпосылки извне.
Мне видится это следующим образом:
- нужно фиксировать время цикла плк (допустим 200 мс или сколько там получится);
- направлять задания в модбас раз в цикл или, если все будет плохо, реже.

[melky]

я так думаю, что если в конце 3-его цикла значение будет иное, чем во 2-м, то значение 2-ого цикла никуда не попадет, его заменит значение в 3-м цикле. И так далее...
Думаю вы льстите этому ПЛК, чтобы он собирал значения в очередь.

[kondor3000]

Ваши слова, в многом, бальзам на душу.
В конце 1-го цикла я выдам значение modbus-переменной к отправке. А в конце 2-го цикла, уже немного другое значение этой же переменной. Допустим, по истчении 2-го цикла, значение modbus-переменной, заданное в 1-ом цикле, так и не была отправлено. Но уже есть новое задание и значение modbus-переменной скорректировано, хотя за 1 цикл ПЛК врят ли для этого возникнут предпосылки извне.
Мне видится это следующим образом:
- нужно фиксировать время цикла плк (допустим 200 мс или сколько там получится);
- направлять задания в модбас раз в цикл или, если все будет плохо, реже.

Ерунду пишите, цикл ПЛК может быть 1-3-10 ms, а передача каждые 20-200 ms, как зададите. Никакой буфер не забьётся. Конфигурация спокойно справится. И библиотека тоже.
На вашем месте, лучше задаться вопросом, как бороться с помехами от частотников. Нужен комплекс мер, по экранированию проводов, заземлению, разнесение силовых кабелей и измерительных (управляющих) проводов, резисторы 120 Ом по сети RS485, помехи по питающей сети и т. д.

[EFrol]

Ваши слова, в многом, бальзам на душу.
В конце 1-го цикла я выдам значение modbus-переменной к отправке. А в конце 2-го цикла, уже немного другое значение этой же переменной. Допустим, по истчении 2-го цикла, значение modbus-переменной, заданное в 1-ом цикле, так и не была отправлено. Но уже есть новое задание и значение modbus-переменной скорректировано, хотя за 1 цикл ПЛК врят ли для этого возникнут предпосылки извне.
Мне видится это следующим образом:
- нужно фиксировать время цикла плк (допустим 200 мс или сколько там получится);
- направлять задания в модбас раз в цикл или, если все будет плохо, реже.

ПЛК может начать передачу значения из переменной в любой момент (хоть на 200-м цикле)
да и передавать его он может несколько циклов подряд (Slave не ответил, будут повторы в передаче и т.д. и т.п.)
поэтому хоть тысячу раз за цикл меняйте, ПЛК сам в нужный ему момент заберет и отправит
даже когда стоит режим "По изменению", а к моменту как придет очередь, и значение будет таким же как при прошлой передаче, ПЛК не будет его передавать, хотя несколько циклов подряд значение переменной менялось