Я привёл самый простой и очевидный пример на тему непригодности. В коде полно ошибок при работе со знаковыми и беззнаковыми типами данных. При работе с небольшими положительными числами всё будет хорошо, а вот с отрицательными или просто большими начнётся такая веселуха! Надо доводить до ума код, а не ставить костыли типа указанных выше. С делением на ноль костыль сканает, а вот, например, с умножением уже нет. Похожи на правду только логические команды, арифметика точно негодная. imsushka молодец, привёл код к виду, пригодному для понимания и доработки. Буду доводить код до ума. Пока не рекомендую его для практического применения. Но! Если есть люди, понимающие в SFC, то большая просьба к ним попробовать написать тестовые программы на нём и проверить их работу.
Сам прикинь: датчик 4..20мА, трансформатор тока 5А и т.д. А нужно делать пороговый контроль: давление 2..4бар, ток 300..400А. Так что для масштабирования без этих операций никак.
Этот код- НЕ_пригоден для использования. Хотя компилируется. Смотрю математику и обалдеваю от того бреда, что вижу. _ВСЯ_ арифметика должна быть переписана. Увы и ах. Не зря китайцы выложили его в свободный доступ.
Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.
тоесть весь контроль операндов на конечном пользователе
а электрики-асушники привыкли из библиотеки блок вставить, входные параметры задать и забыть, а шаг вправо шаг влево для них это веревка с мылом, а крючек уже в шкафу есть
если у тебя задача без пидов и вычисления орбиты солнца, а просто если сработал датчик вкл/выкл выход, то проблем нет
если есть вычисления, то программа чуть усложняется, за счет лишних проверок
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Вот-вот. А если датчик вышел из строя и на его выходе оказался "0"? Поэтому ПЛК и был создан в том числе и для того, чтобы взять такую рутину на себя. Там проблема даже не в том, что подвиснет. Это слишком просто и очевидно. Имеющийся код вообще не формирует никаких флагов результатов. Чуть более сложный пример: сложите два целых числа размеров 32 бита, именуемых в файлё limits.h как LONG_MAX. Ни один маркер, сигнализирующий об ошибке не поднялся. А какой результат получится, представляете? И такие вещи простым сравнением не выловить. Могу продолжать, но зачем? Я ж ведь прекрасно понимаю, что за неделю сделать приличный клон невозможно. Но делать нужно. Прошу воспринимать написанное мной не как критиканство, а как направление для будущих тестов.
Добавлено after 2 minutes 33 seconds: Re: Open source plc STM32F103RBT6 source code Mitsubishi PLCFX1
Цитата:
входные параметры задать и забыть
И это правильно, ибо: "Царь не может думать о каждом, царь должен думать о главном".
простой датчик замкнут/разомкнут - начальная/конечная позиция - намок/ненамок - светло/темно мне здесь где ЛОНГ_МАКС поставить ???????
хай ладно ацп тоже есть, значит еще простой датчик аналоговый тепература больше Х/ меньше У - задвижка повернута на Х - напружеие - ну не знаю что еще для дома/ мелкой конторы может понадобицца а здесь ?
это не для машиностроительного завода / атомной станции / контейнеровоза, да и не будут туда заморачивацца с экономией 1000 баксов это для сохо, аля ардуина, но сбоку
Ты считал из внешнего АЦП код, который тебе нужно преобразовать в реальное значение, путём масштабирования и сдвига. И как ты это сделаешь без математики? Или, например, нужно вести уставочный мониторинг какого-либо параметра, а параметры хочется менять в процессе работы по Модбас. И работать хочется с человеческими "220В", а не абстрактными 0x0ABF. Так что без математики в ПЛК никуда. Это как машина без крыши, дверей и сидений: и, вроде, ехать можно, но нафиг такая поезда нужна.
Начал было тоже китайский код до ума доводить, а тут, я смотрю, уже всё сделано. Спасибо, посмотрим. Сам давно хочу мелкий ПЛК для себя, но меня интересует только такая доводка кода, которая работает с GX Works 2, т.к. я привык к ST, хоть и ущербному, в отличие от нового стандарта с ООП. Попробую протестировать как смогу что есть и, возможно, доработать, что работает как-то не так.
П.С. Нельзя ли выложить код в какой-нить репозиторий? И подскажите обвязку для мк для этого кода, т.е. плату или проект в Proteus.
Что касается IAR'а, то я не использую его среду разработки из-за ущербности. Поэтому буду в 6.5 ваять по двум причинам: 1) я могу Eclipse использовать с этой версией, т.к. плагин для IAR ARM 6.5 там работает; 2) у меня есть ОС PowerPac, если вдруг захочу многозадачности и она туда войдёт. Возможно на последней версии тоже можно что-то такое замутить, но я не пробовал.
Я ведь не просто так прошу пока не использовать этот код. Он в процессе ежедневного изменения и пока не достиг уровня, пригодного для использования.
Если хотите сделать полезное, проверьте SFC. До этого куска пока руки не дошли, поэтому даже насколько там всё плохо, не знаем. При проверках не используйте арифметические операции, они в этой версии не полностью работают.
ST для программирования ни я, ни imsushka не используем, поэтому какие команды нужны для ST, не знаем. ИМХО, программировать ПЛК на СТ- это убивать саму идею ПЛК. Сила ПЛК в визуальных языках, ориентированных на задачи автоматизации. СТ разумно применять для поддержки нестандартных протоколов и при большом количестве вычислений. Я просто пояснил, почему поддержка СТ стоит на последнем месте.
Я пишу на ST вот так. Думается, что любой практик сразу перейдёт на ST, как только его освоит. Я уже имел дело с китайскими ПЛК, которые вполне справляются с такой задачей. Мне не хватало только протокола Mitsubishi, который у меня теперь есть. Раньше его достать было сложно. Разница с LD небольшая, на самом деле код ST просто в LD компилируется и это подсовывается ПЛК. Но это в старых версиях многих ПЛК так происходит. В настоящее время LD устарел и помечен в стандарте как не рекомендуемый для использования или его вообще оттуда выкинули, уже не помню.
Я собрал проект в IAR ARM 6.5, пришлось несколько правок сделать. Возьму его за основу и буду пробовать насколько он совместим с GX Works 2 в плане поддержки ST.
Вложения:
Комментарий к файлу: Пример кода на ST в GX Works 2 MainUnit.pdf [51.91 KiB]
Скачиваний: 487
Комментарий к файлу: IAR ARM 6.5 PLC_iararm65.7z [420.65 KiB]
Скачиваний: 498
А смысл в таком написании? Тогда уж пользуйте Паскаль, как минимум быстрей будет работать. Конечный автомат, для реализации которого как раз и создан SFC.
Цитата:
на самом деле код ST просто в LD компилируется
О как. Вы ради интереса хотя бы документацию от Мицубы почитайте, а то с таким подходом далеко не уедите.
Цитата:
В настоящее время LD устарел и помечен в стандарте как не рекомендуемый для использования или его вообще оттуда выкинули, уже не помню.
Ссылочкой, пожалуйста, подтвердите своё заявление. Думаю, на LD ещё наши внуки-автоматчики будут писать.
Цитата:
буду пробовать насколько он совместим с GX Works 2 в плане поддержки ST.
Только не забудьте подключить отладочную консоль. И ещё. Пройдись по исходнику: там часть команд бросает ошибку, а часть просто проматывает счётчик адреса без выдачи ошибки.
А смысл в таком написании? Тогда уж пользуйте Паскаль, как минимум быстрей будет работать. Конечный автомат, для реализации которого как раз и создан SFC.
Вы не напишете это как-то по-другому на графическом языке, а если напишите, то это будет уродливо. "Рисовать" работу по протоколу на графическом языке - это пытаться изобрести ST. У меня в примере идёт работа по последовательному интерфейсу с весовым контроллером.
По поводу LD я ошибся, имел в виду IL. Код ST, как и любой другой, насколько я понимаю, компилируется в IL и записывается в память контроллера. Поэтому неважно на каком языке написана оригинальная программа ПЛК, исполняться будет код IL, но это только для старых ПЛК и сред разработки типа GX Works 2. Давно не пробовал, но помню, что IDE показывает результат компиляции в виде IL, поэтому китайские подделки теоретически могут быть использованы не только со своими доморощенными средами, но и с оригинальной от Mitsubishi, не считая шифрования. Запароливание работать не будет, т.к. для этого нужно знать алгоритм и сам процесс кодирования/декодирования.
Ну и в пользу того, что в коде мк находится виртуальная IL-машина говорит тот факт, что вы можете выкачать из ПЛК IL-код любой программы. Т.е. закачиваем ST, а выкачать можем только IL. Это касается и любого другого языка для GX Works 2 и FX2N.
Я почему ошибся - выкачиваемый код обычно представляется в LD в IDE и по привычке его считал низкоуровневым. К сожалению, не многие китайские ПЛК поддерживают ST, я пробовал ПЛК Wecon. Он частично поддерживал и я даже попросил китайцев доработать, они доработали и можно было вполне сносно писать на ST, минуя их доморощенную IDE. Но потом скакнули цены и вот теперь приходится ваять ПЛК самому.
Поэтому неважно кто и как использует среду разработки.
Вы не напишете это как-то по-другому на графическом языке, а если напишите, то это будет уродливо.
Для описания грамматик языков программирования самая выразительная форма- это нормализованная Бэкуса-Наура форма, которая проста и понятна людям. Разбор грамматик удобно реализовывать в виде конечного автомата. Так получилось потому, что это графические представления, которые удобны для восприятия и реализации человеком. А тут какой-то протокол с с весовым контроллером... Ну это так, лирическое отступление.
Цитата:
К сожалению, не многие китайские ПЛК поддерживают ST
На чём строится это утверждение? Какие поддерживают? В каком объёме?
Цитата:
Он частично поддерживал
Проверял? Что поддержано, а что нет? Список необходимых команд есть?
Цитата:
я даже попросил китайцев доработать, они доработали и можно было вполне сносно писать на ST
Интересные вещи звучат. Хочется узнать, что они такого сделали, что их контроллеры стали вдруг поддерживать ST.
Я, например, не имею ни малейшего представления, какие команды нужны для поддержки языковых конструкций СТ. Как минимум, нужно написать тестовую прогу на СТ, которая задействует все (или наиболее употребительные) конструкции языка, а потом декомпилировать её и посмотреть ИЛ. Может, где в Инете и валяются такие тесты. Я бы начал с сайта проекта mathiec, может, что на сайте IEC есть. Нужен вам СТ? Вот и подготовьте данные. Может, там работы на вечер, а может на полгода. Сейчас ни у кого нет понимания этого вопроса.
Я практик и пишу как есть в реальном мире. Доморощенные китайские среды обычно только LD поддерживают. Это касается ПЛК от фирмы Wecon, их среду я выкинул на помойку сразу. Писать код на LD для обмена данными через последовательный интерфейс просто невозможно, получается длинное "спагетти". Поэтому я попробовал родную среду GX Works 2 для их клона FX2N. Я залил код в их ПЛК, но он сошёл с ума - начал перемигиваться светодиодами ввода-вывода. Было смешно, показал китайцам, они удалённо перепрошили мозги новой прошивкой. Последняя оказалась лучше и мне удалось запустить загруженный код, но с одной махинацией. Приходилось после загрузки ST проекта выкачивать его как LD, делать незначительное изменение и заливать как LD. После этого всё работало.
Я разбирал их ПЛК и видел там SMT32, но не помню какой серии.
Сейчас собираю своё окружение, чтобы допиливать выложенный тут код до кондиции. Пишу я в eclipse, т.к. IDE IAR полное убожество, но компилятор их использую конечно. Отлаживаю также в eclipse. Поскольку в Proteus вроде есть этот мк, то попробую сначала использовать виртуальный контроллер вместо реального. Точно ещё не понял подойдёт ли BluePill.
Я вроде ясно написал, что никаких команд ST поддерживать не надо. Те наборы инструкций, что находятся в ladder.c должны соответствовать IL командам. Я пока не проверял, но думаю, что так оно и есть, если это действительно совместимый ПЛК.
mathiec - кросс-транслятор, это вообще из другой оперы. Точнее говоря, он ближе к современным soft-ПЛК по идеологии, чем обсуждаемые тут. Я использовал эту утилиту для перевода ST кода в программу для AVR мк. Успешно. Т.е. я могу писать код на ST для Arduino. Но авторы Beremiz выбрали python в качестве языка для IDE, чем убили всю идею. Никто в здравом уме писать визуализацию на нём не будет. Вот и сидят год от года всё на одном месте.
Добавлено after 9 hours 41 minute 25 seconds: Re: Open source plc STM32F103RBT6 source code Mitsubishi PLCFX1 Увы, с BluePill и Proteus пока не получится, т.к. STM32F103C8 на текущий момент отсутствует в библиотеке (для Proteus 8.9). Придётся использовать реальную железку, а хотелось виртуальную обвязку сделать.
Эх, как давно это было. Какое же это всё убожество. Вот так можно писать ST в один из китайских клонов FX2N.
Что-то не наблюдаю ничего, кроме F103 серии. У меня 8.9 SP2.
Я бы посмотрел как ST заходит, а код меня разочаровал - полное отсутствие какого-то стиля оформления, жуткая мешанина. Из-за китайских иероглифов основной шрифт у меня в IAR IDE "слетает" при просмотре. Дарёному коню в зубы не смотрят, но сопровождать творение будет не очень приятно. Я бы всё нафик переписал и вообще под C++ сразу, чтобы в IDE поудобнее было.
Пока не заводил в eclipse, т.к. структура исходников какая-то избыточная. Было бы здорово отделить саму IL-машину от мк-кода, тогда логику её работы можно было бы тестировать как программу под Windows. Это же просто блоки памяти и операции над ними, таймеры, счётчики и прочее можно имитировать.
Видимо скачал старый какой-то вариант с прошлой страницы. Там ниже ещё есть, посмотрю его.
Цитата:
и ил это 1 файл, никак не привязан к мк
Мне проще отлаживать было бы как отдельную программу на C++, я могу обернуть её и программным нуль-модемом к IDE подключить. Всяко лучше любых embedder сред разработки, если получится. Главное, чтобы в железе поведение не отличалось потом.
Добавлено after 3 minutes 59 seconds: Re: Open source plc STM32F103RBT6 source code Mitsubishi PLCFX1 О, я нужную модельку нашёл, нажав на эту магическую кнопочку. Раньше этим как-то не пользовался. Интересно откуда все эти модели дополнительные.
Сейчас этот форум просматривают: HardWareMan и гости: 14
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
может сырые были.
