Средство для программирования контроллера: Си или МЭК 61131?

Да. А а цифровое устройство любой сложности можно создать используя только элементы 2И-НЕ. :-) Но я спрашивал не об этом. Просто Вы говорили что IL выглядит как ассемблер, а "для некоторых моделей ПЛК фирмы Siemens является языком Ассемблера". Я и спрашивал, для какой конкретно аппаратной платформы (для какого микроконтроллера) IL является ассемблером. Если не знаете так и скажите.

У меня есть подозрение, что такого микроконтроллера не существует. Такой набор команд мог быть разве что у микропрограммных контроллеров конца 60х - начала 70х. Получается что ИДИОТИЗМ продолжается более 30 лет и ИДИОТЫ засели не только в крупнейших корпорациях, но и в национаьлных комитетах стран членов МЭК. 

А Sun - так это вообще сборище идиотов. Пытаются решить проблемы переносимости практически с помощью некого универсального ассемблера - байт-кода Java. :-)

С Уважением,

Сергей Сорокин

 

 

Первоначально опубликовано Владимир Е. Зюбин Почему маловато? Может многовато? Как известно, любой алгоритм можно описать посредством двух операторов DEC и JZ (декремент и переход по нулю). Вот это по настоящему простой язык... Понять бы еще, кому он нужен... :-) Серьезно: среди большинства специалистов в области ПЛК IL ассоциируется с Сименсом, и только с Сименсом, что и отражено в статье... А у каких других ассемблеров, кроме сименовского, есть родственные связи с IL, Вам лучше подскажет доктор Q. Первоначально опубликовано Sergey Sorokin Первоначально опубликовано Владимир Е. Зюбин Добиваться межплатформенной переносимости с помощью ассемблера - ИДИОТИЗМ вдвойне. Т.к. 1. ассемблер по определению отражает архитектурные особенности вычислительной платформы (если разговор идет о "железе" и переносимости с одной "железки" на другую). ... Владимир, а Вы не вспомните к архитектуре какого конкретно микропроцессора относится IL? Я тут посмотрел последний драфт стандарта 61131-3 и в списке инструкций IL нашел всего 20 операторов. Мне показалось маловато. Даже для старенького микроконтроллера 8048 я насчитал в его ассемблере 96 команд. Может IL еще на ламповых контроллерах работал? :-) С Уважением Сергей Сорокин

Владимир Е. Зюбин Если кратко - то транслятор пришлось писать из-за семантики и прагматики. Некоторые, действительно, макросы пишут, например, в "Авроре" Шалыто и Ко...

Надо ли это понимать так, что вводимые новшества настолько просты для реализации, что их можно  вводить даже в виде макросов? Не говоря уж о библиотеках? 

или Любченко, вот, тоже  секретные dll-ки создает... но это такая рутина, такая ненадега...

Из-за чего "ненадега"? Вы хотите сказать, что Ваш самопальный транслятор с "похожего-на-С" языка СПАРМ - более надежен, чем существующие С трансляторы?

а насчет Wiki, я там даже определения транслятора не
нашел...

Я уже говорил Вам, напоминаю: современное понимание терминов таково, что компилятор и транслятор являются синонимами.

Первоначально опубликовано Доктор Q   ... Я уже говорил Вам, напоминаю: современное понимание терминов таково, что компилятор и транслятор являются синонимами.

Это конечно интересная тема - терминология в Computer Sience. Но я думаю рядовой пользователь о ней редко задумывается.

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

С Уважением,

Сергей Срокин

 

Первоначально опубликовано Максим Ананских Первоначально опубликовано Дмитрий Теркель И я про то же. Нет других возможностей при использовании агрегатов. А те, что есть, заставляют руками писать программы преобразования, как Вы справедливо заметили. Которые ничего не делают, но писать их надо. Собственно, этого и хочется избежать. У Вас есть какие-то предложения по этому поводу?

Собственно, мое исходное предложение по поводу "агрегатных" или "множественных" связей и было таким предложением. Пользователь сам создает определенный ТИП СВЯЗИ, соединяющий определенные ТИПЫ БЛОКОВ. Затем он может протянуть одну единственную агрегатную связь (это как жгут проводов, если хотите), содержащую некоторое множество элементарных. Тогда агрегация самих данных в структуры или массивы ДЛЯ ЭТОЙ ЦЕЛИ будет не нужна.

Первоначально опубликовано Максим Ананских Первоначально опубликовано Дмитрий Теркель Представьте себе диаграмму из двух блоков, у каждого один вход и один выход. Оба блока расположены на диаграмме строго один под другим. Выход одного замкнут на вход другого и наоборот (этакая восьмерка). Стандарт ВООБЩЕ НЕ ОПРЕДЕЛЯЕТ, в каком порядке блоки будут выполняться, а значит, не определяет, какая из двух связей прямая, а какая обратная. Теперь сдвигаем нижний блок на миллиметр влево. Он будет выполнен первым. А на миллиметр вправо - наоборот. Здорово! Семантика языка зависит от точности движения рисовальщика! (только по "grid" не стоит говорить, мы же стандарт обсуждаем :) Ну, начнем с того, что большинство пакетов программирования просто не дадут так разместить блоки.

А что в этом незаконного? Вполне корректная с точки зрения стандарта конструкция. Если я не cмогу, скажем, на Microsoft Visual C++ реализовать какую-либо законную конструкцию языка С, я им это сообщу как баг компилятора, а они мне пообещают его исправить :)

