Многозадачность и языки МЭК

Первоначально опубликовано Nekit ...хочется увидеть форум только по Codesys...

Он есть
форум  международный, на английском, но можно и на русском писать. Если накопится 'критическая масса' сделаем отдельный русский. Однако там люди увы больше любят спрашивать, чем отвечать. IMHO сейчас форум СТА лучший в своей области, по отзывчивости участников и удобству работы, поэтому тут и пишу.

Совсем недавно CAA для CoDeSys сделаны некоторые специализированные доп. биб-ки. В их числе есть биб-ка которая позволяет динамически создавать и управлять задачами. Инициировал это дело один заказчик, который использует CoDeSys под QNX. Изначально  он писал все на C, а МЭК проект запускал как одну из задач. Но постепенно эта МЭК часть сильно выросла и возникла идея делать все полностью в CoDeSys. Биб-ка по сути является интерфейсом для API ОС, с ее помощью можно даже отдельный функциональный блок запустить отдельным потоком. Статическая настройка задач и семафоры были всегда, но вот столь гибкое динамическое конфигурирование задач в новинку.

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

Первоначально опубликовано lolik ...дать ссылку для начинающего работать в CoDeSys на хороший учебник.

Есть документ Первые шаги… в дистрибутиве.
Книжка, статьи, публикации всякие разные
+ Самое быстрое и эффективное – тренинг курсы

Первоначально опубликовано lolik ...книжка...подойдет для начинающих...?

Книжка исключительно для начинающих (сейчас печатается доп. тираж, буквально на днях она должна появится в магазинах). Со времени ее выхода в CoDeSys появились ряд новшеств. Т.е. после книжки стоить почитать и статьи 'Отладка прикладных ПЛК программ в CoDeSys'. В дистрибутив включен мануал в pdf и хелп на русском, сделан он в форме лаконичного справочника. Для обучения он не подходит, заточен под оперативное получение информации в процессе работы.
Многие пользователи CoDeSys настаивают на том, чтобы сделать русский интерфейс, чтобы упростить изучение. Технически проблем нет, вопрос целесообразности. Обсудим это на ближайшей открытой конференции пользователей 23 мая. Если действительно нужно, то будет.

Мб чутка в офф-топик, но присоединюсь к SAN в отказе от русификации.

Перевод меню не только не полезен, но и зачастую вреден!

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

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

Мне кажется, это не совсем соответствует истине.

Спасибо за отзывы! Согласен. Русификацию, как правило, требуют совсем начинающие, пока не выучат десяток основных команд.
Перевести меню и диалоги проблемы большой нет. Хотя факт в том, что сейчас в переводах используется весьма разная терминология. Поэтому иногда приходится смотреть английские документы, чтобы понять что вообще имеется в виду.
Сложнее всего с конфигураторами ПЛК и сети (особенно CANopen и Профибас). Здесь параметры в диалоги подставляются изготовителями оборудования. Т.е. в этих местах может получиться забавная разноязычная смесь .
Может быть, кроме интерактивного хелпа стоит еще  перевести сообщения об ошибках и предупреждения компилятора?