quote: Выполняется соответственно групповое чтение или групповая запись (WORD, FLOAT) при обмене с заданным устройством по MODBUS (в том числе по MODBUS TCP/IP). Устройство и начальный адрес задаются в источнике, количество считываемых/устанавливаемых параметров определяется числом аргументов канала.
Запрос по Modbus увеличивется на 1. Пример: - создаем источник RinWord как указано выше, - создаем канал ChGroupReq в нем 4 аргумента, - привязываем его к источнику. Запускаем, смотрим запрос ... 00 05 CRC Если сделать 3 аргумента для соотв. обмена с устройством, то где прописывается 4-ое значение?
Posted by Алекс К (Участник № / Member № 1337) on :
Почему по Modbus не проверяется в ответе соответсвие адресса устройства и номера функции? Нехорошо получается. Данные от другого устройства да и еще и с другой функцией хаваются на ура
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1. В групповом запросе Modbus RTU сейчас запрашивается на один параметр больше, чем должно быть. Мы это исправим.
2. Другое устройтсво не должно отвечать на запрос. Попробуйте увеличить таймаут. У нас данная ситуация не воспроизвелась
Posted by Grigorovskih (Участник № / Member № 1915) on :
Господа разработчики, ситуации с попаданием ответа не в тот канал были и в релизе 6.05, пока не выстроишь каналы по возрастанию ID, те что связаны с источниками. А у Вас ситуация и не воспроизведётся если Вы не подключите пару тройку реальных девайсов на шину RS485(к примеру), да так чтоб эти устройства имели бы ещё разное время задержки на выдачу ответа в сеть, ведь синхронизации в том или ином виде в таком протоколе нет, поэтому было бы неплохо всё же иметь возможность контроля адреса в ответе и записи его в соответствующий канал (аргумент в случае использования ChGroupReq)
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Ошибка релиза 6.05 давно была исправлена, и к текущей ситуации отношения не имеет.
По протоколу Modbus не может быть ответа от устройств с другим номером, не совпадающим с номером устройства в запросе.
Posted by Алекс К (Участник № / Member № 1337) on :
По нольмодемному кабелю (ответ на запрос со второго ПК) кушает и другой адрес и другую функцию.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Проверка адреса и функции будет введена.
Posted by Алекс К (Участник № / Member № 1337) on :
quote: -------------------------------------------------------------------------------- Выполняется соответственно групповое чтение или групповая запись (WORD, FLOAT) при обмене с заданным устройством по MODBUS (в том числе по MODBUS TCP/IP). Устройство и начальный адрес задаются в источнике, количество считываемых/устанавливаемых параметров определяется числом аргументов канала. -------------------------------------------------------------------------------- Неполучается по такому описанию из Helpa сделать групповую запись Word. Прошу дать последовательность действий. Аргументы в канале ChGroupReq IN или OUT? Как привязать к источнику, экрану? и т.д.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1. Создаете источник W_Word(16) и настраиваете его. 2. Создаете канал Call с типом ChGroupReq 3. Привязываете источник простым drag'n'drop'ом к каналу Call 4. Создаете необходимое количество аргументов (OUT, тип INT) 5. Настраиваете сеть или COM порт
Posted by Алекс К (Участник № / Member № 1337) on :
Придерживаюсь всех пунктов, но P_mon дает пусто. При чем, при просмотре компонентов в реальном времени - аргументы канала Call с типом ChGroupReq данные с ГЭ кнопка получают. В чем проблема? Перепроверьте пожалуйста.
[ 16.06.2011, 10:06: Сообщение отредактировал / Message edited by AdAstra Technical Support ]
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
А Вы единичку в Call посылате?
Posted by Алекс К (Участник № / Member № 1337) on :
Теперь посылаю, спасибо.
Другой вопрос: Есть функция W_Word(16) с последующей задержкой на выполнение других команд (_wait)?
Posted by Алекс К (Участник № / Member № 1337) on :
Прошу дать ответ на вопрос в предыдущем посте.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Это функция реализуется нами для корректного прохождения команды.
Posted by Алекс К (Участник № / Member № 1337) on :
Извините, ответ не понятен. Вы говорите о реализации в следущем релизе?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Нет, она уже реализована.
Posted by Алекс К (Участник № / Member № 1337) on :
В релизе 6.06.2 1. Ошибка по Привязке источника MODBUS чтения или записи исправлена! хорошо но 2. Привязка MODBUS.R_FIFO_Queue Параметр=2 перестал работать!(в пред. релизе все было ok) Байты данных ответа от устройства прописываются в arg0(№ функции) и arg1(кол-во слов запроса) канала ChGroupReq и конечно же запрос меняется. Проверьте пожалуйста.
[ 16.06.2011, 10:08: Сообщение отредактировал / Message edited by AdAstra Technical Support ]
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Эта проблема уже исправлена, будет доступно в след. релизе.
Posted by Karpelyanskiy S.V. (Участник № / Member № 2191) on :
Уважаемая техническая поддержка! Объясните пожалуйста, как с помощью канала CALL.ChGroupReq организовать получение данных из узла Trace Mode 5? В хелпе по этому поводу ничего конкретно не написано... Если есть пример подобного проекта, пришлите пожалуйста на адрес xxx@oemk.ru
[ 16.06.2011, 10:08: Сообщение отредактировал / Message edited by AdAstra Technical Support ]
Posted by Karpelyanskiy S.V. (Участник № / Member № 2191) on :
Уважаемая техническая поддержка! Пожалуйста ответьте на мой вопрос!
[ 16.06.2011, 10:10: Сообщение отредактировал / Message edited by AdAstra Technical Support ]
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Канал Call.(54) MLink – канал CALL с этим типом вызова в основном предназначен для обмена с мониторами версии 5. Если тип канала – INPUT, он запрашивает по M-LINK N значений (N – число аргументов канала CALL) у узла с номером, заданным атрибутом Параметр канала CALL, по каналу с индексом, заданным значением канала CALL. Полученные значения записываются в аргументы канала CALL.
Если канал CALL имеет тип OUTPUT, в нем может быть создано до 16 пар аргументов. Первый аргумент пары задает индекс канала, в который требуется передать по M-LINK значение, заданное вторым аргументом пары. Номер бита значения канала CALL, равный 1, задает номер пары для отработки. При отработке канала CALL отрабатывается одна пара, заданная самым младшим битом из всех, равных 1, после чего этот бит сбрасывается;
Posted by Karpelyanskiy S.V. (Участник № / Member № 2191) on :
Зачем Вы мне пишете про обмен по протоколу M-Link? Мне это не нужно. Вот выдержка из раздела справки о канале CALL.ChGroupReq: "В зависимости от атрибута Параметр, такой канал выполняет различные функции обмена с удаленным узлом (в том числе с узлом TRACE MODE 5) по сети или RS." Так как же организовать обмен с узлом TRACE MODE 5 по сети с помощью этого канала?
Posted by Soyuz (Участник № / Member № 2028) on :
Была поставлена цель, прочитать по протоколу ModBus RTU значение UDINT переменной контроллера. Для этой цели использовали канал Call.ChGroupReq. Создали в нём два аргумента In Uint. Приязали их к каналам Hex16. Канал Call.ChGroupReq привязали к источнику/приёмнику ModBus - Rout_Word(3). Настроили источник приёмник.
Запускаем проект на исполнение. Значения от контроллера получаем правильные, но с переменной переодичностью получаемые приходят нулевые значения. Хотя, программа PortMon показала, что на все запросы были переданы не нулевые ответы. Скажите, в чем может быть проблема, что в получаемых статичных данных, проскакивают нулевые значения?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Karpelyanskiy S.V. Связь с узлами Trace Mode 5 следует осуществлять с помощью канала Call.(54) MLink. Упоминание об организации такой связи с помощью канала CALL.ChGroupReq - ошибочное. Мы исправим это в документации. Для более развернутой связи с узлами Trace Mode 5 рационально использовать OPC-интерфейс.
Soyuz Проверьте правильность привязок каналов Hex16 к аргументам Call.ChGroupReq. Привязки должны быть к атрибутам ВХОД, а не РЕАЛЬНОЕ.
Posted by Soyuz (Участник № / Member № 2028) on :
Да, действительно проблема была в привязке. Спасибо.
Posted by AlKon (Участник № / Member № 1919) on :
Когда ожидается выход следующего релиза ? Разрабатывается программа - необходимо правильное распределение ответа от приборов или пока пользоваться неправильным? Или предложите пользоваться предыдущим релизом?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Вам нужна функция чтения MODBUS.R_FIFO_Queue? Или что-то другое?
Posted by AlKon (Участник № / Member № 1919) on :
Да прописывается запрос на считывание данных, и результат считывания затирает исходную функцию. Что делать?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Вам выслан патч
Posted by Алекс К (Участник № / Member № 1337) on :
Релиз 6.06.03 Если в канале Call ChGroupReq Параметр 2, привязаному к R_FIFO_Queue, в аргументы USINT начиная c arg002 попадают значение больше 0x7f они становятся UINT (0x80 уже = 0xff80) из help 6.06.03
quote: Параметр<>0: расшифровка ответа
Номер первого байта данных в ответе контроллера при arg0<255 – 3, при arg0>255 – 4 (считая с 0).
Байты данных последовательно записываются в аргументы, следующие за arg0…arg3 (в зависимости от атрибута Параметр).
В аргумент SINT или USINT пишется 1 байт данных.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Мы перепроверили описанную Вами ситуацию на разных моделях. Воспроизвести не удалось. Уточните, пожалуйста, как Вы наблюдаете этот эффект. Можете ли Вы промоделировать эту ситуацию в отсутствие реальной связи с устройством? Пришлите нам проект с такой моделью.
Posted by Алекс К (Участник № / Member № 1337) on :
quote:Отправитель / Originally posted by AdAstra Technical Support: Уточните, пожалуйста, как Вы наблюдаете этот эффект.
например в проекте RS_UDEF приемные аргументы сделайте usint и пусть в них приходят значения 0x80. Посмотрите значения аргументов в Профайлере->Компоненты = 65408 (0x80 = 128).
При использоании UINT все нормально.
quote:Отправитель / Originally posted by AdAstra Technical Support: Можете ли Вы промоделировать эту ситуацию в отсутствие реальной связи с устройством?
com_slave'ом
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Следует уточнить формулировку: "В общем случае в аргумент SINT или USINT пишется 1 байт данных из полученного ответа в 2-байтовом формате." Мы введем уточнение в документацию.
Posted by Avgorr (Участник № / Member № 2607) on :
Канал CALL.ChGroupReq, Привязка удаленного канала Параметр=0. Подскажите, что-то никак не получается таким способом получить данные с MicroМРВ (WinCon) в МРВ. Делаю как написано: 1. В MicroМРВ создаю канал, привязываю его к CALL.ChGroupReq в МРВ. 2. В CALL.ChGroupReq создаю аргументы тип IN, REAL. 3. Привязываю к этим аргументам удалённые каналы (в MicroМРВ) - реальное значение. 4. В МРВ создаю экран, его аргументы привязываю к аргументам CALL.ChGroupReq. В результате ничего не получаю. Если можно пришлите пример. Спасибо.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
CALL.ChGroupReq в МРВ должен быть залинкован на удаленный канал в MicroМРВ. По тому, что Вы хотите получить, у канала CALL.ChGroupReq должен быть ПАРАМЕТР=5. И конечно между МРВ и MicroМРВ должна быть связь.
Posted by Avgorr (Участник № / Member № 2607) on :
С ПАРАМЕТР=5 всё получилось, но про ПАРАМЕТР=0 тоже интересно написано: "Параметр=0 – в аргументы INPUT канала ChGroupReq записываются реальные значения удаленных каналов (значение канала с ID=n записывается в аргумент с порядковым номером n)" - для чего тогда это можно использовать?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Это можно использовать для того, чтобы считать значения каналов с индексами от 0 до максимального номера аргумента. В силу того, что индексы каналов имеют сквозную нумерацию в проекте, практического применения эта настройка не имеет.
Posted by Avgorr (Участник № / Member № 2607) on :
Канал CALL.ChGroupReq, ПАРАМЕТР=5: 1. Аргументы передаются за один такт пересчета? Целесообразно ли использовать такой канал для уменьшения нагрузки на сеть (уменьшение трафика)? 2. Как потом эти принятые аргументы раскидать по каналам (так как некоторые параметры нужно архивировать)? Или есть способ сбрасывать в СПАД сразу аргументы CALL.ChGroupReq?
Posted by Алекс К (Участник № / Member № 1337) on :
quote:Отправитель / Originally posted by AdAstra Technical Support: Следует уточнить формулировку: "В общем случае в аргумент SINT или USINT пишется 1 байт данных из полученного ответа в 2-байтовом формате." Мы введем уточнение в документацию.
Один байт это от 0 до 255, а у Вас от 0 до 127! Если возвращаемое значение больше 127 (напрмер = 128 то уже в аргументе почему-то преобразуется в 65408). Это какой-то полубайт - полуслово получается!
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1. Нет, особой экономии трафика не будет. 2. Записывать аргументы в СПАД нельзя. Раскидать можно с помощью программы, например. -------------------------------------------------- SINT - это число от -128 до 127. 65408 - это и есть -128.
USINT - это число от 0 до 255.
Posted by Алекс К (Участник № / Member № 1337) on :
Так я же про USINT и говорю, понимаете? У вас аргументы CHGROUPREQ что USINT что SINT - до 127!!!
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Пришлите пример такой ситуации на hotline3@adastra.ru
Posted by Алекс К (Участник № / Member № 1337) on :
Выслал
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Да, действительно такая проблема есть. Обойти ее, не используя каналы, нельзя.
Posted by Avgorr (Участник № / Member № 2607) on :
Подскажите, если в МикроМРВ(WinCon) есть каналы, которые в МРВ будут проходить дальнейшую обработку (архивирование и т.п.), то напрашивается связь канал – канал, а если некоторые каналы в МикроМРВ(WinCon) необходимо только отображать или изменять на экране в МРВ (например, коэффициенты регулятора) - не очень хочется создавать дополнительные каналы в МРВ, то насколько оправдано будет применение CALL.ChGroupReq ПАРАМЕТР=5 и аргументы CALL.ChGroupReq привязывать сразу к аргументам экрана? Просто проект был сделан наспех, и получилось в информации о проекте использовано: 1669(4303) каналов. Теперь необходимо оптимизировать проект и хотелось бы это сделать правильно. Проект ещё и дальше будет развиваться.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Вполне оправдано.
1669(4303) - такое соотношение настораживает. Весьма вероятно, что значительная часть виртуальных каналов повторяются неоднократно.
Ваше предполагаемое решение может оказаться здесь эффективным.
Posted by Avgorr (Участник № / Member № 2607) on :
Проверял, виртуальные каналы не повторяются. Просто много удалённых обьектов и их каналы привязаны напрямую к аргументам экранов. И ещё: от релиза к релизу, некоторые каналы у Вас "отмирают", не будет ли это в дальнейшем с каналом CALL.ChGroupReq?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
От релиза к релизу каналы не "отмирают", а модифицируются, их функции расширяются. Морально устаревшие функции, которые эффективно заменяются новыми, не корректируются.
Надо удалить из проекта все лишние связи и все связи аргументов с "Источниками" (!), чтобы оптимизировать обмен.
Posted by Avgorr (Участник № / Member № 2607) on :
Если узел содержит канал CALL.ChGroupReq например ПАРАМЕТР=5, и аргументы его привязаны к каналам удалённого узла, то этот узел не возможно добавить в библиотеку. ТМ пишет: Привязанный объект не найден.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
В Пользовательской библиотеке компонентов сохраняются компоненты, не имеющие сложных межузловых связей. Указанный Вами компонент, по существу, является сплошной структурой межузловых связей. При импорте в библиотеку отследить и сохранить такие связи не представляется возможным. Придется на время импорта такие каналы исключать или модифицировать. Так или иначе, но при экспорте из библиотеки в проект такие компоненты надо будет конфигурировать заново.
Posted by Валерий Багин (Участник № / Member № 3467) on :
Уважаемая поддержка, данные читаются из контроллера через канал CHGroupReq. Аргументы типа Out привязаны к входному значению канала Input.
Не получается запись значения канала в контроллер через CHGroupReq, если это возможно объясните как. Канал делаю Output, аргументы Out, CHGroupReq привязываю к источнику Output.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Драйвер для OMRON не поддерживает групповую запись
Posted by Валерий Багин (Участник № / Member № 3467) on :
Понятно, теперь еще вопрос: У меня достоверность канала, привязанного к аргументу ChGroupReq не отображает отсутствия связи с контроллером, когда этот же канал привязываю к источнику, то все нормально.
Posted by Валерий Багин (Участник № / Member № 3467) on :
и в ОТ не заносятся строки при использовании границ...
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1. Если не аргумент ChGroupReq привязывать к числовому каналу, а числовой канал привязать к аргументу ChGroupReq, то числовой канал должен копировать и недостоверность ChGroupReq.
2. Если у канала FLOAT установлен флажок записи в ОТ, установлен флажок "Использовать границы", заданы корректно все границы и привязан "Словарь сообщений", то сообщения по этому каналу при пересечении границ должны поступать в ОТ. Если у Вас этого не происходит, присылайте проект для анализа.
Posted by Валерий Багин (Участник № / Member № 3467) on :
С ОТ разобрался, но достоверность не работает, проект отправил на hotline.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Была дана рекомендация в свойствах числового канала осуществить привязку к аргументу канала CALL. Вы в проекте привязку осуществили в самом аргументе канала CALL.
Мы выслали Вам подправленный проект.
Posted by Валерий Багин (Участник № / Member № 3467) on :
Спасибо, теперь все понятно.
Posted by Avgorr (Участник № / Member № 2607) on :
В релизе 6.07.7 каналы CALL.ChGroupReq, Параметр=5 как-то криво работают. А именно: Имею МРВ и порядка 30 МикроМРВ, данные с которых получал с помощью каналов CALL.ChGroupReq, Параметр=5. В релизе 6.07 всё работало хорошо. Сохранил проект в версии 6.07.7, запускаю МРВ 6.07.7 и у нескольких каналов некоторые аргументы равны нулю (значения удалённых каналов не передаются). Запускаю этот же проект в МРВ 6.07 - все данные есть. Перешёл обратно на релиз 6.07. Спасибо.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Это связано с числом опрашиваемых узлов?
Нужна дополнительная информация. Создайте в папке узла проекта МРВ cnf-файл с ключом DEBUG=400 и запустите проект в релизе 6.07.7. Вышлите log-файл и файл протокола профайлера для МРВ после запуска проекта с cnf-файлом на hotline3@adastra.ru. Вышлите также файл проекта с указанием, в какие аргументы не передаются значения.
