ПЛК и сетевые коммуникации: концептуальные основы
В соответствии с этот вопрос, Можно отправить сообщение TCP / IP с ПЛК на ПК с использованием релейной логики. Какие? Я уверен, что это имеет смысл для людей из мира ПЛК, но я изо всех сил пытаюсь понять, что это происходит из мира встроенных систем C / C ++.
Может ли кто-нибудь объяснить или указать на объяснение того, где именно по отношению к ПЛК происходит такая связь? Это происходит в цикле сканирования ПЛК, и в этом случае … как ожидания, задержки, тайм-ауты, повторные попытки и т. Д. Обрабатываются без увеличения цикла сканирования? Точно так же, существует ли какой-либо способ, с помощью которого такая функциональность согласуется с метафорой электронных «цепей питания и переключателей» лестничной логики, или эта метафора простирается до точки разрушения?
Меня поражает, что есть задачи (не обязательно задачи), которые трудно развернуть за несколько миллисекунд цикла сканирования ПЛК. Расширение этого цикла ради таких задач кажется несостоятельным. Так есть ли в мире ПЛК способы и средства для выполнения этих задач вне цикла сканирования ПЛК, который каким-то образом интегрирует их ввод / вывод / управление в цикл сканирования ПЛК? Я подозреваю, что это так, но я не нашел ничего, что ясно это говорит.
Решение
как ожидания, задержки, тайм-ауты, повторные попытки и т. д.
Вы просто не делаете это за один цикл. Вместо того, чтобы приостановить поток, вы проверяете, пришло ли время двигаться дальше, и если нет, вы немедленно приступаете к выполнению оставшейся части цикла, пропуская все, что хотите, когда закончите ждать.
Любая не немедленная (блокирующая) задача выполняется в несколько циклов, будь то высокоуровневый ввод / вывод данных или какой-то реальный процесс «реального мира». Коммуникационные звонки, например, read (), write (), send (), receive () и т. д. являются неблокирующими, иногда даже асинхронными. В LD и других (IEC 61131-3) языках все это обрабатывается с использованием флагов, триггеров и т. Д.
Вот это некоторый реальный код, который отправляет запрос и считывает данные измерений с цифрового датчика через последовательный порт RS-485. Обратите внимание, что нет блокирующих вызовов, и не имеет значения, насколько короткий цикл сканирования.
Другие решения
Проблема заключается в том, что ПЛК были разработаны для управления своими задачами и отправки данных в режиме реального времени через ProfiBus, Ethercat, ProfiNet и т. Д. Связь по протоколу TCP / IP действительно довольно громоздкая, если смотреть с точки зрения компьютерного программирования.
Что помогло мне, так это прочитать очень толстые руководства по связи от и до ПЛК. Особенно такие вещи, как объем данных, которые можно отправить или прочитать за один цикл (!). И используйте волшебников как можно больше. Проверьте сайты поддержки.
Положительным моментом для производителей ПЛК является то, что у них есть поддержка, которая больше готова помочь, чем мир программного обеспечения. Просто попробуйте и спросите их, может ли это помочь вам в дальнейшем.
Используя библиотеки, предоставляемые производителем вашей выбранной системы управления, большая часть этого обрабатывается на нижнем уровне асинхронно, и вам не нужно иметь дело с этим в вашем коде ПЛК (который обычно является «в реальном времени», синхронным и блокировка по дизайну).