Подбор ПЛК

[lsr]

Уважаемые коллеги, доброго времени суток.
Читал на форуме ветки по часто задаваемому вопросу какой плк выбрать, как выбрать, но ответа на свой вопрос не нашел.
Основные критерии это интерфейсы, протоколы, возможность подключения модулей расширения аналоговых/дискретных, дублирование, резервирование, OPC, база данных и т.д.
А как убедиться что его "начинка" вывезет информационную емкость системы, или задачи которую передним ставят?
Часто в описании ПЛК производитель указывает: для простых систем, для сложных, для программ среднего и большого объема - основа какая? что есть средний,что есть большой :D
-уже проинформирован что есть "корпоративные" утилиты производителя на подсчет загруженности плк
Все-таки как быть, как считать, какие варианты?
Спасибо!

[Jackson]

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

Ещё по опыту увидел, что объем кода программы (сколько он сжирает в памяти контроллера), написанный на IL является самым маленьким, затем по возрастанию идет ST, LD и графсет, но в той же зависимости находится удобство последующего обслуживания (простота понимания при взгляде стороннего человека, не разработчика а наладчика скажем) - в IL без комментариев вообще разобраться довольно непросто (на это уходит много времени) а графсет понятен сразу. LD например прост для понимания тем кто привык к релейным схемам управления, в моей отрасли и в моей работе я часто им пользовался только поэтому.

Потом я отошел от PLC, так что мне тоже теперь интересно, как оценить достаточность ресурсов PLC до того как купил и сам PLC и софт для разработки прикладного ПО. Весь внимание!

[DelSnos]

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

Часто в описании ПЛК производитель указывает: для простых систем, для сложных, для программ среднего и большого объема - основа какая? что есть средний,что есть большой

Это так любят в брошюрках рекламных писать- много картинок, мало букв, а пользы никакой :D Известные производители выпускают несколько линеек ПЛК. Для примера по возрастанию:
Siemens: S7-1200, S7-300, S7-400 ;
Allen-Bradley: MicroLogix, CompactLogix, ControlLogix.
Масштаб системы можно оценить по количеству входных/выходных сигналов. Опять тут нет каких-то четких границ. Для кого-то 3 ктегов средняя система, для кого-то уже большая- нужно оценивать в рамках отрасли что ли.

А как убедиться что его "начинка" вывезет информационную емкость системы, или задачи которую передним ставят?

Зная примерное кол-во сигналов, алгоритмы обработки данных, интерфейс и кол-во опрашиваемых устройств опытный программист примерно может оценить требуемые ресурсы и выбрать необходимый CPU и коммуникационный модуль. Но это уже совсем серьезный подход для больших систем.

-уже проинформирован что есть "корпоративные" утилиты производителя на подсчет загруженности плк

Да, гиганты-производители выпускают своего рода конфигураторы. В них практически можно собрать полностью рабочий вариант: проверить компоненты по току, на совместимость модулей и интерфейсов, определиться с размерами и многое другое... Очень актуально для мощных систем.
Это я постарался хотя бы в общих чертах описать.

[Jackson]

Зная примерное кол-во сигналов, алгоритмы обработки данных, интерфейс и кол-во опрашиваемых устройств опытный программист примерно может оценить требуемые ресурсы и выбрать необходимый CPU и коммуникационный модуль.

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

Вот пример: 20 DI, 16 DO, 5 AI, 10 AO, RS-485 ModBUS. Что выбрать? Да ничего не выбрать, потому что даже на эти скромные в/в может быть всего 20 инструкций в коде, а может быть 3000, быстродействия при этом может достаточно 100 мс/цикл, а может надо 5 мс/цикл. Совершенно разные PLC получаются.

[DelSnos]

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

Вот пример: 20 DI, 16 DO, 5 AI, 10 AO, RS-485 ModBUS. Что выбрать? Да ничего не выбрать, потому что даже на эти скромные в/в может быть всего 20 инструкций в коде, а может быть 3000, быстродействия при этом может достаточно 100 мс/цикл, а может надо 5 мс/цикл. Совершенно разные PLC получаются.

Наверное, никак! Пусть этот вопрос лучше доверить профессионалам)

[lsr]

