Универсальный конфигурируемый регулятор

[ОООСА]

ОВЕН выпускает универсальный регулятор ТРМ 151.
Я бы развил эту тему. Был в Советское время конфигурируемый (не ПЛК) контроллер, а точнее регулятор с функциями логического управления - РЕМИКОНТ. Он очень полюбился наладчикам не только тем что у него не было советских аналогов, а тем что он имел исчерпывающую удобоваримую документацию (даже была выпущена книга по прибору) и необходимый и достаточный (аксиома) на все случаи жизни наборы алгоблоков (аналог ФБД).
ИМХО имеет смысл взглянуть в сторону универсальных конфигурируемых устройств как промежуточного звена между "железными" регуляторами и ПЛК.
И главное что не нужно изобретать велосипед, нужно переложить идею РЕМИКОНта на железо ОВЕНа, но не используя монстроидального CoDeSys, а с использованием своего компактного самодостаточного графического конфигуратора, что-бы в любой глухой деревне на древнем ноутбуке можно было сконфигурировать прибор под нужды коровника.

[Малышев Олег]

Я выскажу чисто мое мнение, может оно и расходится с мнением партии и правительства.
Сдается мне что Кодесис не такой уж и монстр, и скажем с Visual Studio .Net не сравнится никогда.
Насчет работы с конфигураторами и конфигурируемыми приборами - смотрим кроме 151 в сторону ТРМ251 (отчасти ТРМ 148).
Однако, сдается мне, что конфигурируемость имеет свои пределы и после определенной сложности никакой ноутбук в коровнике это не выход.
И не верится, но и на кодесисе можно набросать и заставить заработать !в подвале! систему регулирования обратки (с диспетчеризацией и защитами) за несколько часов.

[ОООСА]

Я выскажу чисто мое мнение, может оно и расходится с мнением партии и правительства.
Сдается мне что Кодесис не такой уж и монстр, и скажем с Visual Studio .Net не сравнится никогда.

Большинство слесарей КИПиА, да и далеко не каждый инженер КИП программер. Или вы думаете что LD и FBD придумали для прикола?
Лично я не встречал уникума программера в совершенстве знающего КИП, и наоборот не встречал КИПовца виртуозного программера на Си. Я лично первый раз столкнулся с Симатиком и STEP5 в 1986г. и по сей день программирую задачи на LD и FBD потому как они наиболее гармонично сочетаются с философией железа. В CoDeSys имхо основной недостаток это ручное рутинное конфигурирование, объявление всяких переменных и т.д. В качественном ПО все эти действия максимально автоматизированны, достаточно выбрать типы ПЛК и модулей расширения, остальное проблема ПО...
А теперь о конфигурируемом контроллере, за десяток лет наладки РЕМИКОНтов нашей советской организацией не возникало проблем с нехваткой алгоблоков. Данный контроллер был очень качественно продуман на основе опыта нескольких десятилетий разработки регуляторов.
Рекомендую скачать с интернета документацию по РЕМИКОНТу и использовать её как отправную точку.

[ОООСА]

Малышев Олег
Насчет работы с конфигураторами и конфигурируемыми приборами - смотрим кроме 151 в сторону ТРМ251 (отчасти ТРМ 148)
Посмотрим на что способен ТРМ 151. Взял на пробу четыре штучки, буду ломать (шютка). Но вывод однозначен - для конфигурируемого прибора типа РЕМИКОНТ данный девайс жидковат по количеству входов/выходов. Для такого девайса подойдет ТРМ 148 с возможностью расширения. Но сего девайса в природе не существует! Был только анонс, и не более... Вот тут как раз нужно сделать сее чудо с возможностью расширения, но не через MODBUS, а через локальную шину, а MODBUS оставить для верхнего уровня управления. ПО должно быть с простым интуитивно понятным программированием без жестоких премудростей (для примера можно взять ПО от нано-ПЛК LOGO! (Siemens), Alpha XL (Mitsubishi), Millenium3 (CROUZET)).
П.С. Есть в интернете проект с открытым ресурсом HiAsm - конструктор программ на Delphi, который имеет схожий интерфейс с ПО для нано-ПЛК. Можно его попробовать прикрутить к конфигурируемому прибору, потому как к нему есть открытые исходники.
Кстати, может кто из форумчан попробует адаптировать HiAsm под ОВЕНы?

