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

автор работает с 8-битниками

простите меня теоретика, сдающего по нескольку объектов под ключ за сезон.

Занимался как раз задачами автоматизации птичника (более 10 лет). Расскажу с чем мы столкнулись.
Как показала практика все системы должны быть распределёнными (как минимум допускать расширение), либо связаны по сети (диспетчеризация).
Готовые системы не устраивают не зависимо от производителя, должен быть индивидуальный подход.

Минусы использования ПЛК (тип не имеет значение):
1) ОЧЕНЬ дорого, особенно по нынешним ценам;
2) в качестве датчиков температуры использовали DS18B20 (DS18S20). Ни один нормальный ПЛК не поддерживает данный тип датчиков (городить что то по modbus не очень хороший вариант)
3) частично лицензионный софт
4) иногда быстродействие, как ни странно (например, при реализации фазоимпульсной модуляции)
5) модули для контроля входов 220V как правило с трудом выдерживают режим работы 24/7 (приходится опять городить что-то свое).

При разработке основная проблема была с нехваткой портов ввода/вывода, а также памяти (как RAM так Flash), как говорили уже здесь быстродействия вполне хватало (в ОСРВ потребности не было). В итоге даже начинал рассматривать вариант разработки своего ПЛК (хотели переделать ПЛК Delta, они дешевле и используют STM32 (правда среда разработки плохая, нет ST) либо сделать что-то своё аналогичное, платы можно заказать в Китае).

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

Речь в данной теме шла о софте: итог (моё мнение) - всё равно придётся плодить версии под каждого заказчика (заказчик всегда прав), единственно, что можно это попробовать решить за счёт конфигурации блока (недоступной заказчику). Правда я немного не понимаю почему у вас это сводится к изменению ПО, как правило оно тянет за собой и изменение аппаратной части.

Может что нибудь предложить? Какой ПЛК самый лучший?

Тож в Австралии один "курятник" надо автоматизировать.

Последние 2 года в основном ставлю Овен ПЛК110-60 и ПЛК110-30. Самый лучший не подскажу, выбираю под конкретные задачи. По надежности одним из них считаю Simatic S-300. В принципе все хотелки Вам должен написать заказчик в техусловиях на проектирование АСУТП. Может у них Аллен Бредли или Омрон в почете, им виднее.

В своё время рассматривали Schneider Electric Modicon M340 (BMX XBP 1200 + BMXP342020 + ...)

значит время таки пришло ?

В этой теме речь не идет о пром контроллерах, армах или скриптовых движках. Это наверное и важно и интересно, но точно не мне и не сейчас.
Из конструктива в теме отмечу ссылки на ооп и ос. На сколько мне известно, то это огромные темы с массой интересного. Однако напоминаю, что у меня маленькие процы и в принципе простые задачи сложно взаимодействующие друг с другом.
Что из самого ценного взять и трансформировать в мир маленьких камней из ооп и ос? обьекты и задачи? семафоры? есть ли реализации на которые можно смотреть и наследовать?

С++ для микроконтроллеров.

в первую очередь эта статья
http://easyelectronics.ru/rabota-s-portami...erov-na-si.html
и примеры к ней
https://github.com/KonstantinChizhov/Mcucpp/tree/dev

Многие будут отсылать к книге Андрея Александреску "Современное проектирование на С++", но как то пока сложновато.

тоже в основном смотрю в этом направлении, пробую как раз для AVR (8 бит). Задача стоит иметь расход RAM (а потом и Flash) аналогичный применению с использованием Си.

Для себя сделал вывод, что для uC необходимо (желательно) использовать шаблоны классов со статическими членами, тогда вроде всё получается...

Сообщение отредактировал dm37 - Jan 4 2017, 19:53

Повезло вам с заказчиками... У нас в основном "хочу что-то вот так, включать, чтобы само отключалось потом...", да чтоб картинки красивые, и сенсорные кнопочки с анимашками... Вот и пиши с этого техзадание...

Если ПЛК не может работать в 24\7 - это плохой ПЛК, но чаще всего исполнитель не заботится о защите линий от бросков напряжения и т.п.

Пришло к чему? Поставить винду на 8и битник??

...а после этого обычно оказывается, что "Вы всё неправильно сделали, и вообще я хотел другого. Вы виноваты. Переделывайте всё....".
Сколько занисаюсь разработкой - ТЗ всегда писали сами, заказчик только читал и говорил что ему не нравится. Хотя потом всё равно приходилось переделывать, так как оказывалось что "я хотел не такого, а с перламутровыми пуговицами...."

Как ни странно, но здесь есть доля истины. Только чтоб работать со скриптами, их должна выполнять какая-либо ось, в которой есть уже готовые модули работы с портами в\в интерфейсами, типа того далласа, который указал автор, и еще многое другое. Тогда, да, будет быстрое программирование и не надо винду ставить, сам делал такие ПЛК.

если исполнитель должен заботиться о защите линий по входам 220V, то я скорее выберу свой вариант преобразования из 220V в 24V (с защитой) и возьму обычный модуль дискретного ввода, в противном случае получается необоснованный огород. В принципе мы так и делаем.

Да так и есть, к сожалению..

Тоже неплохой вариант, вообще считаю, чем больше низковольтки, тем надежнее.