Size: a a a

Автономные Технологии

2016 June 21

СБ

Сергей Бондаренко in Автономные Технологии
Фишка для комплекта HMI+PLC+ПЧ для шнейдера будет как раз в том что все это будет настраиваться и програмироваться в едином софте под названием SoMachine. Просто внутри этого SoMachine и есть Codesys 3.5 плюс драйверы и фишечки Шнейдера для комплектного програмирования прочих девайсов.
Поэтому логика лучше под конкретное железо не нарушается... а программу можно конвертировать из обычной кодесис -свобода!
источник

SR

Sergey Romanov in Автономные Технологии
Василий Бугаёв
я бы так не утверждал, что CodeSys лучше. Софты, которые пишутся для конкретного контроллера, лучше заточены под работу с конкретным контроллером. Отсюда Больше фишек и удобств. И все прописанные функции работают. А CodeSys имеет огромный функционал, но в итоге это не на все аппаратные средства ложится.
Очень не проффесиональный ответ. Конечно кодесис лучше. Иначе Шнайдер, Ваго, и другие ведущие производители не стали бы это внедрять. Ведь это современный стандард.
источник

СБ

Сергей Бондаренко in Автономные Технологии
Поэтому в варианте ОВЕНа нужно будет программировать в разном ПО все части системы: ПЛК в кодесис, Модули в конфигураторах, Панели в своем ПО.... в варианте Шнедера это единый софт и отсутствие проблем настройки коммуникации оборудования между собой что в итоге выйгрыш во времени и скорости внедрения, плюс меньше ошибок возможности совершить
источник

SR

Sergey Romanov in Автономные Технологии
Панели овен програмируются в кодесис на сколько мне изветно. Визуализация кодесис становится панелью.
источник

SR

Sergey Romanov in Автономные Технологии
Тоже самое у ВАГО eCockpit это свой софт с встроеной Кодесис 3.5
источник

SR

Sergey Romanov in Автономные Технологии
О едином софте я согласен это удобно. Ни знаю как новые шнайдеры, но контролеры ВАГА заоблачные цены.
источник

SR

Sergey Romanov in Автономные Технологии
Да и кстати нужно учесть что soMachime платная.
источник

DP

Dmitriy Pershin in Автономные Технологии
Всем привет,
меня зовут Дима,
инженер (эксплуатации электрооборудования КС)
ХМАО-Югра
источник

ВБ

Василий Бугаёв in Автономные Технологии
Sergey Romanov
Очень не проффесиональный ответ. Конечно кодесис лучше. Иначе Шнайдер, Ваго, и другие ведущие производители не стали бы это внедрять. Ведь это современный стандард.
Т.е. Siemens, Allen Bradley, Omron ты к ведущим уже не причисляешь?
источник

ВБ

Василий Бугаёв in Автономные Технологии
Просто есть 2 пути.
источник

SM

Stanislav Maksimov in Автономные Технологии
Станислав, инженер проектировщик АСУ ЭТО (электро технического оборудования), раньше АСУ ПС (подстанций), СПб
источник

SR

Sergey Romanov in Автономные Технологии
Василий Бугаёв
Т.е. Siemens, Allen Bradley, Omron ты к ведущим уже не причисляешь?
Я согласен. ТИА портал вообще вещь крутая. Если бы мне дали выбрать, я бы выбрал сименс и работал только с ним.  Омрон и Дельта у них свой софт, но тут однозначно если бы они были на Кодесис то только выйграли бы.
источник

ВБ

Василий Бугаёв in Автономные Технологии
я Omron очень хорошо знаю, CodeSys немного щупал. И скажу, что Omron выигрывает. И скорее всего бы проиграл, если бы был с CodeSys
источник

ВБ

Василий Бугаёв in Автономные Технологии
Delta немного отстает от Omron
источник

ВБ

Василий Бугаёв in Автономные Технологии
До Allen Bradley всё руки не доходят, очень хочу попробовать. Думаю, что это должен быть космос.
источник

a