Спасибо за ответы, рад что вопрос вызвал интерес!

А отталкиваться от характеристик ЦПУ как-то можно на "базовом" уровне?

[lsr]

Учиться и становиться профессионалами удел избранных? Я задал вполне реальный вопрос, на который получаю только образный ответ. Как вы тогда дошли до этого?

[DelSnos]

Спасибо за ответы, рад что вопрос вызвал интерес!

А отталкиваться от характеристик ЦПУ как-то можно на "базовом" уровне?

Неправильно это концептуально. Систему строят снизу, а оттуда уже определяются с количеством сигналов, потом с количеством и типом модулей и поехали дальше.
А просто набор технических характеристик ЦПУ в отдельности ничего не скажет. Систему нужно "мерить" в целом.
А плясать от отдельного ЦПУшника есть смысл, когда он завалялся у вас в закромах и вы собрались его присобачить, например, для автоматизации гаража. :D Правда тоже спорно. Лежит у меня один за несколько тыс. баксов, а модулей в/в нет-дорого очень :D :D

[Jackson]

Учиться и становиться профессионалами удел избранных? Я задал вполне реальный вопрос, на который получаю только образный ответ. Как вы тогда дошли до этого?

Опытным путем. И я даже написал каким именно. И вполне конркретно заметил что многое зависит от кол-ва I/O и интерфейсов как писали выше, а также от объема программы будущего контроллера. Первое Вы можете просто посчитать, как тоже уже было конкретно сказано. Но уж второго тут точно никто Вам не скажет, это Вы должны определить сами - мы не телепаты и понятия не имеем чем будет заниматься Ваш PLC. Про зависимость объема кода от способа программирования я тоже Вам рассказал. Куда уж конкретнее еще разжевывать? Все критерии даны. Или Вы ждёте готовой спецификации PLC для закупки с кодами заказа?

Вот и становитесь профессионалом и учитесь, думайте, не думая своей головой профессионалом Вы не станете.

Кстати, наверное можно взять какой-нибудь софт для программирования, демку без ключа, набрать в ней контроллер, прикинуть программу и попытаться оценить влезет ли она в контроллер. По крайней мере старый PL7 от Шнайдера (сейчас вместо него Unity) давал такую возможность.

А на слишком большой код я нарвался работая с контроллером TSX 07 nano (если кто помнит такой, детище японского Modicona), его софт PL7-07 просто не имел такой фичи - проверка занимаемой памяти, а я наивно верил что раз в софте негде посмотреть распределение памяти в контроллере (а в PL7 для старших контроллеров эта фича есть) то софт меня предупредит когда код превысит допустимый размер. Софт всё время молчал, я писал. В результате я создал код из порядка 1300 инструкций и при загрузке в контроллер узрел ошибку с текстом, мол допустимо всего 999 инструкций. И сидел, оптимизировал. Хорошо что было что оптимизировать, потому что программу я делал на LD и делал её так чтобы она была максимально понятна тем кто в ней возможно будет копаться после меня, т.к. комментарии в контроллере не сохраняются. Этим и пришлось пожертвовать. Вот такой опыт.

[lsr]

Это все предельно ясно, и про загруженность языков я знал, для меня нужен был факт решения вопроса (типа внутренних утилит).
Для себя всю информацию вынес, все практика и практика, к чему только коллега именно сюда СШГЭС приплясал...
Был интерес в существование подхода. Убедился что нет, переживать не буду в случае неудачи, буду редактировать и учиться на ошибках. Всем спасибо!

[DelSnos]

Это все предельно ясно, и про загруженность языков я знал, для меня нужен был факт решения вопроса (типа внутренних утилит).
Для себя всю информацию вынес, все практика и практика, к чему только коллега именно сюда СШГЭС приплясал...
Был интерес в существование подхода. Убедился что нет, переживать не буду в случае неудачи, буду редактировать и учиться на ошибках. Всем спасибо!

СШГЭС все чётко приплясал, а вот подумал, что вы Заказчик, наверное, зря :D :D

[DelSnos]

Хотя конечно все зависит от того, что за ПЛК....

