Возможно, NodeJS всех достал, всем приелся, не нужен, опасен и так далее. Существуют и альтернативные мнения. Зачем ставить ноду на плк - это вообще вопрос для отдельных философствований. Тем не менее, я это сделал и сейчас расскажу как.

Пока у меня был доступ к этому контроллеру, который, кстати, является новинкой российского рынка, я экспериментировал с ним.

Производители поддерживают написание приложений на С/С++ для предыдущего своего контроллера на линуксе, а для этого, судя по всему, не подготовлен тулчейн. Да и приклад на с++ на контроллере - это не новость. Впрочем, нода - это тоже не новость для многих читателей.

Свой веб-сервер у контроллера уже есть. Своя веб-морда есть. Но всё это работает "не так как я хочу". Вспомнив о том, что в линуксе можно всё - я занялся подключением NodeJS.

Прежде всего, у контроллера не настроены dns. Это не сложно. Открываем /etc/network/interfaces и добавляем строку "dns-nameservers 8.8.8.8".

Затем добавить репозиторий в /etc/apt/sources.lost строка:

"deb http://ftp.de.debian.org/debian/ jessie main contrib non-free"

Установка node js: apt-get install nodejs

Установка npm: apt-get install npm

Вот, собственно, и всё, среда установлена, можно подключать модули и запускать скрипты.

Сразу несколько предупреждений:

1. У контроллера ограничена оперативная память. Надо оптимизировать код и исключать утечки памяти.

2. Для запуска скрипта в фоне - понадобится менеджер процессов. я использовал pm2.

О передачи данных в проект:

Стандартная среда программирования для этого контроллера - поставляемая производителем (бесплатная) SMLogix. В этой программе реализована возможность всесторонней передачи данных через механизм Shared Memory (разделяемая память). К сожалению, у меня было недостаточно времени для экспериментов, чтобы наладить связь скрипта с лоджиком. Ограничивает отсутствие в широком доступе адекватных библиотек для этого.

Тем не менее, способы лёгкого взаимодействия со скриптом есть.

Уважаемые читатели, если тема нестандартного использования заводских контроллеров на примере Segnetics (их у меня больше всего) вам интересна - плюсуйте, я выкачу и другие интересные возможности! Пожелания приветствуются!

Приветствую, дорогие читатели! Давно меня мучила одна животрепещущая тема - а что же на самом деле "сделано в России"?

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

Китайцы – очень трудолюбивы. Они готовы свой труд продавать за деньги и делают это всегда и почти без проблем. Это доказывает как минимум то, что их бюджет формируется только за счет экспорта на 95%. Соответственно можно купить продукт любого китайского производителя (получить эксклюзивный контракт), чтобы он ставил вашу наклейку на продукт.

Схема представлена на картинке. Работает так:

1. Российский бизнесмен выбирает понравившийся ему китайский продукт.

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

3. Получается товар, полностью китайский, но сделанный по заказу кого угодно, как угодно.

4. Далее логистика в Россию.

5. В России с этим продуктом делают незначительные действия. Например, вкручивают один болт (утрирую, конечно).

6. Теперь продукт называется «сделано в России».

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

В такой схеме, по факту, потребители покупают китайский товар, возможно, даже не догадываясь о его происхождении. Наверняка, цена на оригинальный (китайский) прибор значительно ниже его «российского» аналога. Это из-за посредника, который выставляет чужой продукт за свой, вкручивание «Российского болта», требует денег на зарплату сборщика.

Контроль качества здесь может отсутствовать. Так же, возникают серьёзные проблемы с технической поддержкой, так как местные представители не являются, по сути, производителем. А настоящим производителям нет дела до конечных потребителей, так как их потребитель – заказчик оборудования.

Такая схема – самая простая для получения «импортозамещающего» оборудования.

2. Российский продукт, комплектующие со всего мира, Российский бренд.

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

Рассмотрим эту схему.

1. Все концепции и схематические решения разрабатываются российскими инженерами.

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

3. Подобранные и закупленные в разных уголках мира комплектующие приезжают на участок сборки.

4. На выходе, после контроля качества всех этапов получается прибор, созданный из современных и проверенных компонентов. Обладает конкурентными ценой и характеристиками.

5. Продаётся по всей России как настоящий отечественный продукт, каким и является.

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

3. Российский продукт, российские комплектующие, Российский бренд.

Без лишних слов взглянем на схему:

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

2. Инженеры исследуют рынок в поисках местных комплектующих.

3. Все детали и компоненты попадают на сборочную линию.

4. Стоимость готового продукта получается «космической».

5. Покупателями такого продукта будут, в первую очередь, государственные структуры. Армия, Роскосмос и т.д.

Откуда берётся «космическая» стоимость?

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

Кроме того, важным фактором является упадочное состояние электронной промышленности в Российской Федерации. Многие импортные компоненты не имеют отечественных аналогов.

4. Выводы.

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

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

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

Кто что по этому поводу думает? Приглашаю в комментарии!

Длиннопост. Речь пойдёт о программировании промышленных логических контроллеров.

Всю свою рабочую жизнь я занимался наладкой автоматических систем управления. Сначала это были только котельные и тепловые пункты, потом ещё разные газоиспользующие установки, а потом дело дошло и до автоматизированных производственных конвейеров, промышленных роботов и прочих прекрасных вещей. Использовал я всякие разные контроллеры. Это были Овен, Сименс, Дельта, Сенека. Просто восьмибитные микроконтроллеры и stm32.

Я всячески избегал FBD. CoDeSys позволял писать программы на паскале-подобном языке (ST). Это было близко и понятно. Хотя я и разбирался в принципиальных электронных схемах, я всё равно не любил использование FBD, уже хотя бы за то, что некоторые вещи просто не знал как реализовать. Использование графических языков всегда занимало массу времени, результат получался ниже среднего.

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

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

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

После того, как я выполнил несколько реальных проектов на их контроллерах, пришло понимание, почему в лоджике нет возможности писать код внутри блока текстовым языком. Дело не в том, могут они это разрешить или не могут. Дело в том, что это не нужно. Составляя программу на фбд, программист не может прострелить себе ногу. А вот текстовые языки, в большинстве случаев, позволяют это сделать в пару строк, а то и в одну. А ещё бывает, что нога простреливается по незнанию, неумению, невнимательности, и ещё тысяча причин.

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

Крутые примеры у меня есть. Приводить их здесь, конечно, не буду. Скажу только, что делал несколько проектов для их сенсорного контроллера. У заказчика были высокие требования к интерфейсу. Это было особенно "болезненно" для меня, так как я никогда не делал серьёзных интерфейсов ранее. Максимум менюшка со списками. А здесь нужно было и анимацию сделать, и всякие жестовые штуки (свайпы, пинчи и прочая вот эта ерунда).

Теперь скажу и о негативной стороне. В частности, когда нет заводской "из коробки" поддержки жестов - приходится танцевать с бубном в этом fbd. Не сказал бы, что реализация нормального "драйвера тач скрина" на фбд невозможна. Да, это не просто, но это выполнимо, и в конечном итоге, работает адекватно. В целом, новый продукт хоть и понравился, но софт заточен под старое. Что ж, лично я буду надеяться, что они-таки выпустят что-то новое, в плане приклада.

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

P.S. Написал некоторые вещи с использованием NodeJS, который запустил прямо на trim5. Изврат? Возможно... Но если очень хочется - то можно вообще не использовать штатные средства программирования. Linux же.