[desh 0]

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

 

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

Да и с точки зрения вашего руководства - это будет несколько не то, что от Вас ожидают.

 

Да и как то рано Вы сливаться начинаете. Вон в соседней теме ребята не менее амбициозный проект пилят уже третий год на альтруизме. Рекомендую ознакомиться с их проектом и его историей.

[AlexandrY 3]

Что если зделать мезанинную структуру, конфигурация будет под заказ. Это годится для идеи? Это далеко от ПЛК. Но начать я думаю можно попробовать. Если не получится значит действительно закрыть тему, а если получится то продолжить развивать.

 

Начать надо с выбора платформы.

Например такой -

 

Можно сказать мезанинная структура.

Плата двухпроцессорная в духе современных трендов. Два Cortex-M4 на 150 и 120 МГц.

RTOS бесплатная - MQX (POSIX совместимая), с поддержкой мультипроцессорности. Обоюдный контроль процессорами друг друга.

Все протоколы и интерфейсы - TCP/IP, USB HS/FS/OTG, Wi-Fi, несколько CAN-ов, UART-ы в режимах RS485, LON, IrDA, ISO7816

Поддержка тачскрина и сенсорной клавиатуры.

Куча памяти, сверхбыстрые отладочные движки в реальном времени.

 

Только остается PLC движок портировать ну и GUI, а весь фирмварный backend практически готов.

[Myron 0]

Начать надо с выбора платформы. Например такой

Или такой:

http://www.fudzilla.com/news/mobile/37664-...ad-core-mini-pc

Two inch cube

SolidRun has added a a 2 x 2 x 2-inch Cubox-i 4X4 to its line claiming that it is the world's smallest ARM quad core 4GB minicomputer.

Dubbed the "CuBox-i 4X4," the NuC uses Freescale's i.MX6 Quad processor and 4GB of RAM. Accordingly, SolidRun claims the CuBox-i 4X4 to be "the smallest ARM quad core 4GB mini computer."

The nearest in size is the Ugoos's UT3 and UT3S mini-PCs which are eight times larger, at an estimated 5 x 5 x 1-inches.

According to LinuxGizmos SolidRun's website currently lists 2GB as the maximum RAM available on the MicroSOM, but the CuBox 4X4 is built around a 4GB version of the MicroSOM.

 

3.8GB RAM

SolidRun's CTO, Rabeeh Khoury, said that only 3.8GB of the RAM might be accessible but it will supports full HD multi format video decoding at over 100Mbps bit rate, as well as encoding of Full-HD video streams, says SolidRun.

The spec is a Freescale i.MX6 Quad processor with 4x Cortex A9 cores with NEON which run at 1GHz-1.2GHz. The GPU is a GC2000 (OpenGL/ES 2.0, OpenCL 1.1) and the RAM is 4GB (DDR3; 64-bit, 1GHz). There is a MicroSD slot for OS; eSATA II 3Gbps (i2Ultra and i4Pro only).

There are gigabit Ethernet ports but the 1000Mbps link is limited to 470Mbps actual bandwidth due to internal chip buses limitation. It has a WiFi 802.11b/g/n; Bluetooth 4.0 and HDMI 1.4. There is an Optical audio SPDIF out and InfraRed receiver and transmitter with 2x USB 2.0 hosts.

It ships with optional Android 4.2.2 microSD card;

The SolidRun CuBox-i 4×4 with an i.MX6 Quad SoC and 4GB RAM will be in the shops in May, priced at $170.

[Михась 2]

Еще добавлю, что не нравиться в плк овен ПЛК110:

1. Наличие только внутренней памяти программы -т.е. если плк сдох, память быстрее всего пропала. Желательно опционально SD карту.

2. Мало входов под энкодеры - пролетаем с моционными приложениями.

 

Проблемы модулей ввода-вывода:

3. для конфигурации даже сетевого номера на модбасе модуль надо тащить на пк для конфигурации. Предпочел бы выбор базовых параметров джамперами под крышкой.

 

Общая проблема - модбус рту очень хороший вариант для распределенной общепромышленной системы управления. Обалденая гибкость. Но часто не хватает быстродействующих модулей вода сигналов. Т.е. тут моноблоки с параллельной быстрой шиной начинают выигрывать. Была бы полезной быстрая подсистема на ethernet для сбора состояния большого количества датчиков за время не более 10мс. Могут быть полезными контроллеры позиционирования с полужесткой логикой на не менее чем три канала (аналогично с ethernet)

 

Но мое имхо - это все надо делать как расширение готового плк. плк - это последнее, с чем мы например готовы эксперементировать. Эти эксперименты ОЧЕНЬ дорогие, кк по человекочасам так и по последствиям.

Изменено 6 мая, 2015 пользователем Михась

[Driver_GV 1]

Для небольших задач себе сделал два варианта ПЛК с программированием на BASIC http://picping.lg.ua/pic_basic_4550/index.htm и http://picping.lg.ua/pic_basic/index.htm . Схемы, прошивки присутствуют, бесплатно для некоммерческого использования. Для домашней автоматизации и небольших станков/теплиц/скд вполне хватает.

