Ну цвет подобрать в случае светодиода сложно — если только RGB, и там уж изгаляться. А то 525 нм они и есть 525 нм. На RGB я бы вряд ли смог плату в домашних условиях воспроизвести.
Они, кстати, не 10, они 5 мм. В оригинале диаметр светящейся точки 7 мм. За счет стекла перед светодиодами кажется, что они чуть больше, чем есть.
По-любому нужно питание напряжением поменьше 30В — в схему БП придется лезть. А так да, один транзистор на каждую группу светодиодов. Ну резисторов там парочку…
Ну я хотя бы постарался выдержать все размеры. Так определенно менее попсово, чем 7-мисегментки. Именно поэтому и отринул вот такие штуки, на ИВ-4 сегментов побольше, не похоже получится, как мне показалось.
Думаю, на одной AVR-ке средней мощности сопряжение сделать нетрудно.
А про чистую логику — как-то не очень меня это привлекает, хотя и слежу за 7400 logic competition с интересом.
Данный опыт относится примерно к 2008 году. Восхитило настолько, что вряд ли я стану когда-либо еще использовать их ПЛК. Вот их платы для управления фанкойлом — совсем другое дело, удобная, на мой взгляд, штуковина, могут, значит, когда хотят. А вот pCO* — увольте…
EBOOL — какой-то нестандартный тип, в 61131-3 он не описан… я верно понимаю, что это есть битовый BOOL, предназначенный для привязки напрямую к входам-выходам ПЛК?
Поддержу насчет ST — сам использую исключительно его.
Насчет использования всех сразу языков в одной программе — разве что как некая демонстрация возможностей, может быть? Использование такого решения в продакшене не кажется мне хорошей идеей.
А так вообще использование ПЛК такого класса для светофора — ну это даже не из пушки по воробьям :) Тут и Zelio хватило бы за все глаза, раз уж Вы продукцию Schneider предпочитате. Тот же самый FBD, кстати, он умеет.
Тоже думал на тему упомянутого развития «в вакууме» и пришел к такому выводу. Технологические процессы в массе своей — штука медленная. Это для нас 50 мс — немало, а среднестатистический вентилятор за это время едва оборот успеет сделать. Время отработки даже аварийных устройств, заслонок, например — всё равно измеряется секундами. А отсюда простой вывод: нет смысла наращивать быстродействие. Числодробилки 80-х годов разработки будет достаточно для 99% и сегодняшних задач.
А второй пункт — повышенные требования к надежности. Тот же Ethernet пришел в АСУТП совсем недавно — когда его уже обсосали со всех сторон в порядке, скажем так, бытовой эксплуатации. И именно из-за этих требований, если вывести на рынок абсолютно новую, передовую и вообще клевую среду разработки, многие инженеры отнесутся с изрядным недоверием — а вдруг оно глючит? Порой ставки слишком высоки, как писал выше тов. Vikond.
Вы знаете, CodeSys — это еще далеко не самый плохой вариант.
Есть еще куча самодельных сред для всяких ПЛК, производитель которых счел, что он и сам с усами.
Вот есть, например, такая EasyTools для контроллеров Carel. Так вот она при попытке скомпилировать такое: int i = 100000;
вылетает с синим экраном без сохранения проекта.
В той же среде (там один-единственный язык — FBD) при рисовании линий, соединяющих функциональные блоки, нет привязки. То есть: не довел мышь на один пиксель — получи ошибку компиляции. Без детализации. В стиле «у блока № такой-то есть неподключенные линии». Если этих линий штук 40, попытка найти ту, которую плохо нарисовал — крайне нетривиальная задача.
Вот еще выше автор упоминал такую поделку, как Indusoft. Тоже склонна при нажатии «compile» вылетать с исключением, не сохраняя проект.
Так что — лучше уж CodeSys.
Плюс к вышесказанному — просто нереальная для других ПЛК производительность — есть модели с процессорами вплоть до 2ГГц.
Есть не только полноценные «головы» типа CX, но и просто точки сбора данных (серия BK), которая цепляется с одной стороны к модулям ввода-вывода, а с другой стороны через тот же Ethernet к голове. Программа крутится на голове, а ввод-вывод может быть разнесен по всему объекту. И это все очень просто настраивается.
Согласен. Вроде как весьма мною любимые немцы из Beckhoff таки сделали в своем TwinCAT 3 поддержку С / С++ для ПЛК, но лично пока не пробовал. По впечатлениям других людей, продукт пока что сыроват.
Как человек, который касался и того, и того, могу сказать вот что: у ПЛК уровень абстракции от железа, конечно, выше. Но это и логично: инженер по автоматизации производства должен решать именно задачу автоматизации, а не разбираться с временной диаграммой работы, скажем, АЦП. Ему важнее понимать, что «вот на этот модуль у меня от датчика давления пришел унифицированный сигнал 4-20 мА», а уж как он там конкретно преобразуется в INT — дело, в общем-то, десятое. А инженер по эксплуатации хочет точно знать, что этот модуль не вынесет первым же разрядом, когда весенний первый гром, а как там эта защита конкретно реализована — для него это, опять же, дело десятое.
А если развить сравнение, то с таким же удивлением и непониманием на всех нас смотрят программисты, пишущие на еще более высоком уровне: как ни крути, но про ООП мы только слышали, про многопоточность — тоже, и нет у нас ни динамического выделения памяти, ни прочих благ и красот. И им наш мирок тоже кажется непонятным и зачастую смешным (впечатление сложено по итогам разговора с хорошим другом — разработчиком на Java).
Вопрос грамотной структуризации кода, я считаю. Про повышение читаемости кода на си/паскале написаны километры статей, и многое из них к тому же ST вполне применимо.
Они, кстати, не 10, они 5 мм. В оригинале диаметр светящейся точки 7 мм. За счет стекла перед светодиодами кажется, что они чуть больше, чем есть.
А про чистую логику — как-то не очень меня это привлекает, хотя и слежу за 7400 logic competition с интересом.
Поддержу насчет ST — сам использую исключительно его.
Насчет использования всех сразу языков в одной программе — разве что как некая демонстрация возможностей, может быть? Использование такого решения в продакшене не кажется мне хорошей идеей.
А так вообще использование ПЛК такого класса для светофора — ну это даже не из пушки по воробьям :) Тут и Zelio хватило бы за все глаза, раз уж Вы продукцию Schneider предпочитате. Тот же самый FBD, кстати, он умеет.
А второй пункт — повышенные требования к надежности. Тот же Ethernet пришел в АСУТП совсем недавно — когда его уже обсосали со всех сторон в порядке, скажем так, бытовой эксплуатации. И именно из-за этих требований, если вывести на рынок абсолютно новую, передовую и вообще клевую среду разработки, многие инженеры отнесутся с изрядным недоверием — а вдруг оно глючит? Порой ставки слишком высоки, как писал выше тов. Vikond.
Есть еще куча самодельных сред для всяких ПЛК, производитель которых счел, что он и сам с усами.
Вот есть, например, такая EasyTools для контроллеров Carel. Так вот она при попытке скомпилировать такое:
int i = 100000;вылетает с синим экраном без сохранения проекта.
В той же среде (там один-единственный язык — FBD) при рисовании линий, соединяющих функциональные блоки, нет привязки. То есть: не довел мышь на один пиксель — получи ошибку компиляции. Без детализации. В стиле «у блока № такой-то есть неподключенные линии». Если этих линий штук 40, попытка найти ту, которую плохо нарисовал — крайне нетривиальная задача.
Вот еще выше автор упоминал такую поделку, как Indusoft. Тоже склонна при нажатии «compile» вылетать с исключением, не сохраняя проект.
Так что — лучше уж CodeSys.
Есть не только полноценные «головы» типа CX, но и просто точки сбора данных (серия BK), которая цепляется с одной стороны к модулям ввода-вывода, а с другой стороны через тот же Ethernet к голове. Программа крутится на голове, а ввод-вывод может быть разнесен по всему объекту. И это все очень просто настраивается.
А если развить сравнение, то с таким же удивлением и непониманием на всех нас смотрят программисты, пишущие на еще более высоком уровне: как ни крути, но про ООП мы только слышали, про многопоточность — тоже, и нет у нас ни динамического выделения памяти, ни прочих благ и красот. И им наш мирок тоже кажется непонятным и зачастую смешным (впечатление сложено по итогам разговора с хорошим другом — разработчиком на Java).