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

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

Куда уж проще LADа мне кажется не существует. Обычные электрические схемы. Вы хотите создать падобие мк фирмы сименс или омрон. Так начинайте осваивать протокол передачи данных profibus, так большенство переферии в промышленности использует этот протокол или devicenet. А по поводу МК с диплеем, как предлогает ARV, это хорошая идея и очень удобно. Я имел дело с контроллерами мицубиши, так дисплей и там где он использовался, был очень удобен.
В вашем случае лад буден лучшим вариантом, стл намного сложнее в понимании. И вообще это два языка для разных задач разработаны.

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

Все современные МК работают по такому принципу. Только для интерпритации того же лад на РС и закачка данных программ на мк используется Степ7, если смотреть на сименс. А если вводить данные программ с клавиатуры, то представте массив данных программ масс [4] [8] где 4 - это четыре параметра одного элемента в программе (например нормально открытый контакт) а 8 - это восемь элементов в одной ветке. А если не одна ветка а 4, то тогда масс [4][4][8]. И вот эти все данные нужно ввести с клавиатуры, буден жутко долго и не удобно. Но возможно.

А можно вам задать вопрос zerogliff, вот вы говорите что STEP7 это жутко сложно, а с какими контролерами вы работаете у себя на родине? Просто siemens и omron в России давно стали стандартом промышленности, и я бы сказал, что они очень дорогие. А вы говорите, что у вас заказчик готов менять один бок на другой. А они ведь дорогие, а не дешевые, как вы утверждаете. Мне вот кажется, что вы пыль в глаза пускаете. Лично я в этих делах новичек, и этого не скрываю. А вы позиционируете себя довольно крутым специалистом. Не могли бы вы выложить ссылочки в интернете о ваших поделках, а то у меня складывается впечатление, что у вас сроки поджимают, и вам необходимо получить доступ к готовому исходному коду.
PS: Если я ошибаюсь, то простите меня.

А можно вам задать вопрос zerogliff, вот вы говорите что STEP7 это жутко сложно, а с какими контролерами вы работаете у себя на родине? Просто siemens и omron в России давно стали стандартом промышленности, и я бы сказал, что они очень дорогие. А вы говорите, что у вас заказчик готов менять один бок на другой. А они ведь дорогие, а не дешевые, как вы утверждаете. Мне вот кажется, что вы пыль в глаза пускаете. Лично я в этих делах новичек, и этого не скрываю. А вы позиционируете себя довольно крутым специалистом. Не могли бы вы выложить ссылочки в интернете о ваших поделках, а то у меня складывается впечатление, что у вас сроки поджимают, и вам необходимо получить доступ к готовому исходному коду.
PS: Если я ошибаюсь, то простите меня.

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

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

Хочу узнать мнение специалистов в области последовательных интерфейсов, может кто решал подобную задачу?
Продумал такое решение с входами/выходами ПЛК - по SPI гонится информация на сдвиговые регистры (74HC595) с параллельным выходом, соединённые последовательно в цепь необходимой длины (например, 32 регистра дадут 256 контролируемых выходов). Входы похожим образом, также по SPI считываются посредством регистров 74HC165 (преобразователи параллельного кода в последовательный). Для наращивания каждый модуль расширения будет иметь необходимое количество данных регистров.
Вопрос в следующем - как соединить модули? По последовательному интерфейсу будет передаваться достаточно большая частота, скорость от 1 Мбит и выше, чтобы обеспечить по моей концепции возможность, скажем, вывода частоты в 1 кГц в системе с 50 выходами (и такие иногда встречаются). Если я сделаю просто выход ТТЛ наружу - то в условиях зашумлённости среды и длинных линий (предполагается модули расширения ставить не только рядом с базовым, а иметь возможность раскидать их на управляемой производственной линии) сигнал будет сильно искажён. Была идея передавать через микросхемы интерфейса 485 по стандартной витой паре (4 пары, 4 сигнала SPI) - но эти микросхемы, поддерживающие скорость хотя бы 5 Мбит стоят уже приличную копеечку, а их надо будет немало (на базовом модуле 4 шт, на каждом модуле расширения по 8 шт). К тому же из за такого параметра, как задержка распространения сигнала, надо будет снижать частоту передачи в системах с большим количеством модулей расширения.
Может ли кто посоветовать более изящное решение? Либо я остановлюсь на варианте с RS485...

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

Для сдвиговых регистров: 26LS31/26LS32 (26C31/26C32)- 4 передатчика/4 приёмника - дешевле (чем специализированные RS485), но места займут больше.
При таком количестве каналов я бы разбил на отдельные контроллеры с RS485. И получится не сильно дороже.

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

Да, недешёвое решение )) но с заведомой гарантией, согласен. В вашем варианте правда придётся создавать этот защищённый интерфейс (протокол с контрольной суммой?).

При таком количестве каналов я бы разбил на отдельные контроллеры с RS485. И получится не сильно дороже.

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

передача данных на расстояние в индустриальных условиях без контроьной суммы - я бы за такое решение ни в жисть не поручился бы... SPI - совершенно непригоден для передачи информации во-первых на большие расстояния, а во-вторых, без особого протокола, т.к. проскакивание малейшей помехи по линии CLK гарантирует вам 100% потерю синхронизации с непредсказуемыми последствиями.

zerogliff пишет:

При таком количестве каналов я бы разбил на отдельные контроллеры с RS485.

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

По сути, ARV сказал Вам то же самое насчёт отдельных контроллеров, "соединённых по защищённому интерфейсу". И прислушайтесь, что он говорит по поводу сбоя по CLK.

По поводу SPI: использовал в тренажере (серийно производимом) датчик на кабеле ~3м с интерфейсом SPI. Но сами сигналы SPI по кабелю передавались в виде парафазных (использовались драйверы RS485 интерфейса). 2631\2632 не использовал из-за громоздкости, хотя можно было.

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

