ALIASES (о необходимости которых ... говорили ... ), да еще и UNION (в основном для внутренних данных) - великолепно !
ALIASES - это прорыв, дающий возможность однонаправленного продвижения проекта, обратные звпросы заказчиков и потери времени должны сократиться. Технически, Алиасы не превносят ничего нового - ведь для МЭК-данных механизм разнотипного доступа к области памяти уже существует - AT%, и логическая целостность среды никак не затрагивается. Зато пользовательские преимущества - налицо. Конечный программист, в каждый момент времени будет работать с небольшой группой переменных, с собственными понятными именами, а не извлекать их из общего обширного интерфейса, где в два счета можно запутаться в однообразных нумерованных названиях. Отсюда резко падает вероятность ошибок. Да оно и подтверждается многократной практикой.
Еще можно сказать о, якобы, сложности среды CoDeSys. Она не сложнее других, общеизвестных - C++ Builder , AutoCAD , да те-же CorelDraw , Photoshop ... и многое др. Никто не заставляет использовать все сразу. Возможности имеются, и ждут своего часа, придет время - они пригодятся. Дело совсем в другом - в том, чтобы когда действительно понадобится та или иная функция, от нее было бы получено то, что ожидалось, чтобы она оправдала свое назначение.
То, что CoDeSys выходит за рамки IEC - очень хорошо, IEC - не ориентир. В любой отрасли знаний наступает критическая масса, когда уже не надо стремиться уместить её в рамки - а надо расширять сами рамки.
Ну а теперь по делу. Было бы хорошо организовать полноценную связь CoDeSys c C++. Зачем нужен сам C++ - вопрос отдельный, допустим, что нужен. В данное время эта возможность далека от желаемой. Слегка обозначено взаимодействие с функциями C++ через "внешние" псевдобиблиотеки, да и то с большими ограничениями, с каким-то странным выравниванием функций по байтам (!), что можно сделать только на Ассемблере, невозможность использования общей области данных и т.д. Конечно, тут не все так просто - CoDeSys и Си , в определенном смысле разнородные системы, особенно по части распределения данных - свободных (куча) и фиксированных.
То же касается полной подднржки ActiveX элементов в HMI визуализации.
Но все это, уже длинный разговор.
В CoDeSys радует эффективность исполняемого кода. В новых появляющихся системах больше внимания уделяется внешней раскраске, компиляция кода - на втором плане. Это нехорошие поползновения, ведь к некачественному коду особенно чуствительны "легкие" контроллеры, типа ADAM , WAGO и подобные.
С уважением, SAN
Первоначально опубликовано sanwork
...Ну а теперь по делу. Было бы хорошо организовать полноценную связь CoDeSys c C++. Зачем нужен сам C++ - вопрос отдельный, допустим, что нужен...
А мне вот дом на Канарах нужен. Зачем нужен - вопрос отдельный, допустим, что нужен ... sanwork, а зачем? Напишите. Может оно нам тоже нужно?
Полноценная связь CoDeSys c C++ приведет не только к написанию новых библиотек и т.д., но и возникновению множества ошибок. А как известно исправляя одну ошибку, мы совершаем еще две На мой взгляд, лучше это оставить специалистам создающим CoDeSys, высказывая им свои конкретные пожелания.
CoDeSys поддерживает много разных аппаратных платформ. Для них используются разные компиляторы Си с совершенно различной структурой объектных файлов. Поэтому сделать красивую универсально стыковку с внешними биб-ками не получается. Они поддержаны для всех аппаратных платформ, но в каждом случае есть своя специфика. Реально они используются OEM для интеграции CoDeSys со своими know how. Глобально наша цель сделать CoDeSys так, чтобы никаких внешних инструментов не возникало желания использовать вообще.
Первоначально опубликовано Mixer
Полноценная связь CoDeSys c C++ приведет не только к написанию новых библиотек и т.д., но и возникновению множества ошибок...
Так и есть. Поэтому расширяем МЭК ООП, а не цепляем к нему внешние инструменты.
Тут надо пояснить. CoDeSys так-и-так стоит на C++. Не считая .NET FX, транслятор построен на самом, что ни наесть Си. Си-шная программная структура видна невооруженным взглядом, только замаскирована под STEP7 - усеченный Паскаль-подобный диалект с графическими LD, CFC и другими редакторами.
Так что речь идет не о добавлении в среду чего-то нового, а вовсе наоборот - о воссоединении языка, у которого много чего сократили и сделали правила построже. Отсюда, отпадает вопрос - зачем в CoDeSys - C++.
Эта тема простирается дальше. Сейчас накопилось уже много разных сред программирования, и каждая для чего-то хороша. Нет универсального инструмента на все и про все. Мир как-раз хорош своим разнообразием, а не попытками натянуть все на одну мерку. Для "железа" хороши ASM и C, для WEB-а - Perl, для Медии - Jawa, и т.д.с.д.
Так вот, следующая ступень в развитии информационных технологий - интеграция разных платформ между собой, использование преимуществ каждой из них. Таковые попытки конечно уже есть - .NET Framework, C# и пр. Нельзя сказать что они прямо-таки вызывают восторг. Для промышленных систем требуется интеграция со своими особенностями, чтобы программные компоненты не утратили своей силы и эффективности. Кстати, в CoDeSys кое-что реализовано - например, WEB-визуализация. Этакая смесь Си, Жавы, ИксэМэла. И вобщем-то, неплохо. Каждый делает свое дело, и нисколько не снижает скорости исполняющего кода. Здесь уже возникает проблема некого стандартного взаимодействия между платформами. но никак не ".. зачем нужен Си .."
С уважением, SAN
Первоначально опубликовано _IP_
ok. добавил про форум
Ok. Тогда здесь вас мучить буду дальше. Есть вот что:
Почему не зависимо от состояния b_temp, X2 всегда равен X1.
Первоначально опубликовано Mixer
Почему не зависимо от состояния b_temp, X2 всегда равен X1.
любопятства ради, проверил. у меня все нормально. а подробней можно как это происходит?
Допустим b_temp=FALSE, X1=10. Тут все ясно X2 тоже будет 10.
Теперь делаем b_temp=TRUE, X1=X2=10. Вводим вручную X2=20, подтверждаем.
... и хлоп, X2=X1=10.
Проверял несколько раз. Это не глюк в конце рабочей недели это точно.
После слов, господина Petrova, засомневался. Проверил. Заработала.
Пока писал сообщение еще раз проверил - не работает. Что за чертовщина?
Все дело в том, что блок-схема не отражает реальную электрическую схему. За наглядным изображением кроется обман зрения. На самом деле, правильно будет представить блок-схему в виде текста, где строчки расположены последовательно, и выполняются друг за другом.
Тогда все встает на свои места. Функциональные блоки разбросанные на экране - не что иное как фрагменты текста, и выполняются они в порядке нумерования блоков. Внутри самих блоков, входы так-же не однозначны - какие-то обрабатываются раньше, другие позже, и результат, разумеется, разный. Напишите на выходе SEL-ектора не X2 а X1 и все изменится.
Преобразуйте разные варианты CFC в IL , и сами все увидите.
Чтобы лучше понять об чем речь - небольшая задачка. Как вы думаете за сколько тактов установится истинное состояние вот этой схемы ?
За один, за два ? ... Нет, и не за три, а за пять ! Блок-схема - всего-лишь графическое изображение текста, так-сказать, экранизация. Реальная же электрическая схема мгновенно реагирует на изменения в любом месте.
На эту удочку попадался и я, когда пытался изобразить сложные триггеры, и вместо ожидаемого
Вы не можете публиковать новые темы в этом форуме Вы не можете отвечать на сообщения в этом форуме Вы не можете удалять Ваши сообщения на этом форуме Вы не можете редактировать Ваши сообщения на этом форуме Вы не можете создавать голосования на этом форуме Вы не можете выражать своё мнение в голосованиях на этом форуме
На мой взгляд, лучше это оставить специалистам создающим CoDeSys, высказывая им свои конкретные пожелания.
и опять без форума
Кстати вчера мы открыли официальный сайт 3S на русском языке. См. 