This is topic ModBus TCP, атрибут [120]ACK in forum TRACE MODE 6 бесплатная Базовая версия / TRACE MODE 6 free Base version at Форум TRACE MODE: техническая поддержка.
Здравствуйте. Прошу пояснить механизм работы ModBus TCP и найти решение проблемы.
Проведен эксперимент: Есть прибор (эмулятор) Slave Modbus TCP. Чтение 4-х регистров, идущих подряд. 300001, 300002, 300003, 300004. В источниках/приемниках завел 4 источника Rin_Word(4). Привязал к 4 каналам Float. Период каждого канала Float одинаковый.
Судя по логам, ТМ6 сам анализирует структуру регистров и объединяет функцию чтения регистра в один запрос. Логика в этом есть (экономия трафика и т.п.). Чтение идет, все хорошо, данные обновляются, время в атрибут [045]T записывается, но есть большое "НО": Атрибут [120]ACK при чтении выставляется в "1" только для 1-го канала Float (первый регистр в пакете запроса). Если чтение 4-х регистров "разнести" по времени, естественно групповой запрос уже не формируется и Атрибут [120]ACK выставляется в "1" для каждого канала Float.
Мне необходимо анализировать значение и время опроса каждого канала, независимо друг от друга. После анализа и обработки данных, я сбрасываю ACK в "0" и жду следующего обновления данных. Но получается, независимо это сделать не получится, т.к. ACK для всех последующих каналов в одном запросе не выставляются в "1".
Разносить по времени запросы тоже не очень хорошо, возрастает количество запросов и теряется "красота" единовременного чтения данных с одинаковым периодом.
PS: ТМ6.10 Демо-версия.
Posted by Nico (Участник № / Member № 5342) on :
- 45 атрибут -> это время изменения значения, а не чтения - если значение не будет прочитано из устройства, то возводится не достоверность
Posted by voldemr (Участник № / Member № 7872) on :
Nico, спасибо за уточнение. Да, 45 - время изменения, но сути вопроса не меняет. Чтение происходит, достоверность (0 – _T), а атрибут ACK не взводится для последующих каналов в запросе. Чем они такие особенные? По сути, каждый канал - самостоятельная единица в системе, а тут вылазят особенности.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Уточните, пожалуйста, что именно Вам необходимо знать по каждому опрашиваемому параметру: - время изменения полученного значения, - достоверность полученного значения, - "После анализа и обработки данных" - что Вы имеете в виду, какой результат анализа и обработки, как он используется.
Posted by voldemr (Участник № / Member № 7872) on :
По каждому параметру необходимо знать, что данные успешно прочитаны. Из документации ((120, ACK) – переменная DataReady, принимает значение 1, если запрошенные данные успешно считаны). Насколько я понимаю, этот атрибут должен выставляться при успешном получении данных. И не понимаю, почему значение этого атрибута зависит от местоположения регистра в групповом запросе Modbus. Реализовываю следующую задачу: Раз в минуту (или другой период времени) нужно опросить прибор. Вычитать 4 регистра. Помимо стандартного сохранения в СПАД, выводе на экране значений и графиков и т.п., нужно записывать данные в SQL по ODBC только успешно полученных данных. Как вы мне советовали в топике по чтению OPC HDA, признак успешного чтения канала - анализ атрибута ACK. В данной ситуации решил поступить аналогичным образом. Если данные успешно считаны, записываю набор значений во внешнюю БД, сбрасываю ACK в "0" и далее по минутному периоду опроса каналов все повторяется. Если данные не считаны, то во внешнюю БД ничего записывать не нужно.
Спасибо Nico за подсказку с достоверностью. Реализовал запись в БД через анализ достоверности.
Но из академического интереса: 1. вопрос по ACK остался. Почему не выставляется бит ACK для всех последующих каналов, источники данных которых находятся в одном запросе? 2. Возможно ли "отключить" автоматическую группировку регистров в один запрос?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1. ACK выставляется только 1 раз на транзакцию и только тому каналу, который эту транзакцию (в данном случае - групповую) осуществляет. Это канал, который привязан к регистру 300001.
2. В текущем релизе отключить групповой запрос как опцию нельзя. Можно исключить наличие условий для формирования группового запроса: привязать регистры 300001, 300002, 300003, 300004 к каналам, ID которых идут в обратном порядке, например, 7, 6, 5, 4. Но с точки зрения производительности канала связи это не рационально.
Posted by voldemr (Участник № / Member № 7872) on :
Спасибо за ответ. Вопросы больше были для общего развития и понимания работы ТМ.
