Комментарии 86
ПЛК от отладочной платы радикально отличает куча обвеса
и вся на практике как раз выяснятся что грамотный обвес это 90 процентов успеха
иначе порты дохнут, глюки на входах и т.п.
а что за программа внутри на сегодня это 20 % успеха
неплохо можно и с нуля на си написать
и вся на практике как раз выяснятся что грамотный обвес это 90 процентов успеха
иначе порты дохнут, глюки на входах и т.п.
а что за программа внутри на сегодня это 20 % успеха
неплохо можно и с нуля на си написать
Только знаете, хотелось бы добавить вот что — если вы напишете программу на С, то у вас отладка такой программы будет возможна только через отладчик типа STLink или JLink, и вам придётся перезапускать процессор для подключения. Тут же онлайн — отладка как раз и рассчитана на то, чтобы не прерывая процесса управления, можно было и смотреть, что происходит, и изменять значения онлайн. При этом время цикла управления практически не изменяется. Это один из очень больших плюсов программируемых логических контроллеров.
НЛО прилетело и опубликовало эту надпись здесь
Вы перед тем, как употреблять слово «глупость» подумайте. Если вы читали статью, то там описано — я прямо в среде программирования написал нужную мне логику, скомпилировал, загрузил либо частично, либо полностью, и тут же смотрю работу программы и значения переменных. И мне для этого не надо вообще ничего делать — никаких лишних телодвижений!
А вот что надо в вашем случае, чтобы точно также посмотреть онлайн программу через SWO? Это вообще не одно и то же, вообще!!!
А про привязку к программатору я и не писал — это вы выдумали вообще. А printf в наши дни — это откровенная ардуинщина и костыли.
А вот что надо в вашем случае, чтобы точно также посмотреть онлайн программу через SWO? Это вообще не одно и то же, вообще!!!
А про привязку к программатору я и не писал — это вы выдумали вообще. А printf в наши дни — это откровенная ардуинщина и костыли.
НЛО прилетело и опубликовало эту надпись здесь
Меня совсем не дядя Петя зовут — не надо тут хамить. Отладку перепробовал на STM32 почти всю — так что не надо мне писать, что делать. Я рассказываю про то, что такое промышленная система и как она работает -и даю вам возможность её опробовать. Не интересно — не читайте, я ведь никого не заставляю. Совсем никого. А минусанул за то, что надо читать то, о чём пишут.
НЛО прилетело и опубликовало эту надпись здесь
Мы читаем наверное разную классику просто!
SWO в своё время оказалось единственным средством отладки стека TCP/IP в режиме исполнения — это о чём-то говорит.
Тут промышленное программное обеспечение, которое взаимодействует с платой. А то, что оно без рюшечек — уж извините, вам шашечки или ехать всё таки.
А вот насчёт картинок — да, надо исправить, чтобы было видно полностью. Если уж очень горит — то ПКМ-Открыть в новом окне. И будет вам счастье полноценного просмотра. Но статью буду переделывать…
SWO в своё время оказалось единственным средством отладки стека TCP/IP в режиме исполнения — это о чём-то говорит.
Тут промышленное программное обеспечение, которое взаимодействует с платой. А то, что оно без рюшечек — уж извините, вам шашечки или ехать всё таки.
А вот насчёт картинок — да, надо исправить, чтобы было видно полностью. Если уж очень горит — то ПКМ-Открыть в новом окне. И будет вам счастье полноценного просмотра. Но статью буду переделывать…
Промышленный софт, промышленные языки, промышленнные технологии…
Отлично, что все это удалось сделать на дешевой платке.
У меня такое впечатление, что вы просто ни разу с промышленными ПЛК не работали.
ну хотя бы вики почитайте, про IEC 61131-3, про ladder, про SFC.
ПЛК — это совсем иной мир, идущий от релейно-контактных схем. И да, только в промышленности используются такие языки, что электрику прочесть код проще, чем программисту.
Отлично, что все это удалось сделать на дешевой платке.
У меня такое впечатление, что вы просто ни разу с промышленными ПЛК не работали.
ну хотя бы вики почитайте, про IEC 61131-3, про ladder, про SFC.
ПЛК — это совсем иной мир, идущий от релейно-контактных схем. И да, только в промышленности используются такие языки, что электрику прочесть код проще, чем программисту.
Вот кстати, про читаемость кода ПЛК. Бывает, его и электрики пишут, совсем не знакомые с понятием ООП. Это такая боль и вермишель...
Вот приведу пример отладки выкачанной программы из ПЛК. Как раз сейчас будет видно преимущество визуального языка программирования — в строке, которая выделена маркером, виден выключенный меркер М2. Если его включить, то соберётся вся логика и будет активирован М8. Для того, чтобы определить, что же не даёт включиться меркеру М8, ушло меньше нескольких секунд.
Вы, наверное, имели в виду текстовое отображение всё-таки и стиль написания «лишь бы скомпилилось»
Вы, наверное, имели в виду текстовое отображение всё-таки и стиль написания «лишь бы скомпилилось»
Внешний вид программы в режиме отладки
Нет, в графическом тоже бывает такого понаворотят… У нас программы очень сложные, их разбивают на подпрограммные блоки — функции. Например, входные параметры функции могут изменяться из сотни других функций. Иногда даже инструмент cross reference (мощный аналог find) не спасает, поскольку изменяются параметры с помощью указателей (у Siemens такое можно).
У меня проще — в программе просто раскрашивал ladder симим (0) и красным (1) цветом. Соответственно, для определения требовалось меньше секунды.
Кроме того, был написан модуль автоматической диагностики, которы по переключениям находил причину с шансом 99.9% (мы не писали часто переключаемые временные переменные, поэтому 0.1%).
Удивительно, но единственный случай, когда автоматички не согласились с диагностикой решился в пользу програмы. Там было сложное четырезхтактное срабатывани и автор кода просто не увидел, что он может сработать настолько хитрым путем.
Так что можно и 0 секунд — ladder вполне позволяет автоопределение.
Кроме того, был написан модуль автоматической диагностики, которы по переключениям находил причину с шансом 99.9% (мы не писали часто переключаемые временные переменные, поэтому 0.1%).
Удивительно, но единственный случай, когда автоматички не согласились с диагностикой решился в пользу програмы. Там было сложное четырезхтактное срабатывани и автор кода просто не увидел, что он может сработать настолько хитрым путем.
Так что можно и 0 секунд — ladder вполне позволяет автоопределение.
Ещё хуже, когда программисты лезут в электрику. А уж если автоматику делают люди с ООП головного мозга…
Дело в том, что требования качества вавтоматике, совсем иные, чем принципы ООП.
Во-первых, любой отказ датчика должен диагностироваться и не мешать работе (возможно с некторой деградацией), двойной отказ — обязан диагностироваться, по возможности с продолжением работы с деградацией. Тройной отказ — диагностировать по возможности.
Это означает, что для контроля используются дачтики из совсем других блоков. Например, самолет запрещает реверс при отсутствии раскрутки колес набегающим воздухом после старта. Где двигатели и где колеса?? :-) У вышупомянутом криз-контроле отказ дачтика оборотов колеса легко диагностируется по подаче топлива в двигатель и включению сцепления. Но… это не влезло в ООП, отсюда — и многочисленные трагедии.
Второй момент. Для надежности любой выход должен устанавливаться только в одном месте. Для той же надежности (и модифицируемости) лучше не использовать промежуточные переменные. В итоге формирование аварии — это такая большая простыня со смесью сигналов из разных подсистемю
Третий момент — хороший код автоматички способен выполняться параллельно. То есть не должен зависеть от порядка выполнения нетворков.
Автоматчику — удобнее и надежней и читаемей именно такой код. А для тех, кто с автоматикой не знаком — такой код, конечно, будет слабо читаем.
Кстати, у меян в системе был модуль упрощения нетворков. То, что выдал этот модуль — не прошло. Читаемость меньше, модитцируемость хуже. Хотя выполнялось чуть быстрее.
Дело в том, что требования качества вавтоматике, совсем иные, чем принципы ООП.
Во-первых, любой отказ датчика должен диагностироваться и не мешать работе (возможно с некторой деградацией), двойной отказ — обязан диагностироваться, по возможности с продолжением работы с деградацией. Тройной отказ — диагностировать по возможности.
Это означает, что для контроля используются дачтики из совсем других блоков. Например, самолет запрещает реверс при отсутствии раскрутки колес набегающим воздухом после старта. Где двигатели и где колеса?? :-) У вышупомянутом криз-контроле отказ дачтика оборотов колеса легко диагностируется по подаче топлива в двигатель и включению сцепления. Но… это не влезло в ООП, отсюда — и многочисленные трагедии.
Второй момент. Для надежности любой выход должен устанавливаться только в одном месте. Для той же надежности (и модифицируемости) лучше не использовать промежуточные переменные. В итоге формирование аварии — это такая большая простыня со смесью сигналов из разных подсистемю
Третий момент — хороший код автоматички способен выполняться параллельно. То есть не должен зависеть от порядка выполнения нетворков.
Автоматчику — удобнее и надежней и читаемей именно такой код. А для тех, кто с автоматикой не знаком — такой код, конечно, будет слабо читаем.
Кстати, у меян в системе был модуль упрощения нетворков. То, что выдал этот модуль — не прошло. Читаемость меньше, модитцируемость хуже. Хотя выполнялось чуть быстрее.
Хочу добавить — если в GX Developer-е написать запись в нескольких местах в один и тот же выход, то компилятор не будет ругаться на это. Но если вы запустите поиск ошибок ( меню Сервис — Поиск ошибок), то он вам покажет, что это ошибка. Хотя программа будет спокойно выполняться контроллером. Как-то так.
Так что множественная запись не запрещена, но нежелательна, ибо делает код трудночитаемым. А это время — а обычно в полях его как раз и нет. Но ещё хуже, когда двоичную логику реализуют на языке типа STL( SIEMENS) — вот тут по времени уже намного хуже, чем в визуальных вариантах.
Так что множественная запись не запрещена, но нежелательна, ибо делает код трудночитаемым. А это время — а обычно в полях его как раз и нет. Но ещё хуже, когда двоичную логику реализуют на языке типа STL( SIEMENS) — вот тут по времени уже намного хуже, чем в визуальных вариантах.
Если пишете на IL, то как вы сделаете цикл без множественной записи? А в потрохах — нет разницы, на каком языке изначально писался код. Любой код можно отобразить и как IL и как LD и как FBD.
Хотя STL — это не стандартный IL, с ним может быть чуть хуже.
двоичную логику реализуют на языке типа STL( SIEMENS)Неужели у сименса настолько слабый софт, что не позволяет отобразить STL как ladder? Быстренько глянул доку — судя по главе 1, он должен это уметь.
Хотя STL — это не стандартный IL, с ним может быть чуть хуже.
Увы — только простые конструкции спокойно можно переводить из одного отображения в другое. Например, немцы очень любят FBD и STL — но например на LAD уже не перейти в ряде случаев. Если код посмотреть — команды типа BLD 103 и выравнивание NOP-ами для FBD и LAD выглядят по разному. Но это только для сложных нетворков.
Но вот я например, расчёты предпочитаю делать на STL — потому что на LAD и FBD получается сложновато. И указатели тоже нужны — особенно, когда с массивами работаешь. Всё надо просто применять там, где это необходимо. То есть без фанатизма и предпочтений к какому-то одному языку.
Но вот я например, расчёты предпочитаю делать на STL — потому что на LAD и FBD получается сложновато. И указатели тоже нужны — особенно, когда с массивами работаешь. Всё надо просто применять там, где это необходимо. То есть без фанатизма и предпочтений к какому-то одному языку.
Но ведь можно сделать у блока входа и выхода, верно? Получится некоторая аналогия функции в классическом яп. А то делают так, что другие блоки модифицируют переменные внутри не своего блока. А еще хоть и делают функции, но изменяют их параметры из сотни мест, при этом иногда через указатели.
А вы точно на правильном языке код читаете?
У меня был подобный код. В конце скана код записывал измененных входы, выходы и временные переменные (по маске) и писал кадр в кольцевой буфер. А сервер вычитывал данные из кольцевого буфера и вел архив переключений.
На ассемблере это смотрелось нормально. Но на ladder… ну в общем я никому не советую читать это на ladder. Вычитывали эти 300 строк 5 человек (и каждый расписался за приемку). Потом поставили на стан — и заработало. Ответная часть на сервере была из 10 тысяч строк. :-)
А с ФБ у вас скорее всего сказывается недостаток функциональности самого ФБ. По уму, такое дело надо лечить написанием своего, объемлющего ФБ, но я понимаю, почему проще динамически править параметры.
Первое, что приходит на ум — изменение постоянной времени у пид-регулятора. Есть быстрый режим и медленный, надо переключаться между ними, а функциональности самого пид-регулятора не хватает.
У меня был подобный код. В конце скана код записывал измененных входы, выходы и временные переменные (по маске) и писал кадр в кольцевой буфер. А сервер вычитывал данные из кольцевого буфера и вел архив переключений.
На ассемблере это смотрелось нормально. Но на ladder… ну в общем я никому не советую читать это на ladder. Вычитывали эти 300 строк 5 человек (и каждый расписался за приемку). Потом поставили на стан — и заработало. Ответная часть на сервере была из 10 тысяч строк. :-)
А с ФБ у вас скорее всего сказывается недостаток функциональности самого ФБ. По уму, такое дело надо лечить написанием своего, объемлющего ФБ, но я понимаю, почему проще динамически править параметры.
Первое, что приходит на ум — изменение постоянной времени у пид-регулятора. Есть быстрый режим и медленный, надо переключаться между ними, а функциональности самого пид-регулятора не хватает.
Я обычно на LAD предпочитаю читать код. Просто очень часто код, написанный на STL и прочих ассемблерах, в графический вид не переводится, я и не знал, что такое возможно, если с нуля писать на STL.
А по поводу ПИД регуляторов разговор особый. Их вообще надо ставить в отдельный блок с фиксированным временем вызова. Я тут придумал одну фишку, чтобы уменьшить боль инженерам, которые будут этот код читать. Надо всего лишь сделать в основной программе отдельный блок для управления параметрами ПИД регулятора. И менять параметры только в нём.
А меня удивляет, что такое невозможно. Старый OMRONовский софт вообще все хранил в IL.
Надо всего лишь сделать в основной программе отдельный блок для управления параметрами ПИД регулятора. И менять параметры только в нём.Мне не нравится. Я бы сделал ФБ — «ПИД-регулятор + изменение настроек». И использовал бы его. То есть переключал и регулировал бы настройки входами.
Для ПИД регуляторов хорошо так делать, если логика переключения параметров небольшая. Иначе мы просто бесполезно будем занимать критичное время выполнения процессора (читайте это как код в прерывании, коим оно и является).
Время ровно то же будет. Какая разница — выполнить 2 ФБ (настройку и ПИД-регулятор) или один, но с вложенным ФБ ПИД-регулятора? По памяти это может быть хуже.
Для ускорения — ФБ может менять параметры по отдельному сигналу «сменить параметры». А пока этого сигнала нет — не менять.
А зачем вам вообще работа по прерываниям? Почему не в общем скане?
Для ускорения — ФБ может менять параметры по отдельному сигналу «сменить параметры». А пока этого сигнала нет — не менять.
А зачем вам вообще работа по прерываниям? Почему не в общем скане?
Строгое известное время между вызовами блока ПИД необходимо для правильной работы И и Д звена. Они выполнены по математическим численным методам приращения. Это же дискретная логика, тут нет никакого аналогового сигнала интегрирования и тем более дифференцирования. Отсчеты выполняются дискретно. И чем меньше время между отсчетами, тем точнее. Его стараются делать как можно меньше и из-за этого бывают казусы. У меня как-то было, что основной цикл программы не всегда успевал выполняться, всё время происходила непрерывная обработка прерывания.
Гм, вы работали с ПЛК? У меня такое впечатление, что нет.
Дело несколько не в отладке. Вы что думаете, отладил и забыл?
Представьте себе стан. Остановка стана — 40 тысяч долларов (рулон стали), улетевший в брак. А на стане — куча датчиков, которые иногда отказывают.
При аварии или предаварии оперативно или меняется программа для обхода отказвшего датчика или ставится блокировка (показания датчика принудительно приводятся к 0 или 1). А уж потом, раз в месяц, стан встает на ремонт и все отказавшее — меняется.
Времена отказа считаются в минутах(!!!) в год. Например у автоматчиков несколько лет подряд было 0 минут простоя в год по их вине. Это при 8 тысячах входов и 2 тысячах выходов, контролируемых дюжиной ПЛК
А теперь попробуйте воспроизвести это на Си с любым отладчиком. Отладчик с возможностью загрузки отдельной измененной процедуры (нетворка в терминологии Ladder) найдете?
P.S. Это АНГА, цех ПХЛ, Северсталь.
P.P.S А время на реальную отладку нового кода на живом стане — 2 часа в месяц. Это когда стан выходит из ремонта, но ещё не вошел в режим.
Дело несколько не в отладке. Вы что думаете, отладил и забыл?
Представьте себе стан. Остановка стана — 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. Ну в общем считайте, что ПЛК это такая ПЛИС — и вам сразу все понятней будет. Для ПЛИС-то хоть хоть как раз писали?
НЛО прилетело и опубликовало эту надпись здесь
«Современное» — это ругательство. Это так, для бытовухи. Для надежных применений используется то, что реально работает 10-20 лет. С реальными цифрами наработки на отказ. А ПЛИС у нас коммутирует сигналы ком-портов, так что надежная, мелкая (CPLD XC2C64A), зато — при нужде заменяется российской ПЛИС с 5ой приемкой.
Понятно, написать не смогли. А учебники «для электриков» читайте сами, мои интересы в другой области, лет 35 уже как от радиогубительства отошел.
P.S. ну а то, что ваши вымыслы про С++ не смогли подтвердить реализацией — это типично.
Понятно, написать не смогли. А учебники «для электриков» читайте сами, мои интересы в другой области, лет 35 уже как от радиогубительства отошел.
P.S. ну а то, что ваши вымыслы про С++ не смогли подтвердить реализацией — это типично.
НЛО прилетело и опубликовало эту надпись здесь
… хуже, сейчас ещё и 9ой приемкой проект делается.
Это высокоточная спутниковая навигация. С точностью 5 миллиметров СКО. Так что с одной стороны — GPS, ГЛОНАСС, GALILEO, а с другой — атомные ледоколы, автовождение тракторов и грузовиков, шлюзы, военные беспилотники, перевозимые на двух грузовиках…
Если вы на самом деле инженер — то сумеете с 5ой приемкой сделать. А если так, обычный малолетка, то сидите в мире бытовухи и не суйтесь туда, где нужна надежность.
Для обычных применений мы тоже на STM32H7 делаем. Но мы умеем выживать и там, где реально нужно 20 лет работы без сбоев.
Это высокоточная спутниковая навигация. С точностью 5 миллиметров СКО. Так что с одной стороны — GPS, ГЛОНАСС, GALILEO, а с другой — атомные ледоколы, автовождение тракторов и грузовиков, шлюзы, военные беспилотники, перевозимые на двух грузовиках…
Если вы на самом деле инженер — то сумеете с 5ой приемкой сделать. А если так, обычный малолетка, то сидите в мире бытовухи и не суйтесь туда, где нужна надежность.
Для обычных применений мы тоже на STM32H7 делаем. Но мы умеем выживать и там, где реально нужно 20 лет работы без сбоев.
НЛО прилетело и опубликовало эту надпись здесь
Такое впечатление, что вы не сталкивались с западными промышленными решениями. Вы думаете они новее нашей 5ой приемки?
Аирбасы, боинги… Знаете какой там GPS-приемник? 12 каналов, характеристики такие, что любая бытовуха за пояс заткнет. Элементная база — ну где-то года 1990ого, если не раньше. Это вот то, что летает. Пару лет назад начали поставлять новые. С характеристиками примерно 2000 года. Зато — не ломается. Промышленное решение. Судя по корпусу — оно и крушение самолета переживет, если пожар недолгим будет.
Ещё пример. 2002 год, та самая Северсталь.закупаем для ПЛК сетевую плату. Бытовые 100мегабитные — стоят 10 долларов, а эта — тысячу. протокол — Ethernet II, то есть 2 мегабита. Зато — не ломается.
У вас стопроцентный входной контроль деталей есть? А реальная наработка на отказ по тем же деталям известна? Или только теоретическая, в камерах ускоренного старения?
Просто для инженера — интересней делать высоконадежное решение. А погоня за современностью — это для бытовухи. Легко можно нарваться на что-то типа "таймера смерти" у intel Atom C200.
Мне, как программисту, почти все равно на каком железе оно пахать будет. Лишь бы производительности хватило. Ну почти все равно — есть свои секреты, все-таки 1.6 ГГЦ в ВЧ части…
Аирбасы, боинги… Знаете какой там GPS-приемник? 12 каналов, характеристики такие, что любая бытовуха за пояс заткнет. Элементная база — ну где-то года 1990ого, если не раньше. Это вот то, что летает. Пару лет назад начали поставлять новые. С характеристиками примерно 2000 года. Зато — не ломается. Промышленное решение. Судя по корпусу — оно и крушение самолета переживет, если пожар недолгим будет.
Ещё пример. 2002 год, та самая Северсталь.закупаем для ПЛК сетевую плату. Бытовые 100мегабитные — стоят 10 долларов, а эта — тысячу. протокол — Ethernet II, то есть 2 мегабита. Зато — не ломается.
Сейчас занимаюсь индастриал решениями (силовые преобразователи с гарантией 15+ летСколько проживут ваши преобразователи в цехе, если даже в бытовке за месяц прямо из воздуха выпадает миллиметр металлической окалины?
У вас стопроцентный входной контроль деталей есть? А реальная наработка на отказ по тем же деталям известна? Или только теоретическая, в камерах ускоренного старения?
Доводилось работать с клоном альтеры из Воронежа, тихий ужас…"Ну, да! Ну, ужас! Но не «ужас-ужас-ужас»!" Заработала она. Палкой и веревочной петлей, но работает. Ком-порты у нас на ней в одном изделие (но это уже не я писал).
Просто для инженера — интересней делать высоконадежное решение. А погоня за современностью — это для бытовухи. Легко можно нарваться на что-то типа "таймера смерти" у intel Atom C200.
Мне, как программисту, почти все равно на каком железе оно пахать будет. Лишь бы производительности хватило. Ну почти все равно — есть свои секреты, все-таки 1.6 ГГЦ в ВЧ части…
Северсталь -Балаково? Мне сразу вспомнился проект водоподготовки, который написан был на SCL- PASCAL-е подобном языке.
Бывал в тех краях, правда давно.
Бывал в тех краях, правда давно.
Нет, Череповец. Вот краткое описание проекта.
Совершенно верно! Именно поэтому я и показал плату, которую использую в качестве отладочной. На самом деле этот пост для тех, кому лень или нет желания писать такую реализацию на С — берёшь готовое и вуаля.
Делать свой ПЛК на МК, используя чью-то прошивку без открытых исходников — извините, такое себе.
Всё работает, атвичаютут не катит.
Я ведь только предлагаю готовую прошивку — у вас есть свобода выбора, всегда можете выбрать любой другой вариант. Мне кажется, что важно, чтобы были хотя бы какие-то варианты — хотя бы такие. А так конечно — для серьёзной системы вообще хорошим тоном будет все своё иметь, и операционку тоже.
И именно поэтому я и пишу — это всё для ленивых, кто готов применять готовое. Тем более что на самом деле — 5 минут и готово.
А кстати, где-то на гитхабе мне попадались исходники ПЛК — если найду ссылку, кину.
И именно поэтому я и пишу — это всё для ленивых, кто готов применять готовое. Тем более что на самом деле — 5 минут и готово.
А кстати, где-то на гитхабе мне попадались исходники ПЛК — если найду ссылку, кину.
НЛО прилетело и опубликовало эту надпись здесь
Ох, вспомнил лифт на ардуине и снова стало плохо :(
У меня аж тогда проскочила мысль, что ну его нафиг, эти лифты, я и по лестнице могу.
У меня аж тогда проскочила мысль, что ну его нафиг, эти лифты, я и по лестнице могу.
НЛО прилетело и опубликовало эту надпись здесь
Я тоже отношусь к ардуино не просто с предубеждением — имею опыт демонтажа поделок на оных платках. И люди реально имели проблемы из-за таких автоматизаторов. А менял на контроллеры, которые делает контора — и весьма успешно, ни одного отказа за больше чем 2 года. Дело в том, что этот бинарник — это отладочная версия, на ней откатываем функции на старом железе. Но рабочее железо уже давно другое -для малых версий STM32F3, серии постарше уже F4 или H7 с поддержкой Ethernet и прочими плюшками. Всякую рассыпуху датчиковую — на STM32F0. Непонятна реакция только ваша — вроде я ничего не продаю, просто даю возможность попробовать интересное решение. Что не так?
А если серьёзно — лифты до сих пор клепают на КР1816ВЕ35 или КР1816ВЕ39. Так что не удивляйтесь, что работает немного не так, как бы хотелось. Завод изготовитель называть не буду из этических соображений.
А в чём там основные проблемы были, в схемотехнике или программировании? Логика лифта на иерархический (с учётом сигнала пожар) конечный автомат хорошо ложится, тут сложно напортить. Или там keep-alive сигналов не было?
Если интересно — вот, можете почитать.
Ссылка на исходник -https://github.com/KeyMove/STM32-PLC-FX1N
Beremiz неплох, когда речь идёт о получении грантов) А вот хотя бы один реально работающий проект с онлайн отладкой, загрузкой и выгрузкой мне что-то не попадался, который работает хотя бы 10 минут без отваливаний. Если у вас есть ссылка — поделитесь, посмотреть будет интересно. Или я напишу под него интерпретатор даже, если проект будет стоящий.
Кстати вот по вашей ссылке цитата-«Таким образом Beremiz преобразует LD, FBD, SFC или IL в код на ST, а MatIEC конвертирует ST в C. Код С компилируется на конечную платформу.» То есть выгрузить программу из контроллера без вариантов. Грустно это…
Кстати вот по вашей ссылке цитата-«Таким образом Beremiz преобразует LD, FBD, SFC или IL в код на ST, а MatIEC конвертирует ST в C. Код С компилируется на конечную платформу.» То есть выгрузить программу из контроллера без вариантов. Грустно это…
Здравствуйте!
Насколько я понимаю, из Bluepill получится очень примитивный игрушечный ПЛК.
Во-первых, я не уверен, что он сможет работать в диапазоне температур от -60 до +120.
Во-вторых, ПЛК — это не только контроллер, как заметили выше, но и модули расширения. Без них говорить даже об отладке смысла нет, т.к. как минимум временные характеристики выполнения программы будут отличаться (если подставлять желаемые значения вместо получаемых с устройства, то время, затрачиваемое на опрос устройства будет равно нулю, либо потребуется дополнительно создавать ПО для моделирования всего этого и т.п.). Отлаживать же непосредственно обмен информацией с модулями расширений будет точно так же не удобно, т.к. потребуется какой-то переходник, который на практике будет иметь крайне неприятную наружность и работать будет так себе, ведь он будет изготовлен в единственном экземпляре.
Мой опыт показывает, что лучше всего просто поставить каждому разработчику по полноценному ПЛК с необходимым минимальным набором модулей расширения.
Насколько я понимаю, из Bluepill получится очень примитивный игрушечный ПЛК.
Во-первых, я не уверен, что он сможет работать в диапазоне температур от -60 до +120.
Во-вторых, ПЛК — это не только контроллер, как заметили выше, но и модули расширения. Без них говорить даже об отладке смысла нет, т.к. как минимум временные характеристики выполнения программы будут отличаться (если подставлять желаемые значения вместо получаемых с устройства, то время, затрачиваемое на опрос устройства будет равно нулю, либо потребуется дополнительно создавать ПО для моделирования всего этого и т.п.). Отлаживать же непосредственно обмен информацией с модулями расширений будет точно так же не удобно, т.к. потребуется какой-то переходник, который на практике будет иметь крайне неприятную наружность и работать будет так себе, ведь он будет изготовлен в единственном экземпляре.
Мой опыт показывает, что лучше всего просто поставить каждому разработчику по полноценному ПЛК с необходимым минимальным набором модулей расширения.
Основная идея публикации была в том, чтобы дать людям возможность использовать завалявшиеся платы с пользой. Но меня жутко удивляет реакция — почему столько негатива, что не так? Тем более что я старался раскрыть большую и интересную тему — плюс была бы возможность попробовать свои силы и набраться опыта на копеечных платах, которые тем более что уже есть. Конечно, такие платы не для использования на объектах — это я всё описал в статье.
Когда речь идёт о конторе, которая занимается разработкой — да, тут применять самодельные модули себе дороже. А вот для кружка самое то — пора прощаться с ардуинами и им подобными клонами, пусть дети изучают хотя бы промышленные языки и осваивают азы отладки. Это моё мнение.
Когда речь идёт о конторе, которая занимается разработкой — да, тут применять самодельные модули себе дороже. А вот для кружка самое то — пора прощаться с ардуинами и им подобными клонами, пусть дети изучают хотя бы промышленные языки и осваивают азы отладки. Это моё мнение.
Извините меня, пожалуйста, за негатив. Упоминание использования в обучении я пропустил. Вероятно, потому что данная ремарка размещена в заключении статьи.
Для совсем базового обучения (особенно в случае открытия исходников описываемой в публикации прошивки) может подойти. Хотя в этом случае потребуется ограничиться периферией самого контроллера, т.к. делать систему с модулями расширений дорого. Благо, что сам контроллер имеет достаточно много различных устройств, которые можно представить в виде «виртуальных» модулей расширений.
Для совсем базового обучения (особенно в случае открытия исходников описываемой в публикации прошивки) может подойти. Хотя в этом случае потребуется ограничиться периферией самого контроллера, т.к. делать систему с модулями расширений дорого. Благо, что сам контроллер имеет достаточно много различных устройств, которые можно представить в виде «виртуальных» модулей расширений.
НЛО прилетело и опубликовало эту надпись здесь
Здравствуйте!
По поводу +120 могу несколько ошибаться — точную верхнюю границу я не знаю, но на прежнем месте работы контроллеры в печке грели. И, насколько мне известно, заявляли, что ПЛК способен работать при -60. Уж с дополнительным подогревом или без — не знаю, я не по железу работал.
Между тем тот же MSP430 вполне себе переживает -60. Только один раз видел, чтобы после заморозки он вышел из строя.
Справедливости ради, отмечу, что конкретные механизмы обеспечения работоспособности при низких температурах мне не известны.
По поводу +120 могу несколько ошибаться — точную верхнюю границу я не знаю, но на прежнем месте работы контроллеры в печке грели. И, насколько мне известно, заявляли, что ПЛК способен работать при -60. Уж с дополнительным подогревом или без — не знаю, я не по железу работал.
Между тем тот же MSP430 вполне себе переживает -60. Только один раз видел, чтобы после заморозки он вышел из строя.
Справедливости ради, отмечу, что конкретные механизмы обеспечения работоспособности при низких температурах мне не известны.
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за Ваш ответ и опускание меня до менеджеров и ардуинщиков. Большое спасибо. Вы — про, я — ничтожество. Признаю свою ошибку.
НЛО прилетело и опубликовало эту надпись здесь
К сожалению, не могу уже изменить комментарий и исправить на +60, что соответствует номинальному диапазону рабочих температур. Если же просмотреть руководство по эксплуатации, то можно увидеть, что имеется два возможных диапазона рабочих температур: -40..+60 и расширенный -61..+60. Всё это, разумеется, исключительно маркетинговый ход. Может быть я дурак, раз верю, что в документах пишут то, что есть.
Относительно MSP430: я сам своими глазами видел, как устройство с данным контроллером работало в морозильной камере.
P.S. Очевидно же, вроде, что я не инженер, а ардуинщик.
Относительно MSP430: я сам своими глазами видел, как устройство с данным контроллером работало в морозильной камере.
P.S. Очевидно же, вроде, что я не инженер, а ардуинщик.
А какой смысл затирать маркировку микросхем? Даже самого STM32 и кварца? Вы же в статьё всё равно написали, что это за микросхемы.
Что на счёт IO-Link?
IO-Link на данный момент не поддерживается, хотя можно и добавить. Я так понимаю, физика немного специфична. По данным википедии, длина линии составляет максимум 20 метров — но я совсем не уверен, что эта информация корректна. Была идея насчёт AS-i интерфейса — но его физика дорогая и периферия совсем не дешёвая. Для дома такую не купить — поэтому отложили реализацию.
Физики никакой специфичной нет — обычный UART по одному проводу, нужно только немного обвязки для согласования уровней(а можно взять готовое решение у того же ST), а вот сам протокол… почитайте как-нибудь на досуге спецификации: www.io-link.com
Приветствую, коллеги!
Приятно видеть тему про промышленное программирование — довольно редкую на Хабре.
Сам работаю АСУшником, сегодня, в субботу, дали время, заливал новую редакцию программ в ПЛК, сижу, контролирую, вроде всё работает)))
В GX Developer тоже работаю изредка, есть с десяток подопечных ПЛК Митсу FX.
Вышла версия ПО посвежее — GX Works, (у вендоров можно попросить бесплатно).
Автор, с ней будет работать ваша Blue pill?
Если есть желание попробовать себя в программировании ПЛК, у Митсу есть хороший тренажер на русском. Программа несколько старовата и капризна, но интересна и полезна.
Приятно видеть тему про промышленное программирование — довольно редкую на Хабре.
Сам работаю АСУшником, сегодня, в субботу, дали время, заливал новую редакцию программ в ПЛК, сижу, контролирую, вроде всё работает)))
В GX Developer тоже работаю изредка, есть с десяток подопечных ПЛК Митсу FX.
Вышла версия ПО посвежее — GX Works, (у вендоров можно попросить бесплатно).
Автор, с ней будет работать ваша Blue pill?
Если есть желание попробовать себя в программировании ПЛК, у Митсу есть хороший тренажер на русском. Программа несколько старовата и капризна, но интересна и полезна.
Да, я тестировал работу с версией GX Works 2. Единственно что — в данной версии реализация функций PWM, EXTR и DEZCP немного отличается от канонической. Да- кстати, в этой версии есть поддержка Profibus DP slave, совсем забыл. Надо будет немного переписать утилиту конфигурации, чтобы можно было активировать этот режим. Мне кажется, будет любопытно попробовать работу в таком режиме.
Ну, насчет «хилости» «голубой таблетки» вы это зря. Камень (STM32F103C8T6) — пром исполнения, и спокойно переживает -40 +85 С (проверялось лично). Кварцы там — да, послабее, -20 +70 С. Слабый стабилизатор, всего 100 мА. Но исправляя это, я для себя «нарисовал» аналог "голубой таблетки". Кварцы такого же типоразмера, но -40 +85 С, Стабилизатор 800 мА. Проект с открытыми исходниками, можете повторять.
Если мало 103-го камня, то вместо него можно впаять 303-й, 373-й. (вообще список совместимых по ногам достаточно большой). Например STM32F373CCT6, Flash=256K, RAM=32K.
Если мало 103-го камня, то вместо него можно впаять 303-й, 373-й. (вообще список совместимых по ногам достаточно большой). Например STM32F373CCT6, Flash=256K, RAM=32K.
Как раз 303 и использую. Причина банальна — не хватило каналов DMA под все хотелки.
И ещё, по насчет энергонезависимой памяти: Если это уставки, и не часто меняются, то никто не запрещает использовать ПЗУ микроконтроллера для хранения чего-либо. Например для этого отводим верхний килобайт-два.
Да — насчёт применения флеш памяти для хранения… В данном проекте можно сохранять комментарии к элементам программы в контроллере — то есть при выгрузке из памяти вы получите такой точно проект, каким его написал программист до вас. Русский поддерживается. Ещё поддерживается так называемая память регистров — выделяются блоки по 500 регистров, где вы можете хранить свои константы. Увы — пришлось эту особенность реализовать так, что сохранение происходит только при записи константы из GX Developer FX. И конечно же, расходуется память программ — из 8000 шагов откусываем куски или для комментариев, или для файловых регистров. Зато если программа небольшая — то получается очень даже удобно.
Да — вот на какой плате используется 303 проц. Тут уже и сохранение всех переменных в батарейной памяти(чип 23к256 по SPI), до 20 mbps последовательный изолированный порт( второй — до 500 kpbs), блок питания уже получше качеством. На основе этого дизайна недавно тестировали мост Profibus DP slave — Modbus RTU master. Конечно, это всё партизанщина — но что поделать, даже такой проект позволяет оставаться в тонусе.
Фото платы другого образца
Пытался сделать ПЛК из синей таблетки за 5 минут в результате убил весь вечер так и не добившись результата… Дальше прошивки синей таблетки дело не пошло.
Сайт Mitsubishi то ещё счастье — потратил кучу времени на то чтоб найти программу, потом скачать (долго и разные варианты) потом оказалось что ни одна из программ не работает на Windows10, также как и «Программа-конфигуратор»…
Сайт Mitsubishi то ещё счастье — потратил кучу времени на то чтоб найти программу, потом скачать (долго и разные варианты) потом оказалось что ни одна из программ не работает на Windows10, также как и «Программа-конфигуратор»…
А вот тут давайте поподробнее… Дело в том, что под 10-кой я как раз и не тестировал — только под 7 x64 и под XP x32. Сейчас посмотрим, что можно будет сделать по крайней мере с конфигуратором.
Как костыль можно предложить работу под виртуалкой — но это ещё то удовольствие.
А программу, насколько я помню, можно скачать на трекерах — была почти на всех, что сейчас заблокированы.
Как костыль можно предложить работу под виртуалкой — но это ещё то удовольствие.
А программу, насколько я помню, можно скачать на трекерах — была почти на всех, что сейчас заблокированы.
Итак коллеги — провёл тесты под Windows 10. Всё отлично работает на самом деле. Система х64. Перед началом установки GX Developer надо установить доп.пакет из папки GX_developer\EnvMEL. Также установил драйвера по ссылке для СОМ порта.
Снимок экрана работающей программы
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Blue pill (синяя таблетка) STM32F103 в качестве ПЛК