Мини-ПЛК: открытый проект

как настроить я и сам не очень понимаю... когда я это делал, то наполовину методом тыка, наполовину по советам других кое-как настроил Eclipse, сейчас уже и не вспомню, тем более что при написании статей про Eclipse я неоднократно ставил и сносил разные версии, в результате чего плагин для CVS у меня теперь отсутствует

можно просто открыть по ссылке проект на code.google и посмотреть в браузере. там, по-моему, и скачивать можно...

Эх, жалко.
Многоуважаемый ARV, я вам очень благодарен за помощь в обучении. Я прочитал ваш учебник, который вы печатали в Радио журнале, и очень много ответов, которые вы давали на одном из форумов (с которым у вас сейчас не лады). А по ECLIPSE, так вообще золотые статьи у вас. Сейчас только ECLIPSE и пользуюсь.
И ваши уроки не прошли даром, если повезет, то я оформлю свой первый в жизни патент примерно через пол года. Сейчас в связке с одним из университетов я работаю над одним интересным проектом в свободное от основной работы время.

ARV пишет: это все замечательно но есть ряд вопросов.
1. вы рассматриваете свой проект просто как аппаратную платформу с более-менее устоявшимся набором периферии, а программное обеспечение планируете писать как обычно, т.е. на Си или там С++ - верно? в этом случае мы снова приходим к проблеме доступности ПЛК для непрограммистов
2. подключение через RS485 клавиатуры, дисплея - тут есть какие-то стандарты или как это все планируется?
3. аппаратный ШИМ 2 МГц при 16 битах - это какая аппаратная поддержка?

все эти вопросы у меня связаны в связи с тем, что моя идея была в создании ПРОСТОГО, НЕДОРОГОГО и ДОСТУПНОГО НЕПРОГРАММИСТУ устройства, способного выполнять достаточно много функций по задаваемому пользователем алгоритму.

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

1) Программное обеспечение предполагалось сначала писать на Си, НО!!! для создания удобной среды использовать бесплатный компилятор, написать готовую библиотеку типа операционной среды, которая будет обрабатывать макросы, а уже макросы писать наподобие VHDL или же придумать свои конструкции, которые будут транслироваться в нашей среде в код на Си и тут же компилироваться. Это только задумка, но она имеет смысл, даже несмотря на кажущуюся сложность в воплощении.
2) Клавиатура, дисплей - придумать свои стандарты. Например для строчных дисплеев можно вообще использоват55366ь просто вывод, как на терминал. Для графических придумать свой протокол.
3) Насчёт ШИМ имел ввиду, что это будет реализация на аппаратном ШИМ контроллера, например таймер 1 в ATmega16, режим 16 бит, 2 МГц тактировка таймера (частота ШИМ соответственно 2 МГц/65536)

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

zerogliff, при всем уважении - но вы ведь тоже не прочли описание моей концепции? я предполагал базовый блок с 8 входами, каждый из которых может быть простым входом, аналоговым входом или входом температурного датчика DS18x20, и с 8 выходами, 2 из которых опционально могут быть ШИМ-выходами. Так что такой ПЛК мог бы управлять светом в целом доме из 4 подъездов, причем с коррекцией на освещенность, открывание дверей и время года

ARV пишет: zerogliff, при всем уважении - но вы ведь тоже не прочли описание моей концепции? я предполагал базовый блок с 8 входами, каждый из которых может быть простым входом, аналоговым входом или входом температурного датчика DS18x20, и с 8 выходами, 2 из которых опционально могут быть ШИМ-выходами. Так что такой ПЛК мог бы управлять светом в целом доме из 4 подъездов, причем с коррекцией на освещенность, открывание дверей и время года

Да, описание вашей концепции я не то чтобы не прочёл - я его не смог отыскать
Пытался на Гугле скачать что либо о проекте - ничего не вышло.
Что же, ваш вариант отличен от моего, но здесь, разбирая детально, можно увидеть, что наши с вами реализации - это всего лишь вариации одной концепции. Если можно детальнее изучить ваши концепции - пошлите меня в нужное направление, я буду рад ознакомиться.

zerogliff пишет: Да, описание вашей концепции я не то чтобы не прочёл - я его не смог отыскать

а разве эта тема форума вам недоступна для просмотра? www.simple-devices.ru/forum/Mini-PLC-Team

Доступно, не видел раньше... Читаю, спасибо за ссылку.

Итак, я просмотрел...
Что понравилось - задумка насчёт программирования ПЛК на месте, очень интересная концепция ввода программы.
Всё, что увидел - концепции программирования ПЛК, реализация программного обеспечения. Обсуждения концепции железа, как такового - нет. В этой области у меня к вам куча вопросов.
1) Как предполагалось реализовывать в железе настройку порта на цифровой/аналоговый вход?
2) Как предполагалось масштабировать систему? Подключать дополнительные входы/выходы?
3) Почему в концепции железа не заложен промышленный RS485?

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

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

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

как-то так...

