CodeSys - Serial Modbus Slave

Почему для ЧПУ нужно 50 - 20 мс.? Мы же говорим про операторское управление. Здесь нажатие кнопки 100 мс, если палец на ней уже лежит. Другими словами, при каких условиях для операторского управления нужно обновлять данные быстрее, чем человек может на них реагировать?

10 - 20 мс.  -  это только чистое время передачи от Точки к Точке, так-сказать - базовое время. Оно почти не зависит от об'ема данных, и определяется в основном протокольными делами TCP / IP. Но кроме самого обмена данными в системе делается еще много всякой работы.

Одиночные контроллеры работают обычно автономено, почти не общаясь с внешним миром. В отличие от них - ЧПУ постоянно обмениваются с пультом управления.
Со стороны станка на пульт поступают несколько десятков чисел для показаний индикаторов координат, строки программы обработки детали, таблицы настройки инструментов, и много другой информации.
С пульта поступают команды. Но не сразу, а проходят через анализатор команд, распределитель, направляются в цикл выполнения. Потом ожидается подтверждение выполнения, затем - его отправка. Все это замешано на синхронизации циклов между собой через флаги. Аппаратура молотит вовсю.
Каждая операция требует обмена данными, и стало быть, базовое время нужно помножить на число операций, причем - вдвойне. Общий командный цикл набегает плрядка  0.5 - 1 сек. Такая медлительность подчас не нравится операторам. Бывает что можно выжать и побыстрее.

Я упоминал одиночные контроллеры. Но есть системы связанных контроллеров, чаще всего на автоматических линиях. Такие контроллеры наворочены как ЧПУ. Для согласования между собой им нужна скорость еще выше - базовое время  5 - 10 мс.  Здесь дело уже не в "ожидании нажатия кнопки" на пульте.

Так-что, вопрос о периоде обмена далеко не пустяшный.

OPC - забава для магнатов, смотреть заплывшими глазами, как через красивые бачки, нефть разливается в карманы ...

С вуажением, SAN

К чему такие крайности? В отношении ЧПУ все расписали вполне корретно и возражений пост не вызывает.

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

Так что имхо ОРС вполне имеет право на существование.

Впечатляет

И полностью согласен с Вашим постом на первой странице темы.

Если в технологии речь идет о секундах - годится ОРС-сервер, используются его возможности и меньшие требования к уровню знаний и умений инженера.

Если речь идет о десятках миллисекунд - Ваш вариант безусловно "вкуснее"!

Первоначально опубликовано sanwork OPC - забава для магнатов, смотреть заплывшими глазами, как через красивые бачки, нефть разливается в карманы ...

Не согласен. Неужели проще нарисовать для оператора установки таблицу параметров эдак в 500 заставить его заучить какой параметр за что отвечает и что делать в случае его выхода за уставки. Или все же проще сделать картинку на которой все доходчиво нарисовано-расположено интуитивно понятно и любой маломальски грамотный оператор, зная что ваабщето происходит в системе сможет управлять ей. Можно писать на Делфи/С++ верхний уровень угробив на это чертисколько времени и потом сопровождать творение всю жизнь, а можно взять скаду и все сделать за разумные сроки и в надлежащем качестве. А уж применительно к скадам ОРС "самое оно". И ведь далеко не всегда нужно чтобы при техпроцессе длинной в пару недель данные приходили с периодом в десятки милисекунд, а уж если надо то можно реализовать "быстрые" каналы "руками" не ожидая пока ОРС перелопатит всю гору тэгов.

Поддерживаю высказанную выше мысль "Все зависит от задачи".