Сработает. Этот канал для этого и создавался.Цитата:
Сообщение от service
Сработает. Этот канал для этого и создавался.Цитата:
Сообщение от service
то есть возможно обойтись без функциональных блоков (ComConn, MV110_8A_inputs и т.д) из библиотеки ModulsOwenLib и их обработки?
Все верно. В тоже время библиотеки позволяют более глубже и гибче настроить процесс обмена с периферийными устройствами.Цитата:
Сообщение от service
День добрый!
Кто-нибудь, подскажите или укажите, где можно посмотреть пример связи датчика влажности ПВТ-100 и СПК110? Может кто сталкивался с данным вопросом?
Предстоит писать проект, который будет состоять из 5 модулей МВ110-224-8А, одного МУ110-224-8Р и четырех ПВТ-100.
Модули четко считываются и работают, а вот с ПВТ-100 загвоздка. Его опрос идет но, показания считанных регистров по нулям.
Пробовал делать пробную конфигурацию с одним только ПВТ ситуация такая же, опрос есть - горит зелененький кружок возле устройства в дереве проекта в онлайне.
В качестве устройства для опроса ПВТ 100 добавляю стандартный Modbus Slave COM Port.
Прилагаю пробный пример.
Вложение 36766
Добрый день.Цитата:
Сообщение от Евгентий
Сделайте вот так:
Вложение 36767
Вот как!
Спасибо Евгений!
Попробую.
А все остальное, как я понял, правильно?
Если речь о проекте - то в нем правильные номера регистров, да.Цитата:
Сообщение от Евгентий
У меня СПК110 и скорость обмена с 5 модулями 19200.
В CODESYS ставлю частоту циклов основной программы 200 мс: I, II модули работают, III помигивает "аварией", а на IV "авария" светится постоянно.
Таймауты 1 секунда.
Методом тыка уменьшил частоту циклов основной программы до 90 мс, "аварии" исчезли.
Объясните пожалуйста, в какой задаче "сидит" подзадача обмена данными по RS485? В одном потоке с основным циклом?
Как правильно подобрать время цикла, кроме метода тыка?
Ведь может быть ситуация, когда циклу надо не менее 200 мс, а этого не хватает для полноценного обмена с модулями, который требует например не более 100 мс. Как тогда?
Спасибо.
По умолчанию обмен происходит в задаче с наименьшим временем цикла. Если в проекте одна задача (у вас, видимо, так) - то, соответственно, обмен происходит в ней.
Можно создать отдельную задачу и привязать обмен к ней (см. настройки Modbus Master).
Но зачем? По умолчанию задача MainTask имеет время цикла 20 мс. Поднимать его выше я, честно говоря, не вижу смысла. Если вам необходимо выполнять какие-то операции раз в 200 мс - то лучше для этого использовать таймер в программе.
Евгений, спасибо за оперативный ответ.Цитата:
Сообщение от Евгений Кислов
В разделе "Конфигурация задач/монитор" можно увидеть "среднее время цикла (нс)". Можно ли его использовать
для выбора времени цикла? Или использовать "максимальное время цикла"? Оно бывает на порядок больше.
Если выбрать маленькое время цикла возможны же сбои, когда один цикл не завершился, а уже вызывается другой. Процессор будет забит под завязку и его может "кому-то" не хватить. или это не критично?
Буду очень благодарен, если разъясните.
1. Надо заметить, что в мониторинге конфигуратора задач время отображется в микросекундах.
2. В значительном числе случаев дефолтного времени (20 мс) для задачи пользовательского кода вполне хватает.
Но если внезапно нет - то можно порекомендовать задавать его как (среднее время цикла в мониторинге, переведенное в мс * 1.25)
3. В CODESYS 3.5 вытесняющая многозадачность. Все циклы так или иначе отработают полностью. Так что "маленькое" время цикла в значительном числе случаев действительно не критично.
P.S. - на всякий случай: мс = миллисекунды (не микро)
Спасибо!
То есть теоретически можно поставить обновление и 1 мс, и СПК будет работать нормально.
Не совсем правда понятно, если любой цикл (рабочей программы/обмена РС485/визуализации) прервется на половине своей работы, "вытеснится" другой задачей...
Нет, 1 мс - плохое решение. Начать следует с 20 мс. Далее можно смотреть по среднему времени реального цикла - если не укладывается, то повысить.Цитата:
То есть теоретически можно поставить обновление и 1 мс, и СПК будет работать нормально.
Представьте: вы 3 часа писали код, потом вам надоело (глаза устали), и вы решили сходить немного прогуляться. Теперь вы никогда не вернетесь домой и не допишите код?Цитата:
Не совсем правда понятно, если любой цикл (рабочей программы/обмена РС485/визуализации) прервется на половине своей работы, "вытеснится" другой задачей...
Наверное, нет (вернетесь и допишите).
ПЛК выполняет задачи не последовательно одну за другой, а небольшими фрагментами (т.е. задачи постоянно переключаются). Время цикла и приоритет определяют, сколько единиц времени будет отдано той или иной задачи.
В вашем случае достаточно поставить время цикла MainTask = 20 мс (тогда обмен будет идти нормально), а дальше в коде выполнять необходимые операции с нужной частотой, используя таймеры (см. библиотеку Standard).
Добрый вечер!
Первый раз пишу обмен по Modbus на Codesys 3.5, читал вот это краткое руководство - https://akytec.de/en/blog/modbus_kom...seinstellungen
Есть СПК 107, конвертер Com<->Ethernet ЕТ-485 и Scada, которая вне проекта, в качестве отладки взял RapidScada.
Нужно управлять СПК107 со стороны SCADA по Modbus TCP.
Вопросы:
1. В CDS один из Com-портов выделил под Modbus, его делать Master или Slave (Modbus_COM -> Modbus_Serial_Device)? По логике слейва достаточно, опрашивать СПК будет SCADA.
2. Конвертер в этом случае должен быть мастером сети? В объекте Modbus_Serial_Device параметр Unit ID - это адрес СПК?
3. Для передачи REAL значений в Modbus_Serial_Device на вкладке I/O Mapping нужно использовать <имя_переменной>.WordArray?
4. Что еще почитать про обмен по Модбас, особенно когда используется конвертер, как у меня?
Заранее спасибо!
Добрый вечер.
1. Да, Modbus Serial Device.
2. Да.
3, 4. Вам поможет этот документ:
https://ftp.owen.ru/CoDeSys3/11_Docu...CADA_v.1.1.pdf
В нем описывается, как опросить СПК через OPC. Настройка со стороны SCADA будет примерно такой же.
Добрый день!Цитата:
Сообщение от Евгений Кислов
Спасибо, с чтением более-менее, а запись командой 6 (Write Single Register) не работает.
Вложение 37356
На скрине две переменные, V0 и V1, объявлены обычно:
Со стороны Скады пакеты такие:Цитата:
VAR_GLOBAL
V0:WORD;
END_VAR
PROGRAM PLC_PRG
VAR
V1:WORD;
END_VAR
V0:
Отправка (12): 00 00 00 00 00 06 01 06 00 00 00 64
Приём (7/7): 00 00 00 00 00 06 01
Приём (5/5): 06 00 00 00 64
V1:
Отправка (12): 00 00 00 00 00 06 01 06 00 01 00 C8
Приём (7/7): 00 00 00 00 00 06 01
Приём (5/5): 06 00 01 00 C8
Если их распарсить, то все выглядит прилично, но в CDS ничего не меняется.
Почему не работает, как думаете?
А что должно меняться в CDS? Вы значение записываемой переменной меняете?
Ну да, я ожидаю, что V0 и V1 примут переданные значения. А разве не так должно быть?Цитата:
Сообщение от Евгений Кислов
Ваш конвертер умеет Modbus TCP в RTU преобразовывать?
Желательно еще просниффить обмен со стороны RS-485.
В настройках слэйва в CDS стоит галочка Таймаут?
Ну я ровно этой же скадой писал в МУ110-224.16Р, кондей Митсубиси и еще какую-то штуковину крайний раз, только шлюз был MOXA.Цитата:
Сообщение от Евгений Кислов
Пользуюсь вот этим парсером:
http://modbus.rapidscada.net/
Адрес слейва у меня 1, все верно, 6 - код команды Modbus.
Попробовал командой 16:
V0:
Отправка (15): 00 00 00 00 00 09 01 10 00 00 00 01 02 00 64
Приём (7/7): 00 00 00 00 00 06 01
Приём (5/5): 10 00 00 00 01
V1:
Отправка (15): 00 00 00 00 00 09 01 10 00 01 00 01 02 00 64
Приём (7/7): 00 00 00 00 00 06 01
Приём (5/5): 10 00 01 00 01
Результат такой же - в проекте переменные V0 и V1 не меняются.
Вообще, в CDS отладка или логи по этому поводу есть какие-нибудь? Скада-то мне показывает что происходит с ее стороны, а вот из CDS я ничего не вижу.
Я отредактировал свой пост выше, ответьте про галочку, пожалуйста.
Со стороны CDS логов нет. Нужно прослушивать линию связи (например, подключить к порту АС4 и запустить какую-нибудь программу-терминал)
Ну конвертер этим и занимается, на стороне RS-485 RTU, а дальше - TCP, пакеты которые я присылал со стороны скады, то есть это TCP.Цитата:
Сообщение от Евгений Кислов
Галочка стоит, значение 2000.
Галочку надо снять. Если она стоит, то после 2000 мс (или другого указанного значения) без получения команд от мастера - контроллер обнуляет значения регистров.
Отлично, спасибо! Вещь крайне неочевидная, надо ее в мануалы добавить. CDS продолжает удивлять =)Цитата:
Сообщение от Евгений Кислов
Евгений Кислов
Наверное последний вопрос, и самый каверзный - про REAL.
Сделал UNION как в мануале:
Соответственно, в Модбас смотрят переменные типа:Цитата:
TYPE Real2Word :
UNION
Value:REAL;
WordArray:ARRAY [0..1] OF WORD;
END_UNION
END_TYPE
Application.System.Regulators.P.Value.WordArray[0]
Application.System.Regulators.P.Value.WordArray[1]
В скаде при чтении отображаются корректные значения, как в CDS, если это две двухбайтовых переменных, то есть для значения "100" будет:
Байт 0 = 0
Байт 1 = 17096
Но если я делаю в скаде одно четырехбайтовое значение float, то получаю ерунду.
Понятно, что это проблемы скады, и тем не менее, мне нужно в документации дать таблицу адресов, как все это корректно указать?
Аналогично с записью REAL, для значения "100" просто пишет в нулевой байт 100, в первый не пишет ничего - это для 2*ushort.
Для 1*float путает байты:
Байт 0 = 17096
Байт 1 = 0
Если изменить порядок следования, то в пишет в Байт 0 ерунду.
Для начала попробуйте поменять Application.System.Regulators.P.Value.WordArray[0] и Application.System.Regulators.P.Value.WordArray[1] местами.
Т.е.
Application.System.Regulators.P.Value.WordArray[1]
Application.System.Regulators.P.Value.WordArray[0]
Если это не поможет - то, возможно, для вашей SCADA надо менять местами не регистры (WORD), а байты (BYTE).
Самый простой способ определить правильный порядок - записываете из SCADA в СПК значение типа REAL (например, 11.22). Смотрите, какой у него порядок байт.
После этого объявляете два экземпляра UNION.
В одном из них задаете REAL, и копируете байты из него в другой UNION, при этом меняя их порядок на тот, который нужен SCADA. После этого привязываете к регистрам слэйва WORD из второго UNION.Код:TYPE Real2SCADA :
UNION
Value:REAL
ByteArray:ARRAY [0..3] OF BYTE;
Modbus: ARRAY [0..1] OF WORD;
END_UNION
END_TYPE
Добрый день комрады! Есть такая проблема, к одному modbus порту на СПК207 подключено несколько слейвов(блок управления кранами). А вопрос у меня следующего плана, как исключить такой модуль из опроса, если один из них вышел из строя?
Добрый день. В проекте используются шаблоны модулей Mx110?Цитата:
Сообщение от nsarychev
Нет, устройство стороннего производителя. Подключены как modbus slave, com-port.Цитата:
Сообщение от Евгений Кислов
Тогда можно в настройках ПЛК (компонент Device) поставить галочку Enable Diagnosis for device.Цитата:
Сообщение от nsarychev
Вложение 37426
После этого в коде программы можно отключить опрос устройства следующим образом:
где Modbus_Slave_COM_Port - имя нужного slave-устройства в дереве проекта.Цитата:
Modbus_Slave_COM_Port.Enable := FALSE;
Для возобновления опроса, соответственно, нужно присвоить переменной значение TRUE.
Поэтому от вас был вопрос "В проекте используются шаблоны модулей Mx110?". Тогда да, кроме блоков BCV-1-01(блок управления кранами), есть еще модули входов и выходов Мх110(сидят на другом порту), и шаблоны я использую.
Тогда есть следующие варианты:Цитата:
Сообщение от nsarychev
1. Реализовать опрос вашего устройства в режиме RISING_EDGE (по команде из программы).
2. Отказаться от шаблонов и реализовать опрос модулей Mx110 через стандартные компоненты Modbus_Slave_COM_Port.
Вас понял, спасибо!Цитата:
Сообщение от Евгений Кислов
Второй вариант мне ближе, буду его реализовывать.
С Уважением Н. Сарычев.
Я всетаки попробовал :) Прошу обратить внимание, что попытка использовать такой подход совместно с шаблонами Мх110 приведет к исключению в программе. Все вроде работает:confused: А какого рода исключение в программе?Цитата:
Сообщение от Евгений Кислов
подскажите начинающему , программисту и разработчику с вашими плк и спк ,когда идет связь по протоколу modbus rtu не нужен спец. кабель закупать для связи между этими устройствами ,как у siemens (сиреневый кабель profibus).Т.е я так понимаю достаточно обычного кабеля с жилами 1,5 мм2 и установкой оконечного сопротивления R=120om))
все коллеги вопрос отпал сам собой из первой документации по протоколу modbus ))) Для линий связи RS-485 необходимо использовать экранированный кабель
с витой парой, предназначенный для промышленного интерфейса
RS-485 с волновым сопротивлением 120 Ом(например, КИПЭВ)
Здравствуйте, товарищи знатоки.
Есть СПК110. К нему по RS-485 подключены: ТРМ-136, МВ1108А, и МК110-8ДН.4Р. С последними двумя проблем нет - использую шаблоны, обмен по протоколу ОВЕН работает. Как быть с ТРМ-136? Пытался разобраться на найденном примере с СПК207 и ТРМ212, но сходу не осилил. То есть правильные сетевые настройки и перечень параметров ТРМ-136 у меня есть, но не хватает опыта этим воспользоваться. Может быть, есть более близкий пример?
Подскажите, куда копать. Надо считывать текущие измеренные значения с входов.
Добрый день.Цитата:
Сообщение от БелУрал
Наши шаблоны Mx110 работают по протоколу Modbus RTU. ТРМ136 также поддерживает этот протокол, поэтому смотреть пример с ТРМ212 не надо - там используется протокол ОВЕН.
Посмотрите документ СПК. Modbus (ссылка в подписи) - там приведен пример опроса устройства по Modbus через стандартный элемент Modbus Slave (добавляется также, как шаблоны модулей).
Если есть возможность, свяжитесь со мной по skype - я помогу с настройкой.
Спасибо, пойду читать. Мысль вроде бы ясна (пока).
Здравствуйте, Евгений.
Изучив документ "СПК. Modbus", попробовал считать параметр со входа ТРМ136 с помощью объединения и с помощью указателя, использовал поочередно функцию чтения 3 и 4.
Результат во всех случаях почти одинаковый - связь есть, переменная типа WORD, отвечающая за положение десятичной точки, имеет значение 1, переменная типа WORD, отвечающая за текущее значение температуры, имеет значение, соответствующее реальной температуре в данный момент (например 1652 при 165,2 градусах) , а значение переменной типа REAL, которое должно бы выражаться числом с плавающей десятичной точкой, выглядит примерно так: -7,351374Е-36.
Цифры и знаки "-" меняются при изменении функции чтения и способа преобразования.
Подозреваю, дело в какой-то простой мелочи, которой я не знаю. Пример бы мне, как в букваре только подробнее :)
Добрый день.
Вероятно, нужно поменять порядок регистров.
На примере с объединением: у вас к каналам последовательно привязаны переменные awModbusReal[0] и awModbusReal[1].
Поменяйте их местами - чтобы awModbusReal[1] стало первым (или наоборот - в зависимости от того, как вы их привязали сейчас).