[Tanya 4]

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

Не очень понятно, поняли ли Вы мою аллегорию про пересадку мозга...

В конечном итоге покупаются именно мозги разработчика, воплощенные в железо...

Чтобы не размазывать кашу по столу, отойдем по Вашей просьбе от околотехнических аллегорий про ложки, мозги и кроссовки...

Вот есть такие штучки - EUROTHERM - ПИД-контроллеры температуры. Они уже лет сто выпускаются. Только стали меньше в несколько раз за сто лет. Их покупают и вставляют в свои коробочки многие производители.

Теперь эта фирма куплена большим концерном, который делает в том числе и ПЛК.

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

Не хочется обижать, но пока я даже даром не хочу Ваше будущее изделие, только с доплатой. И еще - Вам надо еще поработать над Вашим (русским) языком.

[=AK= 12]

Начать надо с выбора платформы.

 

Начинать надо с архитектуры. Ну а раз уж речь идет о ПЛК, где главное - надежность, то именно по надежности и надо раскладывать по полочкам.

 

1. ПЛК начального уровня, имеющие минимальную архитектурную надежность. Это как раз те ПЛК, о которых до сих пор только и шла речь в треде. Это тот ПЛК, который делали вы ранее. Это те платформы, из которых вы предлагаете выбирать. Это ПЛК для теплиц предлагаемые ув. Driver_GV, который достоин восхищения за изобретательность и трудолюбие. Он даже пресловутый "специальный станок" себе сделал своими руками. Это всевозможные SoftPLC всех видов и типов. В них все свалено в одну кучу и вся работа выполняется одним процессором. Ни вам, ни TC, похоже, даже в голову не приходит, что кроме этого лапидарного подхода существует что-то еще.

 

2. Продвинутые ПЛК, в которых обеспечивается надежное исполнение пользовательского кода. Для этого в первую очередь производится разделение на основной и вспомогательный процессор. Основной работает по классическому для ПЛК непрерывному замкнутому циклу: опрос входов - вычисление - раздача результатов на выходы. Все. Никаких операционных систем, коммуникаций, прерываний, и т.п. В идеале он непоследственно исполняет IL-код, который берется из надежной памяти, с восстановлением ошибок по Хэммингу. В пример можно привести старые Сименсовские ПЛК, сделанные на микропрограммируемых секционных процессорах. Недавно натыкался на немецкую фирму, предлагающую на продажу реализацию такого процессора в FPGA, это тоже вариант. Но если нет требований к быстродействию (а при малом числе I/O их как правило нет), то с работой вполне успешно справляется обычный микропроцессор или микроконтроллер. Oднако крайне важно, чтобы интерпретатор IL-кодa был простой и надежный. Что касается вспомогательного процессора (или процессоров), то они делают все остальное, все то, что не влияет или очень мало влияет на надежность. Они заняты Модбасами, Профибасами, CAN-ами, Эзернетами, и т.п. Они обеспечивают индикацию. Они потихоньку ведут фоновую самодиагностику. И т.д. и т.п.

 

3. Дублированные системы, как это делает Текон. В них два ПЛК объединяются в единую систему, их входы и выходы соединяются, а между контроллерами ведется обмен контекстом. Один из контроллеров активен, второй находится в горячем резерве, его выходы находятся в высокоимпедансном состоянии и не мешают напарнику работать. Когда активный контроллер выходит из активного режима (по срабатыванию самодиагностики или по комаде оператора), тот, который был в горячем резерве подхватывает управление "на лету", безударно.

 

4. Системы с мажоритарным голосованием для ответственных применений, наподобие советского ПС-1001.

[_DC 0]

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

 

Зачастую потребитель хочет получить весь комплекс продуктов и услуг в одной компании, куда он обратился. Туда входят помимо ПЛК разного рода датчики, исполнительные устройства, панели оператора, а так же услуги по монтажу, настройке, гарантийное обслуживание, пуско-наладка оборудования, программы конфигурирования, OPC-серверы и т.д. и т.п. Посмотрите на сайт того же ОВЕН-а, у них там чего только нет, кроме ПЛК... И так у большинства более-менее серьёзных фирм. И именно такие фирмы представляют большой интерес у АСУТП-шников.

 

Если и "горит" что-либо разработать, то тут целиком согласен с Tanya - попробуйте сначала разработать свой собственный ПИД-регулятор температуры с широкими функциональными возможностями (с прохождением всех стадий сертификации, внесением в госреестр), предложите к нему несколько вариантов датчиков температуры разных типов на разные диапазоны, несколько вариантов твердотельное реле и, возможно, несколько вариантов нагревателей. А там уже - как дело пойдёт...

 

[AlexandrY 3]

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

 

Зачастую потребитель хочет получить весь комплекс продуктов и услуг в одной компании, куда он обратился.

 

Целесообразно и еще как. Малые фирмы с успехом берут и заказывают самодельные ПЛК.