[Малышев Олег]

Посмотрим на что способен ТРМ 151. Взял на пробу четыре штучки, буду ломать (шютка). Но вывод однозначен - для конфигурируемого прибора типа РЕМИКОНТ данный девайс жидковат по количеству входов/выходов.
Можно прикрутить МВА, МВУ - т.к. 151 может работать как мастер.

Насчет оптимизма в отношении сред Мицубиси и Сименс Лого ... Честно говоря не вижу особых преимуществ над кодесисом. По библиотекам вопрос в наработке под себя набора удобных ФБ. Впрочем можно начать с utils.lib, PID_regulators.lib, oscat.lib.

Далее - по декларированию переменных - в среде есть чудо кнопка - F2. Пока не освоил - тоже сильно ругался.

Прикрутить HiAsm к ТРМ151 - вообще неплохая идея. Возможно получится...

[ОООСА]

Малышев Олег
По поводу CoDeSys. Я и не собираюсь его сравнивать с LOGO!. Это разные весовые категории. CoDeSys хорош для серьезных проектов с серьезными ПЛК где работает команда разработчиков. Вот тут возможности совместной работы над проектом жизненно необходимы. А для простых проектов нужны простое, ИНТУИТИВНО понятное ПО!!! Так что-бы можно было создать работающий проект размером от десятка до пары сотен ФБД, не напрягаясь рисуя схему. При таком подходе мозг разработчика занят анализом процесса и не отвлекается на всякие мелочи...
Поигрался с конфигуратором ТРМ 151. Ответ однозначный - графический интерфейс конфигурирования был бы заметно удобнее и НАГЛЯДНЕЕ древовидного меню, ну а если еще добавить режим эмуляции то вааще шоколадно...

[Алексей А.]

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

[ОООСА]

Алексей А.
Из своей многолетней практики могу привести сравнительный пример: Есть на свете два мощных, извечно конкурирующих производителей ПЛК. Это Siemens и Mitsubishi. В большинстве случаев у заказчика выигрывал Siemens при более высокой цене и более низкой производительности ПЛК по причине отличной ДОКУМЕНТИРОВАННОСТИ и хорошего сопровождения (представительство AG Siemens обосновалось в России давно, а AG Mitsubishi только недавно, хотя само представительсто Mitsubishi сидит у нас давно). У всех япошек есть один большой минус - слабая документация, а если учитывать что документация переводится с японского (в котором почти нет технических терминов) на английский, а потом на русский, то в итоге получаем черти что, и смешно и горько... Приходится изучать ПЛК ручками, тратя драгоценное время, а ВРЕМЯ - ДЕНЬГИ, и тратить уйму времени на разгадывание ребусов непозволительная роскошь!
Так что главный бич приборной части это аппаратно/программные баги и слабая (запутанная) документация. И только далее следует цена, надежность, долговечность и бренд.
Имхо это не моё дело, но разработкой документации должен заниматься отдельный специалист, а не разработчик "железа" и программист (у них своих дел хватает).
Когда-то шутили что МЗТА выпускает "шифрованную" документацию что-бы американские разведчики ничего не поняли и не стибрили ноу-хау... Мне крайне не хочется что-бы успешный ОВЕН уподоблялся МЗТА (к сожалению параллель вполне можно провести, чем сложнее начинают выпускать приборы, тем путаннее документация)...

[Филоненко Владислав]

Все приборы ОВЕНа, начиная с ТРМ151 и сложнее всегда были, ИМХО, избыточно функциональны. Это наш крест, т.к. в нашей стране куча головастых кулибиных, к-м нужно 300 % отдачи от железки.
В отличии от импортных производителей мы не можем не обращать внимание на запросы потребителей выжать всё, что можно из прибора.
Да и сами, честно говоря, также склонны создавать приборы с макс. функционалом. Капелька крови Кулибина течёт в наших жилах ))
А вот описать такой функционал сложно, т.к. нельзя опереться на опыт других производителей и сказать: "У нас также".
Документация такого уровня сложности за рубежом отшлифовывалась годами, над этим работали множество специалистов во всех областях.
Но в посл. время позитивные подвижки есть, тех. писатели набрались опыта, и сами разработчики тоже.

[Wildelectric]

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