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

[Herzog]

странно у вас построена система управления производством - если этот ваш PC решит зависнуть, у вас ничего не сломается в цехе?

Нет.
У меня не система управления производством (хотя отдельные ее элементы есть), а система контроля производста. Производство не остановится, а перестанет собираться контрольная информация.

вот, сами говорите, что их много, все чудесно универсальны. так какой из них отдать предпочтение фирме 3s? самой лучшей Tortoise? а если пользователи других СКВ начнут хотеть поддержки своей?

У всех существующих систем контроля версий есть одна общая деталь - они в основном работают с текстовыми файлами. Здесь их преимущества колоссальны.
Бинарные файлы пишутся, фиксируются, но не сравниваются.
И если бы разработчики CodeSys сохраняли проект в виде текстовых файлов, можно было бы использовать любую систему контроля версия, не выдумывая свою уникальную.

3s такая же корпорация, также зарабатывает деньги, за дешево продает кдс, за дорого ени

Можно, я не буду комментировать такую политику?
На форуме неприлично ругаться матом...

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

[Herzog]

На любой прибор ОВЕНа выступающий в роли slave-устройства в документации идет таблица регистров модбас,

На область регистров modbus я последовательно отражаю таблицу записей состояний. Например, массив Records[0..25][0..40] - 25 каналов, 40 состояний на канал. А может быть - Records[0..32][0..30]. Как системщик на PC может понять, что за поток идет - 24*40 или 32*30?
Я ему должен передать из своей разработки формат массива, который есть на текущий момент в моей разработке. Если бы я сбросил файл констант проекта в СКВ, то он просто включил бы его в свой С-проект с такой же СКВ - все просто.
А сейчас что мне делать? писать на бумажке - "каналов 25, состояний 30" - каждый раз при изменении моей программы? Так если бы всего две константы менялись!

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

Прежде всего для ST не нужно выдумывать отдельную СКВ, достаточно включить возможность сохранять проект в текстовом виде из текстового редактора - в этом нет никаких проблем. Если текст уже есть в виде текста, то какая сложность его сохранить в этом виде?
Ну и если уж они включили текстовый язык программирования, то можно было бы предвидеть, что исходный текст может понадобиться. Хотя бы для системы контроля версий. Особого ума, да и напряжения программистских сил для этого явно не требуется.

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

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

Пляски как раз в CoDeSys. Причем как я понимаю, именно из-за платности собственной системы контроля версий.

Вы это серьезно? Если бы вдруг мозги у 3S закрутились в эту сторону, то давно бы сделали платную среду программирования. Бизнес схема 3S проста и логична, никаких задних мыслей в ней заложено. На рантайм CoDeSys продается 300 тыс. лицензий в год. С позиции голой прибыли нужно заниматься только этим. Но, иногда возникают потребности на отдельные сервисы и компоненты, требующие доп. работы. В V2.3 ENI излишне универсален и сложноват в установке и конфигурировании. Все серьезные заказчики просили сделать под ключ. Отсюда исторически и сложилась модель его распространения. Сейчас стоит задача упростить ENI и включить в дистрибутив V3. Это обсуждалось на прошедшей конференции.

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

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

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

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

[Herzog]

ну ладно, это может слишком надолго затянутся, Hezog попробуйте следующее и успокойтесь. Выделяете необходимый ФБ на ST, в меню выбираете Проект -> Объект -> TODO:Exportieren... сохраняете предлагаемый файл. Открываете этот файл в любом редакторе и вуаля наслаждаетесь текстовой формой Вашего исходника

Это поштучный перебор POU. У меня сейчас в проекте текстовых файлов шесть. Перебирать каждый раз все шесть?

Лучше открыть Project->Import. В этом случае сохранятся все документы разом. Нет риска пропустить.
Теперь осталось освоить макросы, чтобы делать это одной кнопкой.

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

[Herzog]

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

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

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

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

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

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

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

[Herzog]

А как же Ваш изначально заданный вопрос, по моему я на него ответил и что Вы за человек Вам даже лишних 30 раз мышкой кликнуть лень

Вам плюсик. Распишитесь и получите.
Только кликните 30 раз...

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

[BETEP]

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

неужели никто из Вас никогда не путал версии своих прог? я путал, заказчики которые тиражируют, путают постоянно.
Как графику убогой визуализации привязать к тексту? да никак, Herzog этого и не просит. неужели кто-то пользует визуализацию кодесиса? (не для отладки) признавайтесь кто так низко пал, скрины приложить.

Отношение кодесиса к стандартным протоколам доставляет...
отказались от жесткой адресации на "благо" пользователя, получили дополнительный геморой для пользователя, а ведь как просто отдать на верхний уровень таблицу массивов по адресам и форматам и не напрягать верхний уровень контролем версий.

Система CoDeSys v.3 все больше и больше поворачивается лицом к специалистам.

+1 этой фразе. достойно башорга.

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

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

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

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

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

[BETEP]

это координаты, размеры, шрифты двух блочков и линии между ними в омроновском CFS,
XML не напоминает?

<Elements>
<SFCStep N="Step1" X="40" Y="40" O="Trans1" T="Initial" />
<SFCTransition N="Trans1" Y="80" O="Step2" />
<SFCStep N="Step2" X="160" Y="160" H="120" />
</Elements>
<Font Name="Arial" Size="8" Height="13" />$?St$Bk?_#[15] 

в текстовике есть и бинарные вставки