Комментарии 86
и вся на практике как раз выяснятся что грамотный обвес это 90 процентов успеха
иначе порты дохнут, глюки на входах и т.п.
а что за программа внутри на сегодня это 20 % успеха
неплохо можно и с нуля на си написать
А вот что надо в вашем случае, чтобы точно также посмотреть онлайн программу через SWO? Это вообще не одно и то же, вообще!!!
А про привязку к программатору я и не писал — это вы выдумали вообще. А printf в наши дни — это откровенная ардуинщина и костыли.
SWO в своё время оказалось единственным средством отладки стека TCP/IP в режиме исполнения — это о чём-то говорит.
Тут промышленное программное обеспечение, которое взаимодействует с платой. А то, что оно без рюшечек — уж извините, вам шашечки или ехать всё таки.
А вот насчёт картинок — да, надо исправить, чтобы было видно полностью. Если уж очень горит — то ПКМ-Открыть в новом окне. И будет вам счастье полноценного просмотра. Но статью буду переделывать…
Отлично, что все это удалось сделать на дешевой платке.
У меня такое впечатление, что вы просто ни разу с промышленными ПЛК не работали.
ну хотя бы вики почитайте, про IEC 61131-3, про ladder, про SFC.
ПЛК — это совсем иной мир, идущий от релейно-контактных схем. И да, только в промышленности используются такие языки, что электрику прочесть код проще, чем программисту.
Вот кстати, про читаемость кода ПЛК. Бывает, его и электрики пишут, совсем не знакомые с понятием ООП. Это такая боль и вермишель...
Вы, наверное, имели в виду текстовое отображение всё-таки и стиль написания «лишь бы скомпилилось»
Нет, в графическом тоже бывает такого понаворотят… У нас программы очень сложные, их разбивают на подпрограммные блоки — функции. Например, входные параметры функции могут изменяться из сотни других функций. Иногда даже инструмент cross reference (мощный аналог find) не спасает, поскольку изменяются параметры с помощью указателей (у Siemens такое можно).
Кроме того, был написан модуль автоматической диагностики, которы по переключениям находил причину с шансом 99.9% (мы не писали часто переключаемые временные переменные, поэтому 0.1%).
Удивительно, но единственный случай, когда автоматички не согласились с диагностикой решился в пользу програмы. Там было сложное четырезхтактное срабатывани и автор кода просто не увидел, что он может сработать настолько хитрым путем.
Так что можно и 0 секунд — ladder вполне позволяет автоопределение.
Дело в том, что требования качества вавтоматике, совсем иные, чем принципы ООП.
Во-первых, любой отказ датчика должен диагностироваться и не мешать работе (возможно с некторой деградацией), двойной отказ — обязан диагностироваться, по возможности с продолжением работы с деградацией. Тройной отказ — диагностировать по возможности.
Это означает, что для контроля используются дачтики из совсем других блоков. Например, самолет запрещает реверс при отсутствии раскрутки колес набегающим воздухом после старта. Где двигатели и где колеса?? :-) У вышупомянутом криз-контроле отказ дачтика оборотов колеса легко диагностируется по подаче топлива в двигатель и включению сцепления. Но… это не влезло в ООП, отсюда — и многочисленные трагедии.
Второй момент. Для надежности любой выход должен устанавливаться только в одном месте. Для той же надежности (и модифицируемости) лучше не использовать промежуточные переменные. В итоге формирование аварии — это такая большая простыня со смесью сигналов из разных подсистемю
Третий момент — хороший код автоматички способен выполняться параллельно. То есть не должен зависеть от порядка выполнения нетворков.
Автоматчику — удобнее и надежней и читаемей именно такой код. А для тех, кто с автоматикой не знаком — такой код, конечно, будет слабо читаем.
Кстати, у меян в системе был модуль упрощения нетворков. То, что выдал этот модуль — не прошло. Читаемость меньше, модитцируемость хуже. Хотя выполнялось чуть быстрее.
Так что множественная запись не запрещена, но нежелательна, ибо делает код трудночитаемым. А это время — а обычно в полях его как раз и нет. Но ещё хуже, когда двоичную логику реализуют на языке типа STL( SIEMENS) — вот тут по времени уже намного хуже, чем в визуальных вариантах.
двоичную логику реализуют на языке типа STL( SIEMENS)Неужели у сименса настолько слабый софт, что не позволяет отобразить STL как ladder? Быстренько глянул доку — судя по главе 1, он должен это уметь.
Хотя STL — это не стандартный IL, с ним может быть чуть хуже.
Но вот я например, расчёты предпочитаю делать на STL — потому что на LAD и FBD получается сложновато. И указатели тоже нужны — особенно, когда с массивами работаешь. Всё надо просто применять там, где это необходимо. То есть без фанатизма и предпочтений к какому-то одному языку.
Но ведь можно сделать у блока входа и выхода, верно? Получится некоторая аналогия функции в классическом яп. А то делают так, что другие блоки модифицируют переменные внутри не своего блока. А еще хоть и делают функции, но изменяют их параметры из сотни мест, при этом иногда через указатели.
У меня был подобный код. В конце скана код записывал измененных входы, выходы и временные переменные (по маске) и писал кадр в кольцевой буфер. А сервер вычитывал данные из кольцевого буфера и вел архив переключений.
На ассемблере это смотрелось нормально. Но на ladder… ну в общем я никому не советую читать это на ladder. Вычитывали эти 300 строк 5 человек (и каждый расписался за приемку). Потом поставили на стан — и заработало. Ответная часть на сервере была из 10 тысяч строк. :-)
А с ФБ у вас скорее всего сказывается недостаток функциональности самого ФБ. По уму, такое дело надо лечить написанием своего, объемлющего ФБ, но я понимаю, почему проще динамически править параметры.
Первое, что приходит на ум — изменение постоянной времени у пид-регулятора. Есть быстрый режим и медленный, надо переключаться между ними, а функциональности самого пид-регулятора не хватает.
Я обычно на LAD предпочитаю читать код. Просто очень часто код, написанный на STL и прочих ассемблерах, в графический вид не переводится, я и не знал, что такое возможно, если с нуля писать на STL.
А по поводу ПИД регуляторов разговор особый. Их вообще надо ставить в отдельный блок с фиксированным временем вызова. Я тут придумал одну фишку, чтобы уменьшить боль инженерам, которые будут этот код читать. Надо всего лишь сделать в основной программе отдельный блок для управления параметрами ПИД регулятора. И менять параметры только в нём.
Надо всего лишь сделать в основной программе отдельный блок для управления параметрами ПИД регулятора. И менять параметры только в нём.Мне не нравится. Я бы сделал ФБ — «ПИД-регулятор + изменение настроек». И использовал бы его. То есть переключал и регулировал бы настройки входами.
Для ПИД регуляторов хорошо так делать, если логика переключения параметров небольшая. Иначе мы просто бесполезно будем занимать критичное время выполнения процессора (читайте это как код в прерывании, коим оно и является).
Для ускорения — ФБ может менять параметры по отдельному сигналу «сменить параметры». А пока этого сигнала нет — не менять.
А зачем вам вообще работа по прерываниям? Почему не в общем скане?
Строгое известное время между вызовами блока ПИД необходимо для правильной работы И и Д звена. Они выполнены по математическим численным методам приращения. Это же дискретная логика, тут нет никакого аналогового сигнала интегрирования и тем более дифференцирования. Отсчеты выполняются дискретно. И чем меньше время между отсчетами, тем точнее. Его стараются делать как можно меньше и из-за этого бывают казусы. У меня как-то было, что основной цикл программы не всегда успевал выполняться, всё время происходила непрерывная обработка прерывания.
Дело несколько не в отладке. Вы что думаете, отладил и забыл?
Представьте себе стан. Остановка стана — 40 тысяч долларов (рулон стали), улетевший в брак. А на стане — куча датчиков, которые иногда отказывают.
При аварии или предаварии оперативно или меняется программа для обхода отказвшего датчика или ставится блокировка (показания датчика принудительно приводятся к 0 или 1). А уж потом, раз в месяц, стан встает на ремонт и все отказавшее — меняется.
Времена отказа считаются в минутах(!!!) в год. Например у автоматчиков несколько лет подряд было 0 минут простоя в год по их вине. Это при 8 тысячах входов и 2 тысячах выходов, контролируемых дюжиной ПЛК
А теперь попробуйте воспроизвести это на Си с любым отладчиком. Отладчик с возможностью загрузки отдельной измененной процедуры (нетворка в терминологии Ladder) найдете?
P.S. Это АНГА, цех ПХЛ, Северсталь.
P.P.S А время на реальную отладку нового кода на живом стане — 2 часа в месяц. Это когда стан выходит из ремонта, но ещё не вошел в режим.
2) Насколько помню ПЛК создавали, чтобы любой электрик бывший мог заниматься автоматизацией и требовалось бы держать программиста, который в разы дороже.Поржал. Ваш уровень знаний понятен.
Вообще-то любой процессор — это релейно-контактная схема. Так что верно иное — любой автоматчик способен составить схему процессора.
На вашем уровне — считайте, что ПЛК — это такая ПЛИС. А программирование ПЛИС и ПЛК имеет много общего.
Для понимания — можете попробовать на РКС написать… ну скажем делитель частоты на 7. На голой логике, то есть И, ИЛИ, НЕ.
Вроде как RS-485 всегда имеется на таких вещах,Считать не умеете. Скан 20 мс. Сколько датчиков вы за это время сумеете опросить по RS-485? Поэтому используются высокоскоростные шины.
при должном умение в код на С/С++ можно вносить изменения прям на ходуПродемонстрируйте. :-)
А вы точно умеете разрабатывать ПО для МК?Умею, а что? Ничего хитрого в МК нет. Моему софту вообще все равно, он работает и под windows и под *nix и под FreeRTOS. Скорее уж хитрее всего с linux, когда приходится править ядро или драйвера. На FreeRTOS как-то баги в драйверах проще ищутся.
мешает вам создать архитектуру кода так, чтобы вы могли без перепрошивки «обойти» любой датчик?Создайте, а мы посмотрим. :-)
P.S. Ну в общем считайте, что ПЛК это такая ПЛИС — и вам сразу все понятней будет. Для ПЛИС-то хоть хоть как раз писали?
Понятно, написать не смогли. А учебники «для электриков» читайте сами, мои интересы в другой области, лет 35 уже как от радиогубительства отошел.
P.S. ну а то, что ваши вымыслы про С++ не смогли подтвердить реализацией — это типично.
Это высокоточная спутниковая навигация. С точностью 5 миллиметров СКО. Так что с одной стороны — GPS, ГЛОНАСС, GALILEO, а с другой — атомные ледоколы, автовождение тракторов и грузовиков, шлюзы, военные беспилотники, перевозимые на двух грузовиках…
Если вы на самом деле инженер — то сумеете с 5ой приемкой сделать. А если так, обычный малолетка, то сидите в мире бытовухи и не суйтесь туда, где нужна надежность.
Для обычных применений мы тоже на STM32H7 делаем. Но мы умеем выживать и там, где реально нужно 20 лет работы без сбоев.
Аирбасы, боинги… Знаете какой там GPS-приемник? 12 каналов, характеристики такие, что любая бытовуха за пояс заткнет. Элементная база — ну где-то года 1990ого, если не раньше. Это вот то, что летает. Пару лет назад начали поставлять новые. С характеристиками примерно 2000 года. Зато — не ломается. Промышленное решение. Судя по корпусу — оно и крушение самолета переживет, если пожар недолгим будет.
Ещё пример. 2002 год, та самая Северсталь.закупаем для ПЛК сетевую плату. Бытовые 100мегабитные — стоят 10 долларов, а эта — тысячу. протокол — Ethernet II, то есть 2 мегабита. Зато — не ломается.
Сейчас занимаюсь индастриал решениями (силовые преобразователи с гарантией 15+ летСколько проживут ваши преобразователи в цехе, если даже в бытовке за месяц прямо из воздуха выпадает миллиметр металлической окалины?
У вас стопроцентный входной контроль деталей есть? А реальная наработка на отказ по тем же деталям известна? Или только теоретическая, в камерах ускоренного старения?
Доводилось работать с клоном альтеры из Воронежа, тихий ужас…"Ну, да! Ну, ужас! Но не «ужас-ужас-ужас»!" Заработала она. Палкой и веревочной петлей, но работает. Ком-порты у нас на ней в одном изделие (но это уже не я писал).
Просто для инженера — интересней делать высоконадежное решение. А погоня за современностью — это для бытовухи. Легко можно нарваться на что-то типа "таймера смерти" у intel Atom C200.
Мне, как программисту, почти все равно на каком железе оно пахать будет. Лишь бы производительности хватило. Ну почти все равно — есть свои секреты, все-таки 1.6 ГГЦ в ВЧ части…
Бывал в тех краях, правда давно.
Всё работает, атвичаютут не катит.
И именно поэтому я и пишу — это всё для ленивых, кто готов применять готовое. Тем более что на самом деле — 5 минут и готово.
А кстати, где-то на гитхабе мне попадались исходники ПЛК — если найду ссылку, кину.
У меня аж тогда проскочила мысль, что ну его нафиг, эти лифты, я и по лестнице могу.
Кстати вот по вашей ссылке цитата-«Таким образом Beremiz преобразует LD, FBD, SFC или IL в код на ST, а MatIEC конвертирует ST в C. Код С компилируется на конечную платформу.» То есть выгрузить программу из контроллера без вариантов. Грустно это…
Насколько я понимаю, из Bluepill получится очень примитивный игрушечный ПЛК.
Во-первых, я не уверен, что он сможет работать в диапазоне температур от -60 до +120.
Во-вторых, ПЛК — это не только контроллер, как заметили выше, но и модули расширения. Без них говорить даже об отладке смысла нет, т.к. как минимум временные характеристики выполнения программы будут отличаться (если подставлять желаемые значения вместо получаемых с устройства, то время, затрачиваемое на опрос устройства будет равно нулю, либо потребуется дополнительно создавать ПО для моделирования всего этого и т.п.). Отлаживать же непосредственно обмен информацией с модулями расширений будет точно так же не удобно, т.к. потребуется какой-то переходник, который на практике будет иметь крайне неприятную наружность и работать будет так себе, ведь он будет изготовлен в единственном экземпляре.
Мой опыт показывает, что лучше всего просто поставить каждому разработчику по полноценному ПЛК с необходимым минимальным набором модулей расширения.
Когда речь идёт о конторе, которая занимается разработкой — да, тут применять самодельные модули себе дороже. А вот для кружка самое то — пора прощаться с ардуинами и им подобными клонами, пусть дети изучают хотя бы промышленные языки и осваивают азы отладки. Это моё мнение.
Для совсем базового обучения (особенно в случае открытия исходников описываемой в публикации прошивки) может подойти. Хотя в этом случае потребуется ограничиться периферией самого контроллера, т.к. делать систему с модулями расширений дорого. Благо, что сам контроллер имеет достаточно много различных устройств, которые можно представить в виде «виртуальных» модулей расширений.
По поводу +120 могу несколько ошибаться — точную верхнюю границу я не знаю, но на прежнем месте работы контроллеры в печке грели. И, насколько мне известно, заявляли, что ПЛК способен работать при -60. Уж с дополнительным подогревом или без — не знаю, я не по железу работал.
Между тем тот же MSP430 вполне себе переживает -60. Только один раз видел, чтобы после заморозки он вышел из строя.
Справедливости ради, отмечу, что конкретные механизмы обеспечения работоспособности при низких температурах мне не известны.
Относительно MSP430: я сам своими глазами видел, как устройство с данным контроллером работало в морозильной камере.
P.S. Очевидно же, вроде, что я не инженер, а ардуинщик.
Приятно видеть тему про промышленное программирование — довольно редкую на Хабре.
Сам работаю АСУшником, сегодня, в субботу, дали время, заливал новую редакцию программ в ПЛК, сижу, контролирую, вроде всё работает)))
В GX Developer тоже работаю изредка, есть с десяток подопечных ПЛК Митсу FX.
Вышла версия ПО посвежее — GX Works, (у вендоров можно попросить бесплатно).
Автор, с ней будет работать ваша Blue pill?
Если есть желание попробовать себя в программировании ПЛК, у Митсу есть хороший тренажер на русском. Программа несколько старовата и капризна, но интересна и полезна.
Если мало 103-го камня, то вместо него можно впаять 303-й, 373-й. (вообще список совместимых по ногам достаточно большой). Например STM32F373CCT6, Flash=256K, RAM=32K.
Сайт Mitsubishi то ещё счастье — потратил кучу времени на то чтоб найти программу, потом скачать (долго и разные варианты) потом оказалось что ни одна из программ не работает на Windows10, также как и «Программа-конфигуратор»…
Как костыль можно предложить работу под виртуалкой — но это ещё то удовольствие.
А программу, насколько я помню, можно скачать на трекерах — была почти на всех, что сейчас заблокированы.
Blue pill (синяя таблетка) STM32F103 в качестве ПЛК