ap3amac in Автономные Технологии
Сергей Бондаренко
По поводу ОВЕН:
я бы рассматривал вопрос несколько в другой плоскости. Лучше использовать контроллеры на распространенной платформе CoDeSys, это дает простоту программирования (5 языков и множество библиотек) плюс некоторую безопасность применения -залит созданную программу с минимальными изменениями можно будет в ПЛК любого производителя в том числе и ОВЕН. В целом появляется удобная вилка принятия решения, когда есть программа написанная в Codesys и ее можно залить в ОВЕН если нужно подешевле но готов к багам и есть время или залить например в Шнейдер новых серий M221 \М241 \M251 и т.д.
на самом деле всё не так просто и однозначно с CoDeSys. Если речь идет о стандартных функциях и СофтПЛК, то бегает всё вполне стабильно даже на 3.5 версии. Но если говорить о Safety контроллерах, визуализации на Embedded системах или библиотеках выше 2го уровня ISO модели для некоторых протоколов передачи данных по шине (к примеру CANopen или j1939) то не обойтись без костылей и увеличения времени цикла даже на CoDeSys v2.3
источник

PD

Peter Destructive in Автономные Технологии
Борис, аудит, разработка сзи, иб асу тп
источник

DP

Dmitriy Pershin in Автономные Технологии
Не понимаю даже о чем речь, можно подробнее о теме, я вообще не в курсе, но как понял идёт речь о неких интерфейсах управления?
источник

СБ

Сергей Бондаренко in Автономные Технологии
> @ap3amac
на самом деле всё не так просто и однозначно с CoDeSys. Если речь идет о стандартных функциях и СофтПЛК, то бегает всё вполне стабильно даже на 3.5 версии. Но если говорить о Safety контроллерах, визуализации на Embedded системах или библиотеках выше 2го уровня ISO модели для некоторых протоколов передачи данных по шине (к примеру CANopen или j1939) то не обойтись без костылей и увеличения времени цикла даже на CoDeSys v2.3

Да есть такой момент, но речь изначально зашла с ПЛК ОВЕН, и уже затем в сторону обсуждения ПЛК и софта к ним "Кодесис или свой под конкретный ПЛК". А решения где люди рассматривают ПЛК ОВЕН -это низкоуровневые решения, где нет требований скорости опроса и обработки и интерфейс преимущественно Modbus. Для таких решений уровня станка, линии, малой диспетчеризации конечно Кодесис интересней, ибо позволяет выбрать затем по бюджету ПЛК в который его залить без особых переделок программы.  А например с CANopen и опросом по нему ПЧ больших требований не будет... но будет нюанс применения
источник

a

ap3amac in Автономные Технологии
Сергей Бондаренко
> @ap3amac
на самом деле всё не так просто и однозначно с CoDeSys. Если речь идет о стандартных функциях и СофтПЛК, то бегает всё вполне стабильно даже на 3.5 версии. Но если говорить о Safety контроллерах, визуализации на Embedded системах или библиотеках выше 2го уровня ISO модели для некоторых протоколов передачи данных по шине (к примеру CANopen или j1939) то не обойтись без костылей и увеличения времени цикла даже на CoDeSys v2.3

Да есть такой момент, но речь изначально зашла с ПЛК ОВЕН, и уже затем в сторону обсуждения ПЛК и софта к ним "Кодесис или свой под конкретный ПЛК". А решения где люди рассматривают ПЛК ОВЕН -это низкоуровневые решения, где нет требований скорости опроса и обработки и интерфейс преимущественно Modbus. Для таких решений уровня станка, линии, малой диспетчеризации конечно Кодесис интересней, ибо позволяет выбрать затем по бюджету ПЛК в который его залить без особых переделок программы.  А например с CANopen и опросом по нему ПЧ больших требований не будет... но будет нюанс применения
с этим соглашусь. Единственное так или иначе разработчикам ПЛК приходится так или иначе пилить COODESYS под свой контроллер. Так что портация готового проекта на другую систему будет затруднительна (впрочем как и везде), но возможность открыть файл и глянуть что там и как имеет свои плюсы. CODESYS 3.x по идее должен больше развязать руки разработчикам железа в плане внедрения своих модулей, но это пока только идея. Да и (асинхронное) обращение и оп. и файл. системой так же осталось не очень удобной. Но это везде так. Если конечно ты пользуешь IEC языки программирования
источник