Ваши комментарии

текущим мобильным клиентом RTU поверхTCP не поддерживается. только обычный TCP.
задачу будем решать в самое ближайшее время.


А протокол - вы настраиваете RTU поверх TCP?

Здравствуйте.

1. Телефон вообще видит wifi точку, поднятую в rs-wifi преобразователе?
2. Не очень понятна предпоследняя картинка. Мобильный клиент работает, если подключен ПК?

Только если контроллер поддерживает каналы с плавающей точкой.

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

Data - симп анализирует карту заданных адресов и пытается группировать адреса для запроса одним пакетом. при этом при разрывах в карте адресов - формируется отдельный пакет. т.е. например, заданы адреса 1, 2, 5, 6 - будут сформированы 2 пакета для адресов 1, 2 и для 5, 6.

Full - то же что и Data, но разрывы в карте адресов могут быть включены в пакет (если программа решит что ей выгоднее спросить несколько "лишних" адресов, чем разбивать данные на несколько пакетов). т.е. для адресов 1, 2, 5, 6 будет сформирован один пакет. в нем также придут "лишние" данные - адреса 3 и 4. но их значения будут отброшены. По количеству передаваемых данных - это самый оптимальный вариант. Но он работает не на всех устройствах.

если устройство не поддерживает множественное чтение - то однозначно оптимизатор надо отключать (None).
если поддерживает - то Data или Full. это зависит от того, как обрабатывает запросы к несуществующим адресам само устройство. Есть устройства, которые при запросе несуществующих адресов возвращают ошибку. Например, заданы адреса 1, 2, 5, 6 - то любое чтение (даже множественное с 1 по 6) - возвратит ошибку. Для таких устройств подойдет только оптимизация Data. Ну или надо делать карту адресов без разрывов. Тогда подойдет Full, но работать будет точно так же как и Data.

Full может реально ускорить работу, если адреса заданы через 1. Тогда Data будет работать как None. На каждый адрес будет отдельный запрос. А Full - сгруппирует по возможности чтение. Но таких ситуаций следует избегать.

Побочный эффект множественного чтения - обновление данных может быть гораздо быстрее чем указано при настройке канала. Например адреса 1 и 3 настроены на 1 сек. а адрес 2 - на 2 сек. При групповом чтении все 3 адреса будут обновляться с частотой 1 сек. 
Это надо учитывать. И если это нежелательно - группировать адреса с одной частотой опроса близко друг к другу. 

мда... странный прибор.
в первом релизе точно формул не будет. дальше - возможно будут, а возможно нет.

В данный момент могу посоветовать только записывать значения с поменянными старшим и младшим байтом. Увы, но другого пути нет.

В вашем проекте на всех каналах стояли формулы на чтение. Не понял их назначение. Но с ними и в виндовом мониторе ничего не работало. После удаления формул - заработало и на винде и на андроиде. В качестве устройства использовал modbus эмулятр.
HMI в данный момент не поддерживает формулы ни на чтение ни на запись.

Немного по разному значения воспринимаются в мониторе и в мобильном hmi. Постараемся привести к одному виду.

Посмотрел ваш проект.
Настройки типа канала влияют только на внутренние расчеты. Для указания типа значений, считываемые с контроллера - надо настраивать сам Modbus драйвер. И типы данных в нем. 
По умолчанию - тип данных в modbus драйвере - Auto. это int16. Если вам нужны числа больше 32767 - то поставьте UInt16.
Разрыв соединения повторить не удалось.

пришлите, пожалуйста, проект на simp@simplight.ru



Сервис поддержки клиентов работает на платформе UserEcho