Тем не менее сейчас простейшие контроллерные ЦПУ уже многоядерные, а таргетом КодеСиса или МастерСкады или Изаграфа может быть любой Линух. Так что проблема есть и реальная, наработки по многоядерности я видел только у КодеСиса.
Теория доказывает, что на практике с параллельными вычислениями у нас совсем плохо. И практическое моделирование практической же схемы самого простого триггера в этом убеждает. Замечу, самого простого. И не надо моделировать что-то большее, если в малом уже ошибки. Надеюсь, эта "теоретическая мысль" Вам понятна?
Мне тут непонятно, откуда вдруг тут (в статье или триггере) появились параллельные вычисления?
Я не против единства теории и практики, но к сожалению, это обычно разные люди =)
Софт для программирования времен Windows 3.1 и возможностей - мало (недавно вышел новый, но не для всех серий, лишь AS200/300)
Коммуникационные возможности и возможности расширения - а это именно то, что важно для среднего класса - ниже всех похвал, даже порты связи неизолированные.
Сейчас есть китайские клоны S7-200, Mitsubishi FX, и сонма контроллеров под CodeSys 3. Это все гораздо лучший выбор из-за нормального софта, производительности и расширяемости.
Был тут уже один теоретик с подобным наукообразным стилем общения, все про Драконов задвигал.
Вот только бесконечно далек он был от практики, на что ему резонно пеняли.
RS-триггер в ПЛК - это именно то, что я и написал. И Вы кстати, тоже, только уродливо. В схемотехнике триггеров больше и они отличаются.
Если не умеете писать на релейке, рекомендую использовать SFC. Это чистые графы автоматов, как Вам нравится. Поддерживаются всеми адекватными контроллерами.
Насколько помню, компиляторы тех времен, не справлялись с автовекторизацией. И даже были казусы, когда мелкие изменения приводили к кратному замедлению.
Вообще автоматом является управляемый объект, и его состояния (наливается, загружается, перемешивается...), а что там в программе происходит - дело пятое и уже тем более уровень программных инструкций не интересен.
Прекрасный пример, как не надо писать на релейке. Да и заодно убожества Дельты.
Инструкции MOV в релейке быть не должно (разве что не биты а word'ы и прочие данные передать), достаточно койлов, уж тем более, что здесь есть даже их edge-варианты.
Для непривычных, аналогом такого применения MOVв процедурных языках будет if (x=true) y = false
Так же на рис.4 наблюдается нарушения правила единого выхода, что в разных контроллерах - неопределенное поведение (например выход будет моргать по ходу исполнения логики в Allen-Bradley, а в Сименсе не будет)
Видимо нет, потому что дальше продолжили метания UWP, Avalonia, MAUI, WinUI, ... или может Веб =)
Это 32 шага.
Именно.
Я немного забыл - в Стандарте в части 5 предусмотрена синхронизация только через ФБ.
Нет шаговых реле и команд дельтовских STL, SET, RET. См начало треда.
Кстати, этот стандарт уже нашел преемника - IEC 61499
0: MOV(0, dwState) =)
Тем не менее сейчас простейшие контроллерные ЦПУ уже многоядерные, а таргетом КодеСиса или МастерСкады или Изаграфа может быть любой Линух. Так что проблема есть и реальная, наработки по многоядерности я видел только у КодеСиса.
Собственно, я и без спец.инструкций так пишу =)
В данном случае, это эрзатц-SFC от Дельты, в Стандарте этого нет.
Например? Я о реальной многозадачности, а не о блоках прерываний, потому что при их выполнении остальные стоят.
А можно ссылочку, а то гугл не знает.
А объекты в разных контроллерах разные называются похоже.
Наверное Вы работаете на очень вредном химическом производстве, надеюсь молоко хоть дают =)
В МЭК-61131 нет параллельного исполнения пользовательской программы (ну почти, а с учетом числа реализаций, так вообще можно забыть)
Мне тут непонятно, откуда вдруг тут (в статье или триггере) появились параллельные вычисления?
Я не против единства теории и практики, но к сожалению, это обычно разные люди =)
Ну я так думаю, что контроллер на некорректное обращение не обидится =)
Но так то Вы правы, лопата и лук и стрелы тоже на своем месте прекрасно работают.
Но какие эпитеты Вы предпочли бы услышать для контроллера, сравнимого (даже сильно слабее), с контроллером S5-115U выпуска 1989г ?
Какие прекрасно сохранившиеся останки!
Какая винтажная архитектура!
Это прямое наследие древних мастеров!
Я привел примеры нормальных контроллеров того же класса.
Младшим их сериям DVP - до среднего класса ПЛК как до Луны пешком. Я сказал, что они убогие (упомянутые в статье) почему
Они древние
Медленные - 25MHz. Статья про разборку
Обкусанная память программ - 12к шагов =)
Софт для программирования времен Windows 3.1 и возможностей - мало (недавно вышел новый, но не для всех серий, лишь AS200/300)
Коммуникационные возможности и возможности расширения - а это именно то, что важно для среднего класса - ниже всех похвал, даже порты связи неизолированные.
Сейчас есть китайские клоны S7-200, Mitsubishi FX, и сонма контроллеров под CodeSys 3. Это все гораздо лучший выбор из-за нормального софта, производительности и расширяемости.
Был тут уже один теоретик с подобным наукообразным стилем общения, все про Драконов задвигал.
Вот только бесконечно далек он был от практики, на что ему резонно пеняли.
RS-триггер в ПЛК - это именно то, что я и написал. И Вы кстати, тоже, только уродливо. В схемотехнике триггеров больше и они отличаются.
Если не умеете писать на релейке, рекомендую использовать SFC. Это чистые графы автоматов, как Вам нравится. Поддерживаются всеми адекватными контроллерами.
Без проблем, 1я же картинка.
https://studref.com/354825/stroitelstvo/tipovye_uzly_shemy_upravleniya_elektroprivodov_asinhronnymi_dvigatelyami
Когда твой проект выкапывают даже из вебархива =)
Насколько помню, компиляторы тех времен, не справлялись с автовекторизацией. И даже были казусы, когда мелкие изменения приводили к кратному замедлению.
Все там видно на рис.4 - бардак.
Типичный RS-триггер из любого учебника по электротехнике - схема управления двигателем
Для алгоритмов посложнее добавить количество m_StateXXX (ес-но с хранением состояния)
Вообще автоматом является управляемый объект, и его состояния (наливается, загружается, перемешивается...), а что там в программе происходит - дело пятое и уже тем более уровень программных инструкций не интересен.
Прекрасный пример, как не надо писать на релейке. Да и заодно убожества Дельты.
Инструкции MOV в релейке быть не должно (разве что не биты а word'ы и прочие данные передать), достаточно койлов, уж тем более, что здесь есть даже их edge-варианты.
Для непривычных, аналогом такого применения MOVв процедурных языках будет if (x=true) y = false
Так же на рис.4 наблюдается нарушения правила единого выхода, что в разных контроллерах - неопределенное поведение (например выход будет моргать по ходу исполнения логики в Allen-Bradley, а в Сименсе не будет)