Удаленные модули ввода/вывода на базе МК и RS 485 - это лучший вариант. Моё мнение, что так работают почти все современные промышленные МК. SPI это плохой вариант, а RS 485 - это стандарт в промышленности, где миллион помех, наводок и большие расстояния и разбросанность переферии. Только нужно протокол передачи данных подобрать, все уже придумано до нас. Или придумать свой, например: ZerogliffBus или DruidNet.

Alexey_Sh пишет:

zerogliff пишет:

При таком количестве каналов я бы разбил на отдельные контроллеры с RS485.

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

По сути, ARV сказал Вам то же самое насчёт отдельных контроллеров, "соединённых по защищённому интерфейсу". И прислушайтесь, что он говорит по поводу сбоя по CLK.

По поводу SPI: использовал в тренажере (серийно производимом) датчик на кабеле ~3м с интерфейсом SPI. Но сами сигналы SPI по кабелю передавались в виде парафазных (использовались драйверы RS485 интерфейса). 2631\2632 не использовал из-за громоздкости, хотя можно было.

Но ведь Вас сбои по CLK не остановили? И какова надёжность вашего решения? Отказы были, есть какая либо статистика?

В моем случае сбой - не сильно страшно. Прочитал несколько раз - выпадающие значения выкинул. Благо время есть - это датчик положения рулевого колеса. Про статистику на сбои ничего сказать не могу, так как не имею доступа к этому проекту после разработки. Однако ни программист меня по поводу сбоев не беспокоил, ни заказчик, который не первый год продолжает собирать тренажер с этим датчиком.

Отказ - это когда что-то сгорело или отвалилось. При мне во время сборки и тестирования единиц десятков изделий такого не было.

Но: если бы я управлял устройствами, которые от сбоя по управлению могут выйти из строя, то применил бы отдельные контроллеры с CAN или RS485. SPI со сдвиговыми регистрами я не могу контролировать на предмет сбоя. Поэтому ничего, кроме мигания светодиодами (при сбое не сгорят) такому решению бы не доверил.

Послушал все ваши советы - выкинул из концепции расширение путём SPI
По причине отсутствия и трудной доставаемости контроллеров с аппаратным CAN (я всё же рассчитываю на дешевизну решения) - от варианта с CAN отказался. Туда же забросил идеи с Profibus. Понимаю - стандарт, понимаю - получил широкое распространение, НО его поддержка мне обойдётся в кучу денег и времени, и я прикидываю, что овчинка выделки не стоит, так как заказчики, использующие такие протоколы в своих устройствах, уж наверняка найдут средства на промышленный ПЛК типа Siemens'ов.
Остановился на сети USART <-> RS485. USART аппаратный есть почти во всех контроллерах.
Концепция будет такова:
- сеть организована по витой паре, в режиме полудуплекс, с 1 ведущим (базовый модуль) и до 32 ведомых (самые простые драйвера RS485 позволяют подключить до 32 устройств в сети). Из них 1 заранее зарезервирован за модулем дисплей/клавиатура, итого 31 модуль расширения
- ограничим длину сегмента сети для обеспечения максимальной скорости. Предположим, рассчитаем длину сегмента для скорости в 1 Мбит, и будем считать, что эта скорость гарантирована в сети (пусть если даже это будет всего 10 метров).
- обговорим пакетный протокол: 1 байт заголовка, 1 байт адрес + длина данных (5 бит адрес, 3 бита длина данных, итого до 8 байт данных), 1 байт контрольная сумма. Итого длина пакета максимум 11 байт. Содержимое данных зависит от конкретного модуля расширения. Контрольная сумма должна считаться налету, это будет просто дополнение до 0 суммы всех байт пакета по XOR.
- Базовый модуль всегда слушает линию, включает передатчик только в момент передачи. Таким образом он будет сам контролировать переданный пакет (как только переданный байт не будет равен принимаемому - фиксируется коллизия, передача останавливается, и начинается заново через определённый промежуток времени)
- приёмник всегда слушает линию, и также включает передатчик только когда пришёл пакет от базового модуля. Контроль за переданным пакетом схож с контролем базового модуля, за исключением, что прерванная передача не возобновляется.
- Базовый модуль опрашивает по циклу все модули. Каждый модуль, получив пакет (это может быть пакет с состояниями выходов), формирует ответный пакет (например, пакет с состояниями входов). Для обеспечения синхронности введём квоту времени на сеанс связи между базовым модулем и модулем расширения. Считаем - 11 байт, по 10 бит каждый => 110 бит в одну сторону, ответный пакет тоже до 110 бит - итого 220 бит на сеанс связи. Прибавим гарантированную задержку в 1 мкс (1 бит) между концом передачи пакета от базового модуля и началом приёма от модуля расширения - итого 221 бит. Пусть будет с запасом 250 бит. На скорости 1 Мбит это 2.5 мс на сеанс связи. Если в течение времени, необходимого для передачи одного пакета, модуль не начал передачу (не передал ни одного байта) - запрос повторяется еще один раз (вдруг он не принял нормально пакет от базового модуля). Если же передача началась, но пакет не пришёл полностью, либо пакет пришёл битый (неверная контрольная сумма) - запрос не повторяется, сеанс закрывается. Итого - 5 мс на сеанс связи с модулем расширения. При максимальном количестве модулей 32 - цикл опроса равен 160 мс. Каждый цикл опроса состоит из задания нового состояния выходных параметров, и опроса текущего состояния входных параметров. Исходя из вышесказанного, максимальная задержка реакции системы на изменение любого входа - 160 мс.

КРИТИКУЙТЕ!!!