Теперь я понимаю основное отличие наших концепций.
Ваша концепция предполагает любительское использование ПЛК. То есть, захотел - собрал конструктор с нужными тебе блоками, залил туда прошивку, написал программу-автомат. И просто, и экономно, и универсально.
В моей концепции я предполагаю некий полупромышленный ПЛК, с различными реализациями базового модуля (их будет больше 20 точно), каждая модель со своим набором входов/выходов (посмотрите на набор модулей фирмы Delta, Siemens, Omron). Данный ПЛК не надо будет конструировать - вся задумка стоит на различиях в наборе функционала базовых модулей. Здесь есть куча своих трудностей - иногда ты просто можешь не влезть в функционал ни одного из предлагаемых блоков, и пара входов или выходов, которые тебе захочется добавить, сыграют свою роль на стоимости системы в целом.
Я объясню смысл моей концепции. Всё зависит от области распространения данной разработки. В нашем регионе разработчиков-любителей намного меньше, чем в России (я сам с Ташкента). Здесь люди давно привыкли просто платить за готовое, чем заказывать разработку. Главный принцип - дёшево и как можно быстрее. Поэтому концепция ПЛК-конструктора, состоящего из кучи плат, которые набираются в зависимости от задачи, будет выглядеть невыгодно по сравнению с готовым блоком в корпусе с жёстко заданным количеством выводов и их функционалом. Если этот блок вылетит - его просто поменяют, чинить его скорей всего не будут. Копаться самостоятельно в программировании этого блока - тоже навряд ли, даже если будет куча открытой документации и даже если я пользователю подарю бесплатно книжку по написанию программ-автоматов для моего ПЛК. Простая инструкция типа "при такой-то поломке заменить базовый блок, залить в него эту прошивку с компьютера" - максимум, на что способны наши якобы "специалисты".

Плюс ко всему вышесказанному. В Вашей концепции я считаю очень неудобным расположение дисплея и клавиатуры прямо в корпусе с базовым модулем. Зачастую автоматы, управляющие большими промышленными линиями, стоят в неудобных для доступа местах (шкаф управления например), а органы управления автоматом выносятся наружу (кнопки, индикация). Всё это ведёт к прокладке большого количества кабелей (недавно делал автомат для наклейки этикеток на бутылки - 9 кнопок, 1 переключатель режима, 6 индикаторов - толстый шлейф из проводов, расходящийся по реле, пусковикам и так далее). Один моноблок, включающий в себя дисплей и клавиатуру, установленный удалённо от автомата и подключённый всего лишь 3 проводами интерфейса RS485 (3-й провод - экран или выравнивающая потенциалы "земля" - вот это экономия и нервов, и денег на кабеля). Если же учесть, что можно грамотно продумать протокол обмена - такие дисплейно-клавиатурные моноблоки можно делать в разных вариациях, не меняя основной прошивки базового блока.

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

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

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

что касается вашего варианта, то предлагаю вам посмотреть в сторону CAN-интерфейса. очень удобно в плане надежности передачи информации: если с RS485 вам надо городить какой-то протокол обмена, гарантирующий, что в условиях помех информация дойдет без искажений, CAN на своем аппаратном уровне гарантирует доставку ваших 8 байт данных. этот интерфейс можно и не только для дисплейно-клавиатурных модулей применять, но и для других целей. например, небольшая плата с ОУ для приема сигнала с термопары - добавляется МК с CAN и эта плата сама будет посылать значения температуры по шине, таких плат на шину можно посадить хоть сто штук - с другого конца шины будет стоять основной контроллер и получать и обрабатывать эти данные. сигналы управления исполнительными механизмами так же можно посылать по CAN - экономия на сигнальных проводах

Теперь, имея ввиду Ваши наработки, я попытаюсь всё же сделать то, что, возможно, покажется нереализуемым - разделить концепцию железа и концепцию программирования ПЛК. Как бы абстрагируясь от железа, я попробую возродить Вашу концепцию программирования ПЛК. Мне очень импонирует Ваша концепция, и если вы не будете возражать, я попытаюсь воплотить её на своём железе.
Спасибо за подсказку по поводу CAN - это задумки на будущее, если таковое будет у этой разработки. CAN-интерфейс как таковой в нашей промышленной автоматике встречается реже (всё же аппаратура у нас староватая). Пока что планируется разработка 3-х серий базовых модулей: на ATmega8/48/88/168 (серия Micro), на ATmega16/32 (серия Mini), на ATmega64/128 (серия Base). Отличаться будут набором функционала, набором входов/выходов, объёмом памяти для программы пользователя.
Начинать буду с серии Micro, после удачного запуска на чистом Си буду внедрять концепт программирования по типу STL, FBD, исходя из Ваших наработок (опять же, если вы не против). Всё это опять же по причине срочной необходимости через месяц сдавать первый автомат.

Глянул тут на STEP7 - ну чистейшей воды программирование. Типы данных - ну только программерский склад ума нужен. Те же Ladder Diagram - сложная для моего разума система релейных переключателей. Нужно что то лёгкое и понятное даже школьнику. Пока решения не нашёл...

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