Таймеры CoDeSys

Смысл в том, чтобы именовать уже существующие переменные, а также биты произвольных переменных, не меняя уже существующей структуры данных, которая к примеру разбросана по разным модулям или библиотекам. Типичный случай -  когда разные участники проекта договорились о неком общем интерфейсе данных, изменить который впоследствии весьма сложно. Да и не нужно, если есть простой механизм псевдонимов и макросов. При этом внутри отдельной части проекта данные можно группировать и именовать произвольно - ведь они не имеют физической привязки, а лишь имена.

С уважением, SAN.

Да - Aliases, к которым многие так привыкли. Первоначально переменные объявляются в исходном проекте, который вручается заказчику, а там по месту назначаются желаемые имена, и всё складно ! Почему в этом нужно усматривть источник каких-то ошибок ?! Позвольте, при желании можно всё сломать. Например авторы языка C, я полагаю, никак не виноваты, что в программах написанных на нем совершено уже миллиарды ошибок !
Но поскольку CoDeSys не оснащена Aliases-ами, то при отсутствии самого предмета обсуждения, оное можно и завершить.

А вот причем здесь ООП, если это объекты верхнего уровня, тогда-как Aliases - средства низшего уровня ? Они сосуществуют никак не пересекаясь друг-с-другом ( тот-же перенавороченный C++ с .NET-ом).

Я не противник а сторонник CoDeSys, и даже расхваливаю её. Критические замечания - как раз говорят о заинтересованности в использовании этой системы ( не интересующий предмет не обсуждался бы ). А эффективность исполняемого кода CoDeSys - пока самая высокая из встречавшихся МЭК, даже если сравнивать со старыми "ручными" ассемблернми системами.

Что касается структуры интерфейса данных, то наверное будут попытки сформировать две основные концепции, в соответствии с "типом" заказчиков. Одни, которые радушно встретили среду "нового поколения", и охотно принимают предложенную систему обозначений и именований, позволяя удобно оформить проект в виде закрытого законченного (почти) продукта. Иные, приверженцы "старой школы", желают получить почти полностью открытый проект, собираются доделывать всё сами, но при этом не согласны с системой обозначений и вообще со всякой там ООП ...
Чтож, будем работать ...

При случае постараюсь ознакомиться с рекомендованным трактатом Гради Буча по ООП. Будучи не знакомым с таковым, осмелюсь предположить, что означенный фолеант наверное академического толка. Да есть академическое, последовательное знание, которое как караван - медленно но неотвратимо продвигается. Никто не может замедлить или ускорить его ход. Есть прикладные науки, как "собаки" лающие на тот "караван" (никому не в обиду). А как зачастую могучая, стройная теория бывает далека до своего прикладного воплощения.

С уважением, SAN.

Ну это понятно - перечисенные средства являются разными способами использования того что есть. Одни постоянно используютя на практике, особенно разнотипный доступ к одной области памяти, другие реже, а какие и вовсе не применяются. В определенных случаях эти разные способы повышают удобство работы с переменными, но не создают новых средств языка (те же Aliases).

Отношения между разработчиками и заказчиками не так прсты как "продовец-покупатель". И вопрос здесь вовсе не в перекладывании ответственности. Сказать, что мы сделали свою часть работы а остальное мол "ваши проблемы" - такой красивый жест не к месту. Отдел потеряет заказчика, а те найдут подходящего разработчика, или вовсе приобретут готовую систему, что зачастую и делается. Сейчас уже вовсю надвигаются системы подобные CoDeSys, да еще и в комплекте с "железом". Есть к примеру FATEK - полный комплект контроллера с заказными модулями, среда разработки аналогичная CoDeSys - с графическими редакторами, потребителям нравится большой набор готовых функций, связь по Ethernet, Online отладка загрузка программ и все прочие дела. И вполне недорого ! Так-что сделав ставку на CoDeSys, пребывать в спокойствии - не придется.

Реальее и разумнее поступить по другому.  В конкретном случае, некий "Отдел" внедряет системы автоматизации, непосредственным запуском которых занимаются "Службы промэлектроники". Отдел разрабатывает аппаратную часть - контроллер, и к нему системное программное обеспечение, промэлектронщики пишут свою часть ПО, связанную с конкретным оборудованием. В части создания ПО - оба участника находятся в равных ролях. Условное разделение ПО на системную и прикладную части отражает естественный порядок вещей : есть постоянная часть - ядро, которое почти не меняется, и переменная часть, которую гораздо ближе знают программисты-заказчики. Не смотря на условное разделение, и те и другие являются СО-РАЗРАБОТЧИКАМИ общего проекта, и работают то в одной и той-же среде CoDeSys. Так что, улаживать вопросы - это в общих интересах.
А то, что следует выработать некую общую систему объектов, отработанный интерфейс - тут полностью все согласны. Тогда и меньше будет споров, и заказчики свободнее смогут обращаться с переменными, не опасаясь сделать что-то не так.

Очень заинтересовала возможность превнести в Среду Программирования новые возможности или механизмы с помощью добавления ключевых слов (!) Понятно, что для этого надо все хорошо обдумать, систематизировать, взвесить, чтобы не  вводить новое средство на каждый "чих", да и чтобы нововведения не конфликтовали с существующим языком. Хотя может оказаться, что новый механизм может потребовать изменения старого, и поглотить его создав новое качественное средство. Вобщем, это обширная тема, и если есть реальная возможность "конструировать язык" то хотелось бы это обсудить.

С уважением, SAN.

Хотелось бы увидет что-то вроде сводного списка фирм выпускающих контроллеры под CoDeSys, с краткими техническими данными - частота процессора, объем памяти, разрядность, и главное - уровень цен.

В данное время подходящим вариантом представляется монолитный чип  BECK - он и используется как основа для разработки контроллеров. В нем удобно собрано все вместе : стоит не дорого, имеет уже вшитое ПО, и продается с готовой лицензией. Есть у BECK-а технические и программные недостатки, так-что хотелось бы расширить свой кругозор по рынку чипов с ПО поддерживающем CoDeSys. Однако информация очень разрознена, изобилие пустой требухи - разобраться трудно.

А собственно как выглядит участие в Конференции ? Можно ли, к примеру послать подготовленный материал в адрес какого-либо учреждения, как этот материал должен быть оформлен и т.п.

С уважением, SAN.