|
|
Соцопрос: языки МЭК 61131-3. |
|
Сори, под классическими я имел в виду контроллеры программириумые софтом фирмы производителя контроллера. Поэтому и добавил уточнение "закрытые". Я верю, что в Кодесис все так как вы говорите и что ST для Кодесис более оптимален. Я думаю, что в Кодесис это в некотором роде результат многоплатформености. Но вы сами указали, что даже в Кодесис IL можно получить, пусть и копеечный, выигрыш в быстродействии и это связано с "железом". Так почему бы вам не допустить, что в следствии особенностей архитектуры ПЛК программа на LD (а этот язык очень близок IL) будет выполняться быстрее, чем написанная на ST? |
||||
 |
||||
Очень даже возможно. ST – это самый сложный язык в плане реализации транслятора, а создание компиляторов – это вообще одна из самых сложных областей программирования. Классных компиляторов Паскаля и Си – по пальцам пересчитать, а ST их родной брат. FBD и LD реализовать в сто раз проще. Если за разработку берется не специализированная софтверная компания, а изготовитель контроллера, то вероятнее всего такой кривоватый результат и будет. |
||||
|
||||
|
Кривоватый результат - это когда разница по быстродействию в разы. В других случаях это скорее всего особенности связки железо+софт. |
||||
|
||||
|
Главное - компилятор (транслятор), или сказать полнее - среда выдающая исполняемый код. Набор букв - это одно. А поэма - уже совсем другое. Надо еще уметь писать ... К слову, хочу отметить великолепную в целом среду - CoDeSys. Такого эффективного кода у подобных систем я не встречал. И в ней уже все равно, какие изобразительные средства выбрать для конкретного фрагмента. Части проекта можно писать на разных языках : модули на ST и CFC, общую связку - на SFC. Потом легко соединить воедино, и в целом - мощный эффективный код. С уважением, SAN |
||||
|
||||
|
Я как-то не верю в бесплатные пирожки, жизнь научила, поэтому думаю что одинаковое быстродействие программы на LD и ST результат универсальности относительно железа. Проще говоря, думаю что LD слегка притормаживает. У производителей контроллеров, которые сами пишут среду программирования проблема универсальности не стоит, за то стоит задача выжать по максимому из железа. Уповать на то, что люди, которые пишут компиляторы уже лет 20-25 под свои контроллеры, делают это плохо - наивно. |
||||
|
||||
|
Вы наверняка слышали расхожий анекдот про ".. кривые тонкие чулки ..". Так вот это про LD, ST и прочие вещи, которые не туда надели ... С уважением, SAN |
||||
|
||||
|
Что может быть в аппаратуре такого, что программа: --[a]----(c)-- вдруг станет работать быстрее чем c := a AND b; ?
Не стоит? Они что до сих пор используют процессор 8080 и выпускают одну модель ПЛК? Возможно они все же думают о том, чтобы не переделывать все ПО при каждой замене процессора на новый? Согласен, что универсальность легко может давать тормоза, но опять же если она плохо сделана. Если же для каждой процессорной платформы используется свой специализированный компилятор и оптимизированная система исполнения, то такого эффекта не будет. Понятно, что МЭК программа на ПЛК с процессором Infineon С167 будет работать медленнее, чем с ARM9 или Renesas SH4. Однако в каждом случае из процессора выжимается все, что он умеет. В принципе, любую систему исполнения, написанную для 32 бит процессора можно засунуть и в 8051, и она будет работать, будет мучительно вычислять длинные косвенные адреса, эмулировать математику с плавающей запятой повышенной точности и др. Можно, если с головой не дружить совсем.
Точно компиляторы? 25 лет назад не было идеи писать компиляторы для ПЛК. Контроллеры в обязательном порядке поддерживали программирование с автономных пультов. В самом контроллере сидел некий интерпретатор команд, вводимых с пульта. Потом появились АРМ программиста. Функциональность пульта перенесли в компьютер и добавили примитивные трансляторы и сервис. Примерно в таком духе они и развиваются, стараясь обеспечивать совместимость, вопреки оптимальности. Переделать все с нуля и объявить о несовместимости своих ПЛК со своими же ПЛК не реально. А вот включить в дополнение к своему программному инструменту поддержку современного МЭК комплекса высшего класса – нет проблем. Пускай пользователь решает использовать ему то, к чему привык или брать новый инструмент, когда возникают более сложные задачи, которые нельзя решить привычными средствами. |
||||
|
Igor Petrov
|
||||
|
||||
А вы думаете, что программа для контроллера этим и ограничевается?
А не кажется ли вам что вы передергиваете? Одно дело распределенный переход во времени от одного ядра ПЛК к другому и совсем другое, когда это приходится делать здесь и сейчас.
Согласен, ошибся в пылу. Точнее сказать программы для программирования контроллеров с ПК. Сказать точно как обрабатывает "закрытый" контроллер программу созданную пользователем на ПК нельзя. Смысл, однако, остается - опыт разработчиков. Говорить о кривости рук разработчиков продукта за которые сотни тысяч инженеров голосую ни один год кошельком - НАИВНО. Проблема в том, что вы переносите концепцию Кодесси или подобных систем на "закрытые" контроллеры. А оснований для этого нет ни каких. Да, и вообще пора завязывать с этим бессмысленным спором. Напомню, что в начале я просто подставил под сомнение объективность сравнения быстродействия ПЛК на основе тестовых программ написанных на ST и SFC. |
||||
|
||||
|
Промышленная электроника традиционно ориентирована на железо, и его быстродействие. В этом она обладает "здоровым" консерватизмом. Рассуждая о развитии промэлектроники, нужно вовремя остановиться, чтобы не занесло в область совсем иных современных технологий - сдесь очень легко заскочить не туда, особенно под всеобщим хвалебным напором новых веяний. С уважением, SAN |
||||
|
||||
|
Самое сложное, что может быть в IL – это вызов экземпляра функционального блока. Здесь также никакой разницы с ST нет. Так что может быть в контроллере такого, что чтобы LD работал быстрее чем ST? Я не из желания поспорить спрашиваю, мне действительно это очень хотелось бы узнать.
Не очень это понял? Допустим, сделал я нормальную среду программирования для своего ПЛК, все хорошо. Пользователей обучили, документацию написали, отладили все. Год, два, три… Затем аппаратчики применили новое поколение процессоров (поскольку пора – конкуренты смеются), а среда моя подходит к этому ядру как к корове седло, и что? Приспосабливаю, как могу, переделываю, латаю, достигаю универсальности. Обычное дело, когда изготовитель контроллера сам делает систему программирования. Профессиональная (универсальная) МЭК среда: есть >200 OEM компаний, постоянно разрабатывающих новые железки c этим софтом. Есть специализированная фирма, которая все это поддерживает. Я (программист) не успеваю следить за новостями: поддержана FPGA такая и такая, новый DSP и т.д. Уже я хожу за аппаратчиками и долблю их: ребята – вы тормоза, у меня ПО готово, давайте, уделаем всех конкурентов... Почему изготовители ПЛК активно нахваливают FBD подобные штуки? Если честно, то тому, что для их реализации нужен очень простой транслятор – ассемблер. Такой опыт у них есть. Но с нормальным компилятором ST разница тут как между изготовлением швертбота и элитной яхты.
Есть. Поскольку эта концепция закрытости загибается на глазах. Изготовители ПЛК ставят на свои контроллеры профессиональные МЭК системы, наряду с поддержкой собственных систем (кроме Сименса, почти все уже это сделали или делают сейчас). Это не единичное явление, это тенденция.
Дык спор не пустой. Концепции этих тестов открыты для обсуждения. (См. сюда) Если Вы или я видим в них ошибку, то обязаны срочно сообщить членам рабочей группы и внести свои предложения. Их нужно активно обсуждать и делать быстро, иначе получим плохой стандарт. |
||||
|
||||
Ответить 
|
Страница <1 34567 9> |
| Переход на форум | Права доступа на форуме  Вы не можете публиковать новые темы в этом форуме Вы не можете отвечать на сообщения в этом форуме Вы не можете удалять Ваши сообщения на этом форуме Вы не можете редактировать Ваши сообщения на этом форуме Вы не можете создавать голосования на этом форуме Вы не можете выражать своё мнение в голосованиях на этом форуме |
