CODESYS V3.5. Вопросы и ответы

[ВалераМ]

Насколько я понимаю - на стороне ПЛК вы планируете использовать Modbus TCP.
Тогда все вопросы по .GSD нужно задать техподдержке производителя вашего конвертера.
К нему должно быть какое-то конфигурационное ПО, которое позволяет импортировать .GSD и сформировать карту регистров Modbus.
Когда получится сформировать такую карту и опросить насос через конвертер с ПК с помощью какого-нибудь ПО, работающего в режиме Modbus Master (например, Modbus Poll или MasterOPC Universal Modbus Server) - то настроить опрос в CODESYS не составит проблем.

В мануале по CDS написано что их можно подключать как таргет файлы, поэтому я и спросил. Просто скорее всего Овен адаптировало CDS только для своих контроллеров, тогда конечно другое дело. Просто там нет карты регистров модбас, потому что профибас дипи только поддерживает именно этот вид насосов.

[Евгений Кислов]

В мануале по CDS написано что их можно подключать как таргет файлы, поэтому я и спросил. Просто скорее всего Овен адаптировало CDS только для своих контроллеров, тогда конечно другое дело. Просто там нет карты регистров модбас, потому что профибас дипи только поддерживает именно этот вид насосов.

Их (.gsd файлы) действительно можно подключать в CODESYS.
Но наши контроллеры физически не поддерживают Profibus - так что не очень понятно, что вы ожидаете от этого получить.

Если у вас конвертер интерфейсов (Profibus / Ethernet), а не протоколов (Profibus / Modbus) - то опросить ваш насос с нашего ПЛК у вас не получится.

[ВалераМ]

Смысла нет тему продолжать, раз контроллеры овен не поддерживают GSD файлы.

[Frants]

Доброе время суток всем!
Имеется:
-- -- -- -- -- -- -- -- -- --
CODESYS V3.5 SP14 Patch 3
PLC210-04; plc210 1.3.0309.1257
Версия ядра ПЛК 3.5.14.30
-- -- -- -- -- -- -- -- -- --
Вопрос по Codesys Symbol Configuration + OPC ОП Weintek. В процессе работы над проектом добавляются новые переменные, которые, в том числе, нужны и для ОП. Эти переменные объявляются с прагмой {attribute 'symbol' := 'read'}. Заметил, что если переменная в коде не используется, то сервис тегов ОП не видит её для добавления в список тегов. Это очень неудобно, потому что иногда требуется поработать сначала над проектом ОП, а потом уже эти переменные включать в обработку в ПЛК. Есть ли способ изменить такое поведение объекта Symbol Configuration, чтобы все теги с прагмой {attribute 'symbol'} были видны серверу OPC, независимо от их использования в коде?

[Евгений Кислов]

Доброе время суток всем!
Имеется:
-- -- -- -- -- -- -- -- -- --
CODESYS V3.5 SP14 Patch 3
PLC210-04; plc210 1.3.0309.1257
Версия ядра ПЛК 3.5.14.30
-- -- -- -- -- -- -- -- -- --
Вопрос по Codesys Symbol Configuration + OPC ОП Weintek. В процессе работы над проектом добавляются новые переменные, которые, в том числе, нужны и для ОП. Эти переменные объявляются с прагмой {attribute 'symbol' := 'read'}. Заметил, что если переменная в коде не используется, то сервис тегов ОП не видит её для добавления в список тегов. Это очень неудобно, потому что иногда требуется поработать сначала над проектом ОП, а потом уже эти переменные включать в обработку в ПЛК. Есть ли способ изменить такое поведение объекта Symbol Configuration, чтобы все теги с прагмой {attribute 'symbol'} были видны серверу OPC, независимо от их использования в коде?

Добрый день.
У меня проблема не воспроизводится.

2022-05-16_13-48-08.png 2022-05-16_13-48-01.png 2022-05-16_13-53-28.png

Выложите, пожалуйста, простейший проект, в котором я смогу ее увидеть.

[Frants]

Добрый день.
У меня проблема не воспроизводится.

2022-05-16_13-48-08.png 2022-05-16_13-48-01.png 2022-05-16_13-53-28.png

Выложите, пожалуйста, простейший проект, в котором я смогу ее увидеть.

Да действительно, Ваш вариант работает. Прошу простить за неточность. Вопрос относится к переменным, объявленным в глобальных списках (Global Variables List - не знаю как правильно по-русски). Вот с ними как раз эта проблема. Ну, не то чтобы совсем проблема - неудобно.

[Евгений Кислов]

Да действительно, Ваш вариант работает. Прошу простить за неточность. Вопрос относится к переменным, объявленным в глобальных списках (Global Variables List - не знаю как правильно по-русски). Вот с ними как раз эта проблема. Ну, не то чтобы совсем проблема - неудобно.

Это известная особенность, которая не запланирована к исправлению (в тикете написано только про readwrite, но, похоже, это касается всех типов доступа).

16-05-2022 16-26-05.png

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

[Frants]

Это известная особенность, которая не запланирована к исправлению (в тикете написано только про readwrite, но, похоже, это касается всех типов доступа).

16-05-2022 16-26-05.png

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

Ясно. Благодарю Вас за помощь. Просто как-то сразу так пошло, через GVL. В небольшом проекте очень удобно, все переменные по своим группам. А в PLC_PRG - как их делить? Там, наверное, всё в одной куче получится, ещё хуже разбираться...

[Евгений Кислов]

Ясно. Благодарю Вас за помощь. Просто как-то сразу так пошло, через GVL. В небольшом проекте очень удобно, все переменные по своим группам. А в PLC_PRG - как их делить? Там, наверное, всё в одной куче получится, ещё хуже разбираться...

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

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

Точно так же хороший стиль программирования подразумевает стремление к структуризации и модульности ПО.

[Frants]

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

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

Точно так же хороший стиль программирования подразумевает стремление к структуризации и модульности ПО.

Это да, не поспоришь. Благодарю за помощь!