Да если и будут, то опять же человеческий фактор. Помню интегрировал проект в существующий контроллер (AB), как залез в онлайн- шары на лоб полезли.
Вся программа ПЛК была построена через пользовательский цикл For..next. Причем, без учета времени скана main-цикла и подпрограмм. В результате в буфере тонна ошибок от сторожевого таймера. Хорошо, что минорные были, но иногда, как местные говорили ПЛК уходил все-таки в STOP :D
Да, вот еще случай был. Помню нужно было промэпить (с минимальной маской!) сетку с H-системой. В результате за-DoS-сил коммуникационник, а CPU-шник вообще ушел в непонятное состояние. Алгоритмы отрабатывали или нет- не успел проследить. Все обошлось, но сам факт весьма неприятный. Правда система была начала 2000-х годов- прошивки и железо старое.
Я к чему- человеческий фактор остается самым главным. Как там? На Бога надейся, а сам не плошай :)

[Михайло]

99% задач не требуют подсчета объема занимаемой памяти и требуемого быстродействия ЦПУ.
Но первая задача может попасться именно такой - из 1 %, поэтому на всякий случай говорю "ИМХО".

Еще надо понимать, что ПЛК - разработки последних лет - имеют память в десятки раз больше, а быстродействие - в несколько раз. Цена та же. Вот и выбирайте их, зачем Вам изучать старые модели?

[leon78]

Объем занимаемой программой памяти напрямую зависит от реализации.
Я когда начал заниматься программированием ПЛК, написал программу, которая в память не влезала. Пришлось заниматься оптимизацией - тестировал, на что тратится память в каждом конкретном блоке и как уменьшить ее использование. Конкретный пример: замена по всей программе числа 0 на константу, равную 0, дало приличное уменьшение занимаемой памяти. В итоге программа влезла. Цикл сканирования этой версии был 250мс. Потом появились новые идеи, программа была полностью переделана, и она стала выполняться за 100мс, обрабатывая в 2 раза больше сигналов. Но то, что подходит для одного контроллера, не подходит для другого.
Поэтому на объем памяти можно при выборе не смотреть (выбирать с макисмальной памятью и производительностью :) )
Я бы делал так:
1. Определился с количеством контроллеров на объекте. На оборудование, которое может работать независимо, лучше устанавливать отдельный контроллер, чтобы не было проблем с обслуживанием (например, одна установка работает, другая в ремонте, а управляющий контроллер общий).
2. Опеределиться с необходимостью резервирования.
3. Опеределиться с сетями для связи между контроллерами и сетями связи с верхним уровнем.
4. Определиться с протоколами связи.
5. Посчитать количество сигналов на каждый контроллер.
6. Узнать, какие контроллеры уже используются на объекте.
7. Подобрать контроллер по требованиям п.2-6. Стараться использовать максимально однотипные контроллеры, чтобы не разводить зоопарк. Если требуемое количество сигналов на один контроллер приближается к максимуму для данной линейки, лучше выбрать более дорогую серию. Если не было опыта автоматизации таких объектов, на первый раз заложить наиболее мощный контроллер из данной линейки.
Часто на сайте производителя есть примеры использования контроллера в различных отраслях. Эта информация так же может быть полезной.

[Looker]

Rockwell для контроллеров Logix приводит оценку Controller Memory Use (стр.12).

[doza]

Я тут вчера был на эмоциях...пригласили в одну очень крупную компанию (Заказчик которого знают все). Попросили сделать бесплатно (т.е. даром) их же собственную работу (при этом численность своего персонала у них несколько тыс. дармоедов). А потом еще и на тендерах упасть на 15% от стоимости. И это все- при бешеной инфляции и росте курсов валют. Как мне к таким умникам еще относится? :) Стыдобища...

М-да вас просто попросили отмыть деньги, заключив какой нибудь договор и взявшись за работу, Вас потихоньку попросили-бы устранится, а потом за вас доделывала армия как Вы выразились "несколько тыс. дармоедов", в отчетности соответственно отписали что на Вас потратили столько :amazement:
Вы прям как не в России живете.
Извиняюсь что не в тему данного раздела форума, по своему опыту больше 60 точками при самостоятельном проектировании не оперировал.
Да и выбор контроллера не столь сейчас актуален (там где в щит влез контроллер, влезит и второй), вопрос только на каком этапе нагнется бюджетный сервер.