|
|
Соцопрос: языки МЭК 61131-3. |
|
Уф.
Не знаю, поскольку не знаю особенностей построения ядра контроллеров в которых этот эффект был обнаружен. Во всяком случае, для понимания, прочрамы при помощи которых производились сравнения были достаточно объемными и достаточно сложными.
Я не знаю как устроено ядро закрытого ПЛК и какие процессоры (или группы процессоров) там используются. Думаю что и вы этого не знаете. Я знаю лишь то, что ядро контроллера создается в расчете на 10-15 лет производства. Оно может мигрировать из контроллеров верхнего уровня в контроллеры нижнего уровня. В процессе жизни появляются версии, но они не меняют радикально производительности, а лишь увеличивают функциональность. Только не надо заявлять, что это тупик - это требование рынка.
Улыбнулся. Почему-то я эти заявления воспринимаю исключительно как маркетинговый ход. Что-то я не замечаю как митсовский (единственный) процессорный модуль (Q-серия) предназначенный для программирования в C++ и на который может быть установлен Codesys, вытесняет другие модули. Более чаще он используется как вторичный процессор в специализированных системах. А теперь может Вы подскажите какое соотношение у проданных модулей C++ vs Codesys? |
|||
 |
|||
|
Интересно было бы четко локализовать конструкции, которые работают медленно. Тогда это были бы очень ценные результаты, которые помогли бы разработчикам в совершенствовании этой среды программирования...
Абсолютно верно! Радикально поменять не получается: чуть-чуть улучшили, чуть-чуть расширили. Постепенно дошли до упора, когда пора переделывать все с корней, думать о стандартизации и универсальности. То, что в будущем лет инструменты программирования ПЛК будут стандартизироваться и изготовителям контроллеров не придется их самим делать – это просто прогноз. Контроллеры будут гораздо более совместимы. Пользователь сможет легко заменять один на другой, без полной переделки прикладного ПО. Он не будет привязан к поставщикам, которые поставляют модули по 3 месяца, повышают цены, поскольку являются монополистами и т.п. Это цель стандартизации МЭК, медленно, но верно к этому идет. Какова альтернатива? Изготовители будут продолжать делать программно несовместимые контроллеры и пытаться за счет закрытости удерживать заказчиков?
 Еще один маленький примерчик, подтверждающий тенденцию. Даже Митсубиши (!!!), имеющая свою нормальную МЭК систему + неслабые силы для разработки ПО самостоятельно, выпустила контроллер с профессиональной системой МЭК программирования! Причем речь идет о новой высокопроизводительной серии контроллеров. Очевидно, дураки там сидят, которые не анализируют тенденции…
|
|||
|
|||
Да, верно замечено ! Некий теоретический предел эффективности исполняемого кода примерно достигнут. И тут надо уже стремиться не улучшать, ... а как-бы не ухудшить ! А испортить очень легко, особенно когда вовсю расползаются современные технологии программирования, под тяжестью которых еле ворочаются вычислительные системы. Тут главное - не перестараться , и не перекинуть эти технологии на пром-электронику. 2. Лично я за то, чтобы устройства автоматизации программировались на специализированных языках, лучшим образом отражающих особенности этой области. МЭК-языки собственно таковыми и являются ! Но кроме основных языков никак не обойтись без вспомогательных служебных средств, учитывающие особенности конкретной аппаратной системы. Так образуется полнценная среда разработки. С уважением, SAN |
|||
|
|||
Как правило интуитивно понятного интерфейса. Абстракция языков программирования от железа(а она наблюдается с раннего детства компьютеров) требует создания интуитивно понятного интерфейса. Ведь дело не только в том будет ли реализовано поддержка ООП (кстати эта весчь в полнее может усложнить отладку приложения) или какого размера будет квадратики с логикой, а в том насколько удобно будет разрабатывать свои программы конечному пользователю. |
|||
|
С уважением!
|
|||
|
|||
|
Вообще реально ли этими средствами наделить МЭК языки, либо обязательно нужно иметь поддержку Си и ассемблера? Что есть в Си, чего не хватает в МЭК? |
|||
|
|||
|
А в Си есть тоже самое, что есть например в Web-дизайне, или в скриптах SCADA-визуализаций - то-есть всё то, чего нет в МЭК языках - лучшим образом делать работу в своей области, а не конкурировать ! Сейчас настало время интеграции разных информационных технологий между собой. Вопрос, какой язык лучше - на свалку прошлого ! Высокое быстродействие аппаратных средств надо гармонично соединять с мощью изобразительных средств визуализации, и баз данных высокого уровня. Не противопоставлять, а строить изящьные интерфейсы межуровнего обмена - вот будущее. И прекратить наконец споры : зачем нужен СИ, Ассемблер. А зачем нужны Perl, Jawa ... С уважением, SAN |
|||
|
|||
Наделять надо не языки МЭК а среду разработки. |
|||
|
С уважением!
|
|||
|
|||
|
YES ! С уважением, SAN |
|||
|
|||
Как это? Можно по подробнее. Может быть не хорошо одну единственную среду наделять, надо неким образом вогнать это в стандарт, дабы была совместимость? |
|||
|
|||
|
Стандартизировать среды ? Вроде как-бы, большая среда является вполне самодостаточной, и не нуждается в каккой-то стандартизации. Среда разработки сродни операционной системе, а разве есть стандарты на операционные системы ? Каждая уникальна в своем роде, и сама является самодостаточным источником. К тому-же, на выходе остается только конечный продукт, который выработала среда, и какими средствами он был там сделан - уже не важно, все сливается в один исполняемый код. С уважением, SAN |
|||
|
|||
Ответить 
|
Страница <1 45678 9> |
| Переход на форум | Права доступа на форуме  Вы не можете публиковать новые темы в этом форуме Вы не можете отвечать на сообщения в этом форуме Вы не можете удалять Ваши сообщения на этом форуме Вы не можете редактировать Ваши сообщения на этом форуме Вы не можете создавать голосования на этом форуме Вы не можете выражать своё мнение в голосованиях на этом форуме |
Кстати, сейчас идет работа над новой редакцией стандарта МЭК 61131-3. Уже много интересных предложений (например, объектно-ориентированное программирование). Часть из них уже обкатывается в профессиональных МЭК системах. Давайте примем участие в этой работе. Чего не хватает в существующих реализациях? Что плохо, не удобно? Что хотелось бы изменить?