Потому что у фирменных цены вздуты без всяких оснований.

Если набрать на стандартных модулях для ПЛК все функции которые делает одна моя плата, то цена получится выше где-то в 10 раз.

 

Начинать надо с архитектуры. Ну а раз уж речь идет о ПЛК, где главное - надежность, то именно по надежности и надо раскладывать по полочкам.

 

Ну-ну, поучите ещё нас.

Я буквально сегодня был на семинаре Wago по их ПЛК.

 

Во первых они делают ПЛК на куче разных архитектур от 8-и битников до Intel Pentium.

Во вторых они нигде не поминают эту вашу надежность. Все ПЛК от простых до крутых в одном ряду, их не выделяют по критерию какой-то надежности.

Надежность в автоматике это большая красная кнопка STOP на передней панели. Больше ничто надежность не гарантирует.

Она даже есть в самолетах!

Ну еще есть желтые модули для обслуживания цепей безопасности. Все!

Или про какую надежность вы говорите?

Что касается софта, то Wago не стесняется как ПЛК (с жестким риалтаймом-то ) продавать дивайсы с голым uCLinux на ARM7TDMI.

Так что эта индустрия немного не то, что вы пытаетесь описать.

[=AK= 12]

Надо же, какой новый авторитет в ПЛК появился, WAGO. Вы еще Феникс Контакт забыли упомянуть, они сейчас тоже средства автоматизации предлагают. Следует ожидать аналогичного рывка от Dinkle. Тоже будут устраивать семинары и учить, что "надежность в автоматике это большая красная кнопка STOP на передней панели". Соответственно, четверированные системы управления в пассажирские самолеты ставят дураки, когда достаточно одной кнопки.

[alexvu 5]

Надо разделить сферы применения.

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

В большинстве "универсальных" случаев это не требуется и экономически не оправдано.

На практике вряд ли кто ставит в системы (отопления, водоснабжения, сигнализации и т.д.) даже самых "крутых" зданий контроллеры с дублированием или мажоритарной схемой.

Да и управление технологическими процессами в 90% случаев не требует ничего такого, и действительно достаточно красной кнопки и разных электромеханических блокировок.

Для контроллера достаточно обычных мер обеспечения надежности однопроцессорной системы.

(Модули коммуникационных интерфейсов и графических дисплеев не в счет, их действительно лучше делать отдельными).

В тех же технологических системах, где требуется дублирование (резервирование), чаще всего также резервируются и электромеханические компоненты (например датчики, насосы, клапаны) и опять же достаточно 2-х обычных контроллеров.

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

Без такого резервирования технологической части, один только контроллер, сколь угодно надежный, общую надежность работы не обеспечит.

[Михась 2]

Сводить надежность системы к надежности плк просто смешно. Мы поставили чертову тучу овена и некоторое количество сименса и еще не один плк не сдох. Очень редко жгут модули ввода-вывода. На 90% отказы связаны с датчиками, исполнительными устройствами и линиями к ним. Да и никто новичку не даст устанавливать контроллеры с претензией на sil. Что тут обсуждать то?

[=AK= 12]

Мы поставили чертову тучу овена и некоторое количество сименса и еще не один плк не сдох. Очень редко жгут модули ввода-вывода. На 90% отказы связаны с датчиками, исполнительными устройствами и линиями к ним.

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

 

Собственно, по MTBF нумер 2 проиграет нумеру 1, потому что он сложнее. А по устойчивости к сбоям - выиграет с огромным перевесом. Хотя бы потому выиграет, что он в каждом цикле снова и снова пересчитывает заново пользовательскую программу. Поэтому одиночный сбой, если даже случится, промелькнет и исчезнет, уже в следующем цикле все опять будет пересчитано правильно.

[AlexandrY 3]

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

 

Собственно, по MTBF нумер 2 проиграет нумеру 1, потому что он сложнее. А по устойчивости к сбоям - выиграет с огромным перевесом. Хотя бы потому выиграет, что он в каждом цикле снова и снова пересчитывает заново пользовательскую программу. Поэтому одиночный сбой, если даже случится, промелькнет и исчезнет, уже в следующем цикле все опять будет пересчитано правильно.

 

Я ж уже писал.

Omron-ы при малейшем сбое выкидывают ошибку и встают колом.

И это считается нормальным.

О..очень сложно заставить омроны работать без ошибок долгое время.

 

У самолетов при неправильном поведении горизонтального стабилизатора срабатывает защита и они встают колом и это тоже считается правильным.

Чуть что, отключается реверс тяги и сам не восстанавливается и это нормально.

 

При сбоях никакой PLC не должен продолжать работу.

 

А сбои это результат ошибок проектирования пользовательской части ПО.

Поскольку базовое firmware сделано на сертифицированных осях оно одинаково надежно и у DIY PLC и брендовых PLC.

[dpss 5]

Вопрос к уважаемому AlexandrY. Вы несколько раз говорили про PLC движок. Он существует в бесплатном или доступном виде? Интересно было бы на него посмотреть.