ПЛК и сетевые коммуникации: концептуальные основы

Question

Согласно this question, можно отправить сообщение TCP/IP с ПЛК на ПК с использованием логики лестницы. Какие? Я уверен, что это имеет смысл для людей из мира PLC, но я изо всех сил пытаюсь понять, что это происходит из мира встроенных систем C/C++.

Может ли кто-нибудь объяснить или указать на объяснение, где именно происходит связь с ПЛК? Это из цикла проверки PLC, и в этом случае ... как ожидания, задержки, тайм-ауты, повторы и т. Д. Обрабатываются без расширения цикла сканирования? Точно так же существует ли способ, с помощью которого такая функциональность согласуется с электронной метафорой «рельсов и переключателей» логической схемы лестницы или эта метафора простирается до точки разрушения?

Мне кажется, что есть задачи (не обязательно задаваемые задачи), которые трудно было бы развернуться за несколько миллисекунд цикла сканирования ПЛК. Расширение этого цикла ради таких задач представляется несостоятельным. Так существуют ли способы и средства в мире ПЛК для выполнения этих задач за пределами цикла проверки ПЛК, который каким-то образом интегрирует их вход/выход/управление в цикл проверки ПЛК? Я подозреваю, что это так, но не нашел ничего, что ясно говорит об этом.

Answer 1

, как это ждет, задержки, тайм-ауты, повторные попытки и т.д.

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

Любая немедленная (блокирующая) задача выполняется в несколько циклов, будь то высокоуровневые данные ввода/вывода или какой-то фактический процесс «реального мира». Коммуникационные вызовы, например. read(), write(), send(), receive() и т. д., являются неблокирующими, иногда даже асинхронными. В LD и других языках (IEC 61131-3) все обрабатывается с использованием флагов, триггеров и т. Д.

Here - это настоящий код, который отправляет запрос и считывает данные измерений с цифрового датчика через последовательный порт RS-485. Обратите внимание, что нет блокирующих вызовов, и не имеет значения, как короткий цикл сканирования.

Answer 2

Проблема заключается в том, что ПЛК были предназначены для управления своими задачами и отправки данных в режиме реального времени через ProfiBus, Ethercat, ProfiNet и т. Д. Связь TCP/IP действительно довольно громоздка, если смотреть с компьютерного программирования.

Что мне помогло, так это прочитать очень толстые руководства по связи с ПЛК и к ним. Особенно такие вещи, как количество данных, которые могут быть отправлены или прочитаны за один цикл (!). И используйте wizzards как можно больше. Проверьте сайты поддержки.

Положительная сторона производства ПЛК заключается в том, что у них есть поддержка, которая более охотно помогает, чем мир программного обеспечения. Просто попробуйте и спросите их, сможет ли вам помочь вам дальше.

Answer 3

Используя библиотеки, предоставленные производителем вашей системы управления, большинство из них обрабатывается асинхронно на более низком уровне, и вам не нужно иметь дело с ним в коде ПЛК (который обычно является «в реальном времени», , синхронный и блокирующий по дизайну).