Проект CoDeSys в виде текстовых файлов?

[Игорь Петров]

Особого ума, да и напряжения программистских сил для этого явно не требуется.

Поддерживать один текст было бы баловством. Если делать, так серьезно. Нужен единый формат. Куча умных людей, ведущих разработчиков ПЛК со всей планеты пытаются это сделать уже больше 10 лет в рабочей группе PLCopen. В МЭК системах есть специфика, которая не желает лезть в текст никаким боком. Сейчас формируется такой стандарт на базе схем XML. Они открыты для обсуждения. Пожалуйста, примите участие в этой работе, если знаете решение. В CoDeSys новый формат уже поддержан. Если его поддержат все, то проблемы действительно не будет.

Для удобного сравнения не только текстов программ, но и всего, что входит в проект, включая графические объекты, нужно глубоко интегрировать в CoDeSys специальный графический интерфейс. Это и есть оболочка ENI. Это не ‘свой паровоз’, а только заказной тюнинг, типа сиденья с запоминанием настроек под машиниста. Он ставится на существующие системы управления версиями, в том числе на Subversion . Система многопользовательская. Пользоваться можно в рамках многих проектов. Наборы POU могут входить во много проектов. Удаленный программист может править блоки, за которые он отвечает, удаленно подключившись к базе данных из своей системы.

[Herzog]

Если делать, так серьезно. Нужен единый формат.

А зачем?
Зачем делать единое колесо для автомобиля и самолета?
Зачем делать единый формат сохранения и сравнения для графического языка релейных схем и текстового ST?

Для удобного сравнения не только текстов программ, но и всего, что входит в проект, включая графические объекты, нужно глубоко интегрировать в CoDeSys специальный графический интерфейс. Это и есть оболочка ENI. Это не ‘свой паровоз’, а только заказной тюнинг, типа сиденья с запоминанием настроек под машиниста.

Не вижу никакой надобности объединять уже существующий текстовый исходник вместе с графическими файлами, да еще и выдумывать узкоспециализированный инструмент для сравнения этого монстра.
Зачем удалять гланды через задницу?

Есть отработанная еще с египетских пирамид система сравнения текстовых файлов - ну и сравнивать ею исходники текстов CoDeSys, сохраняемые в том текстовом виде, как они были написаны.
А графику сравнивать другим способом.

Впрочем ладно, буду импортировать....
Специальной командой.
Текст редактора в текст файла.

С уважением,
Herzog

[Игорь Петров]

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

В CoDeSys есть графические языки программирования и не только. Тексты составляют малую часть объектов. В проекте сохраняется все, даже координаты элементов на экране и трассировка соединений. Вы предлагаете взять отдельные текстовые шмотки от полноценного проекта и на них поставить СКВ. Оставшиеся объекты просто бросить. При открытии проекта из СКВ большая часть информации будет утрачена. Допустим, делаю красивую CFC программу. Затем сохраняю проект и бац, вижу безобразные перемешанные куски. Мне это надо? Без мата такую СКВ никто использовать не будет. Это несерьезное предложение.

Серьезный подход состоит во внедрении в среду программирования оболочки над СКВ, которая позволит нормально хранить весь проект, без потерь, удобно и красиво. Это и есть ENI.

Существует старинный текстовый формат PLCopen (как в Омроне). Ветер правильно заметил, что он практически бесполезен. Поэтому, PLCopen проводит работы по новому открытому стандарту на основе XML. Он позволит использовать проект в разных средах, разных компаний. В CoDeSys V3 он уже поддержан. Ждем поддержки в других средах.

[Herzog]

Я не пытаюсь заявлять, что нужно использовать из всех СКВ только ту, которая нравится мне лично.
Если:
1. Вы рисуете программу графически и Вам нравится специализировано для этого спроектированная ENI,
2. Вы тратите время на красивую визуализацию,
2. Ваш проект суть "вещь в себе", не имеющий выхода на другие программные средства и стандартные средства разработки других программных вещей,
- то ради бога, пишите и пользуйтесь именно и только специализированной ENI.
Это будет лучший выбор.
Для Вас.

А я вот такой странный - хочу, чтобы текст сохранялся в текстовом виде. И анализировался и сравнивался - методами анализа текста.
Мое пристрастие к здравому смыслу не лечится.
Поэтому, Игорь, не тратьте на меня столько времени.

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

С уважением,
Herzog

[Игорь Петров]

.проект суть "вещь в себе", не имеющий выхода на другие программные средства и стандартные средства разработки других программных вещей..

Нет. ENI просто удобный интерфейс СКВ для МЭК программ. Он позволяет работать не только с выборочными текстовыми объектами, а со всем проектом по-человечески. Я могу работать с деревом объектов в нормальной графической форме, не надрывая мозг. Проект не вещь в себе. Другие программистские и конструкторские инструменты работают с этой же базой данных одновременно.

..хочу, чтобы текст сохранялся в текстовом виде. И анализировался и сравнивался - методами анализа текста. Мое пристрастие к здравому смыслу не лечится.

Это правильно. Одновременно должны работать аналогичные удобные штуки и для всех графических языков, объектов, 3D SoftMotion и др. и пр. Логично чтобы СКВ для МЭК системы решала проблему целиком, без каких либо условий или ограничений. Применять СКВ только к текстовым объектам странная полумера-недоделка. Если освоить езду на 2х колесах, то можно не чинить пробитое колесо целый год - здравый смысл есть, но ИМХО это кино не для всех.

[Herzog]

Проект не вещь в себе.

Как Вы предполагаете передавать свои изменения версий в разработку внешней программу, созданную на другой платформе?
Например, в программу на PC, которая работает во взаимодействии с ПЛК?
Никак? на бумажке? И после этого Вы спорите, что ENI не делает из проекта CoDeSys "вещь в себе"?

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

Применять СКВ только к текстовым объектам странная полумера-недоделка.

Никто этого и не предлагает. Не встраивать СКВ типа SVN в CoDeSys, а дать возможность программеру выбирать - какой СКВ пользоваться, встроенной или внешней. Это же так просто!
Достаточно было в меню "File" добавить одну строку - "Сохранить как исходный текст". Еще лучше - в настройках проекта поставить разовый переключатель "Сохранять как файл проекта (*.pro) или файлы исходников (Да/нет)"
Для этого даже писать в оболочке дополнительно ничего не надо, ничего не надо преобразовывать - стандартная функция в Дельфи или СиБильдере "save all".

Если освоить езду на 2х колесах, то можно не чинить пробитое колесо целый год - здравый смысл есть, но ИМХО это кино не для всех.

ENI предлагает ездить на автомобиле с колесами разного диаметра, специально вытесав для этого монстра колеи разной глубины. Одни для грязи, другие для асфальта.
А между тем гораздо проще ездить на танке по грязи, а на линкольне - по автостраде. Чем навешивать (а вдруг понадобятся?) траки гусеницы на лимузин.

С уважением,
Herzog