Форум TRACE MODE: техническая поддержка Послать новую тему / Post New Topic  Послать ответ / Post A Reply
мой профиль / my profile авторизация / login | регистрация / register | поиск / search | часто задаваемые вопросы / faq | начало / forum home

  Следующая старая тема / next oldest topic   Следующая новая тема / next newest topic
» Форум TRACE MODE: техническая поддержка » ОТКРЫТЫЕ ФОРУМЫ / OPEN FORUMS » TRACE MODE 6 бесплатная версия / TRACE MODE 6 Free version » ModBus TCP, атрибут [120]ACK

   
Автор / Author Тема / Topic: ModBus TCP, атрибут [120]ACK
voldemr
Junior Member / Новичок
Участник № / Member № 7872


Icon 1 отправлено / posted      Профиль для / Profile for voldemr           Редактировать/удалить сообщение / Edit/Delete Post   Вставить в ответ текст исходного сообщения  / Reply With Quote 
Здравствуйте.
Прошу пояснить механизм работы 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 Демо-версия.

Сообщения / Posts 14 | Из / From: РФ  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
Nico
Forum Professor / Завсегдатай форума
Участник № / Member № 5342


Icon 1 отправлено / posted      Профиль для / Profile for Nico           Редактировать/удалить сообщение / Edit/Delete Post   Вставить в ответ текст исходного сообщения  / Reply With Quote 
- 45 атрибут -> это время изменения значения, а не чтения
- если значение не будет прочитано из устройства, то возводится не достоверность

Сообщения / Posts 606 | Из / From: Россия  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
voldemr
Junior Member / Новичок
Участник № / Member № 7872


Icon 1 отправлено / posted      Профиль для / Profile for voldemr           Редактировать/удалить сообщение / Edit/Delete Post   Вставить в ответ текст исходного сообщения  / Reply With Quote 
Nico, спасибо за уточнение.
Да, 45 - время изменения, но сути вопроса не меняет.
Чтение происходит, достоверность (0 – _T), а атрибут ACK не взводится для последующих каналов в запросе.
Чем они такие особенные? По сути, каждый канал - самостоятельная единица в системе, а тут вылазят особенности.

Сообщения / Posts 14 | Из / From: РФ  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
AdAstra Technical Support
Moderator
Участник № / Member № 4


Icon 1 отправлено / posted      Профиль для / Profile for AdAstra Technical Support           Редактировать/удалить сообщение / Edit/Delete Post   Вставить в ответ текст исходного сообщения  / Reply With Quote 
Уточните, пожалуйста, что именно Вам необходимо знать по каждому опрашиваемому параметру:
- время изменения полученного значения,
- достоверность полученного значения,
- "После анализа и обработки данных" - что Вы имеете в виду, какой результат анализа и обработки, как он используется.

Сообщения / Posts 15724 | Из / From: Russia  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
voldemr
Junior Member / Новичок
Участник № / Member № 7872


Icon 1 отправлено / posted      Профиль для / Profile for voldemr           Редактировать/удалить сообщение / Edit/Delete Post   Вставить в ответ текст исходного сообщения  / Reply With Quote 
По каждому параметру необходимо знать, что данные успешно прочитаны.
Из документации ((120, ACK) – переменная DataReady, принимает значение 1, если запрошенные данные успешно считаны).
Насколько я понимаю, этот атрибут должен выставляться при успешном получении данных.
И не понимаю, почему значение этого атрибута зависит от местоположения регистра в групповом запросе Modbus.
Реализовываю следующую задачу:
Раз в минуту (или другой период времени) нужно опросить прибор.
Вычитать 4 регистра.
Помимо стандартного сохранения в СПАД, выводе на экране значений и графиков и т.п., нужно записывать данные в SQL по ODBC только успешно полученных данных.
Как вы мне советовали в топике по чтению OPC HDA, признак успешного чтения канала - анализ атрибута ACK.
В данной ситуации решил поступить аналогичным образом.
Если данные успешно считаны, записываю набор значений во внешнюю БД, сбрасываю ACK в "0" и далее по минутному периоду опроса каналов все повторяется.
Если данные не считаны, то во внешнюю БД ничего записывать не нужно.

Спасибо Nico за подсказку с достоверностью. Реализовал запись в БД через анализ достоверности.

Но из академического интереса:
1. вопрос по ACK остался. Почему не выставляется бит ACK для всех последующих каналов, источники данных которых находятся в одном запросе?
2. Возможно ли "отключить" автоматическую группировку регистров в один запрос?

Сообщения / Posts 14 | Из / From: РФ  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
AdAstra Technical Support
Moderator
Участник № / Member № 4


Icon 1 отправлено / posted      Профиль для / Profile for AdAstra Technical Support           Редактировать/удалить сообщение / Edit/Delete Post   Вставить в ответ текст исходного сообщения  / Reply With Quote 
1. ACK выставляется только 1 раз на транзакцию и только тому каналу, который эту транзакцию (в данном случае - групповую) осуществляет. Это канал, который привязан к регистру 300001.

2. В текущем релизе отключить групповой запрос как опцию нельзя.
Можно исключить наличие условий для формирования группового запроса: привязать регистры
300001, 300002, 300003, 300004 к каналам, ID которых идут в обратном порядке, например,
7, 6, 5, 4.
Но с точки зрения производительности канала связи это не рационально.

Сообщения / Posts 15724 | Из / From: Russia  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
voldemr
Junior Member / Новичок
Участник № / Member № 7872


Icon 1 отправлено / posted      Профиль для / Profile for voldemr           Редактировать/удалить сообщение / Edit/Delete Post   Вставить в ответ текст исходного сообщения  / Reply With Quote 
Спасибо за ответ.
Вопросы больше были для общего развития и понимания работы ТМ.

Сообщения / Posts 14 | Из / From: РФ  |  IP / IP: IP адрес / IP address | Report this post to a Moderator
   

Quick Reply
Сообщение / Message:

HTML код не разрешен. / HTML is not enabled.
UBB код разрешен. / UBB Code is enabled.

Значки Graemlins / Instant Graemlins
   


Послать новую тему / Post New Topic  Послать ответ / Post A Reply Закрыть тему / Close Topic   Feature Topic   Переместить топик / Move Topic   Удалить топик / Delete Topic Следующая старая тема / next oldest topic   Следующая новая тема / next newest topic
 - Printer-friendly view of this topic
Перейти к / Hop To


Новости АСУ ТП / News | SCADA / HMI | Обучение / Trainings | Свяжитесь с нами / Contact Us

Rambler's Top100 Rambler's Top100



Powered by Infopop Corporation
UBB.classic™ 6.7.2