Первоначально опубликовано Максим Ананских Далее, читаем текст стандарта: It shall be possible for the user to define the order of execution of the elements in an explicit loop, for instance by selection of feedback variables to form an implicit loop as shown in figure 23b). То есть, как раз в стандарте-то написано, что этот порядок должен определяться пользователем.

Не совсем точно. Настоятельно рекомендуется, чтобы пользователю была предоставлена ТАКАЯ ВОЗМОЖНОСТЬ.
Он может ею не воспользоваться - имеет право.

Первоначально опубликовано Максим Ананских Хотя бы с помощью создания вспомогательной переменной. То же, о чем Вы говорите - это недостаток реализации этого механизма в рамках конкретной реализации, и не более того. Первоначально опубликовано Дмитрий Теркель Далее, можно ввести третий вид связей - "неважно каких", то есть когда неважно, прямая она или обратная. ПО таким связям диаграмма может быть разрезана на части и распределена по разным задачам и даже узлам. Таким образом, небольшое добавление выразительных возможностей приведет к способности представлять и распределенные алгоритмы. А с принципом "слева направо" действительно далеко не уедешь... Принцип "слева направо" - это тоже не более чем фантазия. В стандарте говорится следующее: No element of a network shall be evaluated until the states of all of its inputs have been evaluated. А вот выходы-то находятся справа, а входы слева.

"...изловить и повесить. ... - Здесь не сказано повесить!... - Не всякое слово в строку пишется!"
(А.С.Пушкин "Борис Годунов")

"Implicit feedback paths can also be created by using connectors that link the output parameters from blocks on the ***RIGHT*** of the network to inputs of preceeding blocks."
(R.W.Lewis/ Programming industrial control systems using iec 1131-3).

Итак, мы с Льюисом оказались в приятной компании фантазеров. ТО есть на самом деле никаких "лево-право" в стандарте нет, и evaluation rules не придают никакого значения расположению графических элементов на диаграмме. За исключением того, что при изображении блока на диаграмме у него на левой стороне квадратика входы, а на правой - выходы. А сами квадратики мы можем перемещать как хотим, и смысл от этого не меняется. Этого бы очень хотелось. Даже более того, формально Вы правы, про справа-налево явно ничего не говориться. Но..

A feedback path is said to exist in a network when the output of a function or function block is used as the input to a function or function
block which _PRECEDES_ it in the network; the associated variable is called a feedback variable.

Интересно, что такое "precedes"? Имеются ввиду "evaluation rules", которые в случае с обратными связями в чистом виде не работают, то есть, будучи применены буквально, вообще делают невозможным вычисление диаграммы с обратными связями? Вряд ли. Или все же старое доброе слева-направо?

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

Далее, предположим, сделано так, как на рисунке
23a (explicit loop) Как мы тогда отличим feedback-переменную от просто промежуточной переменной? Feedback-переменная находится правее блока-приемника? А как еще? Я не понимаю, как еще. Значит, все-таки ПРАВЕЕ!
     
Ну а в целом Вы правы, все не так уж сумрачно. Стандарт действительно настоятельно рекомендует (It shall be possible for the user), как Вы совершенно справедливо заметили, дать юзеру возможность явно указывать обратные связи. И рекомендует несколько вариантов такого указания. По крайней мере один из них (если не оба) неявно основан на расположении элементов диаграммы на листе :). Но самое главное, он не запрещает это делать каким-либо другим образом. Чем, по моему мнению, и надо воспользоваться. Правда, про совместимость и переносимость лучше не вспоминать.. но стандарту это действительно не противоречит.

Первоначально опубликовано Максим Ананских Но все-таки, поясните, пожалуйста, мысль о "неважно-каких" связях. Быть может, это действительно интересное решение, до которого пока еще никто не додумался? Мне, действительно, очень интересно...

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

1. Любой алгоритм можно программировать не то, что
макросами или библиотеками, но и прямо на ассемблере...
как в МЭК 61131-3 предлагается.. :-)

От безысходности много чего можно сделать и сложность/простота тут не при чем... :-)))

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

3. Насчет wiki: Вы бы им подсказали статью о трансляторах все же тиснуть... :-) Честно признаться,
wiki производит впечатление очень слабого толкового словаря, полного наивной и противоречивой отсебятины...
Хотя, опять повторюсь, даже не очень хорошие толковые словари читать полезно...

Первоначально опубликовано Доктор Q <SPAN class=bold>Владимир Е. Зюбин </SPAN>Если кратко - то транслятор пришлось писать из-за семантики и прагматики. Некоторые, действительно, макросы пишут, например, в "Авроре" Шалыто и Ко... Надо ли это понимать так, что вводимые новшества настолько просты для реализации, что их можно  вводить даже в виде макросов? Не говоря уж о библиотеках?  или Любченко, вот, тоже  секретные dll-ки создает... но это такая рутина, такая ненадега... Из-за чего "ненадега"? Вы хотите сказать, что Ваш самопальный транслятор с "похожего-на-С" языка СПАРМ - более надежен, чем существующие С трансляторы? а насчет Wiki, я там даже определения транслятора не нашел... Я уже говорил Вам, напоминаю: современное понимание терминов таково, что компилятор и транслятор являются синонимами.