8 800 775-57-90
Часто задаваемые вопросы по Modbus Universal Master OPC
1. В документации к прибору у меня указаны номера функций. Где они задаются в Modbus Universal MasterOPC?
В протоколе Modbus есть 4 основных региона памяти — Coils, Discrete Inputs, Holding Registers, Input Registers. Для того чтобы что-то прочитать или записать в эти регионы есть специальные функции, которые часто и указывают в документации к прибору. Ниже приводится таблица соответствия каждого региону определенной функции.
В протоколе Modbus есть 4 основных региона памяти — Coils, Discrete Inputs, Holding Registers, Input Registers. Для того чтобы что-то прочитать или записать в эти регионы есть специальные функции, которые часто и указывают в документации к прибору. Ниже приводится таблица соответствия каждого региону определенной функции.
Таким образом, если указано, что переменную необходимо читать функцией 0x03, то в ОРС сервере нужно установить регион Holding Registers.
Задание региона происходит на этапе создания тега:
Задание региона происходит на этапе создания тега:
После того как тег добавлен, изменить регион через свойства уже нельзя (тип добавленного тега выведен в верхней части вкладки панели свойств). Но остается возможность его изменения через групповые операции.
Holding Registers является наиболее распространенным регионом в Modbus устройствах. Следует помнить, что, несмотря на то что по стандарту в него возможно производить как чтение, так и запись, многие производители используют его и, например, только на чтение. В таком случае, чтобы случайно не записать в прибор значение (прибор на такой запрос, скорее всего, выдаст ошибку) можно установить у него тип доступа – Только чтение.
У регионов Coils и Holding Registers есть также возможность одиночной записи - по одному регистру за цикл записи, или групповой - несколько регистров за цикл записи. Чаще всего устройства поддерживают групповую запись, но иногда встречаются с поддержкой только одиночной. За выбор способа записи в ОРС сервере на уровне устройства есть две настройки "Не использовать команду Write_Single_Coils (0x05)" и "Не использовать команду Write_Single_Registers (0x06)" - по умолчанию они включены, и используется групповая запись. Выключение этих настроек выключает групповую запись и включает одиночную.
Holding Registers является наиболее распространенным регионом в Modbus устройствах. Следует помнить, что, несмотря на то что по стандарту в него возможно производить как чтение, так и запись, многие производители используют его и, например, только на чтение. В таком случае, чтобы случайно не записать в прибор значение (прибор на такой запрос, скорее всего, выдаст ошибку) можно установить у него тип доступа – Только чтение.
У регионов Coils и Holding Registers есть также возможность одиночной записи - по одному регистру за цикл записи, или групповой - несколько регистров за цикл записи. Чаще всего устройства поддерживают групповую запись, но иногда встречаются с поддержкой только одиночной. За выбор способа записи в ОРС сервере на уровне устройства есть две настройки "Не использовать команду Write_Single_Coils (0x05)" и "Не использовать команду Write_Single_Registers (0x06)" - по умолчанию они включены, и используется групповая запись. Выключение этих настроек выключает групповую запись и включает одиночную.
2. В документации к прибору к прибору номер регистра указан в шестнадцатеричной системе – как перевести его в десятичную?
Modbus Universal MasterOPC действительно работает с адресами в десятичной системе. Для простого перевода из HEX в DEC, нами реализована специальная функция – введите в поле адреса 0x а затем адрес в HEX формате, а затем нажмите Enter. Произойдет автоматический пересчет в десятичную систему. В поле адреса рядом будет также указываться и адрес в HEX.
Modbus Universal MasterOPC действительно работает с адресами в десятичной системе. Для простого перевода из HEX в DEC, нами реализована специальная функция – введите в поле адреса 0x а затем адрес в HEX формате, а затем нажмите Enter. Произойдет автоматический пересчет в десятичную систему. В поле адреса рядом будет также указываться и адрес в HEX.
3. В документации к прибору регистры указаны в формате 40001, при их опросе значения приходят некорректные.
Производитель устройства использует адресацию регистров в стандартном формате. Перевести ее к виду, требуемому в Modbus Universal MasterOPC очень просто. При стандартной адресации существует четыре области памяти:
1. По первой цифре стандартного адреса определить регион, к которому принадлежит данный регистр;
2. Убрать из стандартного адреса первую цифру и вычесть единицу.
Например, если стандартный адрес равен 40013, то в Modbus Universal MasterOPC, это будет тег региона Holding_Registers, а адрес регистра будет равен 12.
Производитель устройства использует адресацию регистров в стандартном формате. Перевести ее к виду, требуемому в Modbus Universal MasterOPC очень просто. При стандартной адресации существует четыре области памяти:
- Дискретные флаги (COILS): адреса 00001...09999, чтение функция 1, запись - функция 15;
- Дискретные входы (DISCRETE_INPUTS): адрес 10001...19999, чтение - функции 2;
- Входные регистры (INPUT_REGISTERS): адрес 30001...39999, чтение - функция 4;
- Хранимые регистры (HOLDING_REGISTERS): адрес 40001...49999, чтение - функция 3, запись - функция 16
1. По первой цифре стандартного адреса определить регион, к которому принадлежит данный регистр;
2. Убрать из стандартного адреса первую цифру и вычесть единицу.
Например, если стандартный адрес равен 40013, то в Modbus Universal MasterOPC, это будет тег региона Holding_Registers, а адрес регистра будет равен 12.
4. Тег типа Float (Double, Int32) имеет некорректное значение
Здесь проблема в неправильном чередовании байт. Представим себе, что устройство передает число 100, в переменный типа int16. Число 100 будет представлять собой два байта – 00 64. Мы можем принять старшим байтом вперед и получить 00 64 – 100, а может принять младшим байтом вперед и получить 64 00 – 25600. Аналогичная ситуация возникает и с Float, но только там байт уже не 2, а 4 (а у Double – 8). По стандарту применяется следующие настройки чередования:
Однако есть и исключения из правила. У всех контроллеров с Codesys 2, и для 2 байтовых (Word) и для 4 байтовых (Real) чередование байт – старшим байтом вперед.
Здесь проблема в неправильном чередовании байт. Представим себе, что устройство передает число 100, в переменный типа int16. Число 100 будет представлять собой два байта – 00 64. Мы можем принять старшим байтом вперед и получить 00 64 – 100, а может принять младшим байтом вперед и получить 64 00 – 25600. Аналогичная ситуация возникает и с Float, но только там байт уже не 2, а 4 (а у Double – 8). По стандарту применяется следующие настройки чередования:
- 2 байтовые числа (int16, uin16) – старшим байтом вперед.
- 4 байтовые числа (int32, uint32, float) – старшим словом вперед.
- 8 байтовые числа (double) – старшим двойным словом вперед.
Однако есть и исключения из правила. У всех контроллеров с Codesys 2, и для 2 байтовых (Word) и для 4 байтовых (Real) чередование байт – старшим байтом вперед.
5. С прибором нет связи или она не устойчивая (возникает признак качества BAD)
Здесь причин может быть очень много, но все необходимые средства диагностики в Modbus Universal MasterOPC есть. В режиме исполнения, у ОРС сервера есть вкладка Запросы. Выделите нужное устройство или узел и перейдите на эту вкладку. На этой вкладке находятся запросы и ответы.
Здесь причин может быть очень много, но все необходимые средства диагностики в Modbus Universal MasterOPC есть. В режиме исполнения, у ОРС сервера есть вкладка Запросы. Выделите нужное устройство или узел и перейдите на эту вкладку. На этой вкладке находятся запросы и ответы.
Также можно включить формирование лога в файл – если ошибка возникает эпизодически или необходим более глубокий анализ. Для включения ведения лога в файл в свойствах сервера включите запись журнала и всех его действий. Лог пишется в папку:
c:\ProgramData\InSAT\MasterOPC Universal Modbus Server\SERVERLOGS\
Запросы к устройству выделены синим и начинаются с Tx, ответы – зеленым и начинаются в Rx. При корректном запросе, на него следует ответ, а в окне сообщений выдается сообщение что опрос завершен. Если же запрос проходит с ошибкой, то возможны следующие варианты:
А. Запросов нет совсем. Это означает что не удается открыть порт – в этом случае информация выводится во вкладке сообщений. В случае с COM портов это можно означать, что он занят другой программой или вы указали неправильный порт. В случае TCP это означает что устройство не доступно (выполните его Ping) или вы указали неправильный порт или Modbus TCP Server на устройство не активен.
c:\ProgramData\InSAT\MasterOPC Universal Modbus Server\SERVERLOGS\
Запросы к устройству выделены синим и начинаются с Tx, ответы – зеленым и начинаются в Rx. При корректном запросе, на него следует ответ, а в окне сообщений выдается сообщение что опрос завершен. Если же запрос проходит с ошибкой, то возможны следующие варианты:
А. Запросов нет совсем. Это означает что не удается открыть порт – в этом случае информация выводится во вкладке сообщений. В случае с COM портов это можно означать, что он занят другой программой или вы указали неправильный порт. В случае TCP это означает что устройство не доступно (выполните его Ping) или вы указали неправильный порт или Modbus TCP Server на устройство не активен.
Б. Запросы есть, а ответов нет. По стандарту Modbus устройство отвечает только если обращаются к нему и запрос был корректен. Если устройство не отвечает, то причин может быть много – некорректное подключение (перепутаны провода A и B), некорректная скорость, четность, стоп-биты, адрес устройства. Возможно устройство настроено на другой протокол или вообще выключено.
В. Запросы есть, ответы тоже, но все равно выдается ошибка. Здесь возможны два варианта. Первый – устройство отвечает кодом ошибки. По стандарту, если устройство получило запрос, но не может его выполнить (например, запрашивается неподдерживаемая функция или некорректный адрес), то оно отвечает кодом ошибки. Код ошибки представляет собой сумму кода функции и числа 0x80, то есть при запросе функцией 0x03 в случае ошибки устройство вернет 0x83.
В этом случае нужно еще раз внимательно просмотреть документацию – возможно вы обращаетесь не по тем адресам. Также можно попробовать оставить в конфигурации только один проблемный тег и опросить его отдельно – дело в том, что многие приборы не поддерживают опрос большого количества регистров за один запрос, и возможно вы превысили это значение. В этом случае вам поможет настройка устройства в ОРС сервере – Максимальное количество регистров в запросе чтения.
Вторая причина – повреждение пакетов. Данная проблема часто возникает при опросе по Modbus RTU, так как конец кадра он определяет по «тишине» на шине. Поэтому если при передаче возникла задержка, сервер может воспринять это как конец кадра и попытаться разобрать принятый неполный кадр. Особенно актуальна данная проблема при работе по GSM и радиоканалам, но может возникать и в обычном RS-485 если устройство имеет медленный буфер и рвет пакет.
Данную ситуацию достаточно хорошо видно в логе – пакет как бы рвется на составные части. Пример текстового лога:
Вторая причина – повреждение пакетов. Данная проблема часто возникает при опросе по Modbus RTU, так как конец кадра он определяет по «тишине» на шине. Поэтому если при передаче возникла задержка, сервер может воспринять это как конец кадра и попытаться разобрать принятый неполный кадр. Особенно актуальна данная проблема при работе по GSM и радиоканалам, но может возникать и в обычном RS-485 если устройство имеет медленный буфер и рвет пакет.
Данную ситуацию достаточно хорошо видно в логе – пакет как бы рвется на составные части. Пример текстового лога:
[31.01.2017 10:16:45.934] TRACE : (COM13) Tx: [0008] 01 03 00 00 00 05 85 C9
[31.01.2017 10:16:46.096] TRACE : (COM13) Rx: [0015] 01 03 0A 00 0A 00
[31.01.2017 10:16:47.010] TRACE : (COM13) Tx: [0008] 01 03 00 00 00 05 85 C9
[31.01.2017 10:16:47.123] TRACE : (COM13) Rx: [0015] 14 00 1E 00 28 00 32 A7 C8
[31.01.2017 10:16:46.096] TRACE : (COM13) Rx: [0015] 01 03 0A 00 0A 00
[31.01.2017 10:16:47.010] TRACE : (COM13) Tx: [0008] 01 03 00 00 00 05 85 C9
[31.01.2017 10:16:47.123] TRACE : (COM13) Rx: [0015] 14 00 1E 00 28 00 32 A7 C8
То есть кадр ответа распался на две части - 01 03 0A 00 0A 00 и 14 00 1E 00 28 00 32 A7 C8.
Решить эту проблему также достаточно просто. Для этого в Modbus Universal MasterOPC у узла есть настройка Межсимвольный таймаут. По умолчанию данная настройка равно 0 (что считается равным 50 мс) – увеличивайте это значение. Можно начать с 300-500 мс, а затем вновь посмотреть на лог запросов. Если разрывы все еще наблюдаются – увеличивайте дальше. При работе по GSM межсимвольный таймаут может достигать 2000-3000 мс.
Решить эту проблему также достаточно просто. Для этого в Modbus Universal MasterOPC у узла есть настройка Межсимвольный таймаут. По умолчанию данная настройка равно 0 (что считается равным 50 мс) – увеличивайте это значение. Можно начать с 300-500 мс, а затем вновь посмотреть на лог запросов. Если разрывы все еще наблюдаются – увеличивайте дальше. При работе по GSM межсимвольный таймаут может достигать 2000-3000 мс.
Г. Когда в устройстве только 1 тег, то он опрашивается нормально, но когда их число увеличивается все теги переходят в BAD. Это происходит из-за того что в устройстве ограничено количество отдаваемых за один запрос регистров - такое ограничение характерно для простых приборов работающих по Modbus RTU. Чтобы решить проблему нужно задать в ОРС сервере количество запрашиваемых регистров:
Точное количество отдаваемых за один запрос регистров можно узнать из документации или подобрать вручную.
Д. Периодически возникает признак качества BAD. Здесь также нужно анализировать лог – возможно в какой-то момент устройство перестает отвечать или возникают задержки или помехи. Можно попробовать увечить количество повторных запросов и время ожидания ответа.
6. Опрос устройства есть, но спустя некоторое время опрос прекращает и помогает только перезагрузка сервера.
В этом случае, вы скорее всего, увидите в логе сообщений, что ОРС сервер не может открыть порт. Это происходит из-за зависания порта. Решить данную проблему можно включив в ОРС сервере на уровне устройства настройку «Реинициализация узла при ошибке» - в этом случае ОРС сервер закроет порт, а затем откроет его снова. Это может вывести его из зависания.
В этом случае, вы скорее всего, увидите в логе сообщений, что ОРС сервер не может открыть порт. Это происходит из-за зависания порта. Решить данную проблему можно включив в ОРС сервере на уровне устройства настройку «Реинициализация узла при ошибке» - в этом случае ОРС сервер закроет порт, а затем откроет его снова. Это может вывести его из зависания.
7. В процессе работы в тегах иногда появляются недостоверные значения.
Такая ситуация может возникать при работе по радио и GSM каналам по протоколу Modbus RTU и ASCII (при работе по Modbus TCP такая ситуация не возможна). Это происходит из-за «наслоения» ответов. В Modbus RTU нет специального поля, по которому можно было бы определить соответствие ответа определенному запросу (в Modbus TCP такое поле есть – Transaction ID). Представим ситуацию, ОРС сервер послал запрос в устройство, устройство ответило, но возникла задержка в сети (в GSM сетях это обычное явление), ОРС сервер не получил ответ и отправил запрос повторно, ему пришел ответ на предыдущий запрос – он корректен, ОРС сервер разобрал его и послал следующий запрос (следующего регистра), ему приходит ответ от предыдущего запрос – но в нем содержаться данные совершенно от других регистров! ОРС сервер производит анализ полученного ответа, например, если ОРС сервер запросил 2 регистра, а пришло 4, то такой запрос он отбросит. Если запрос пришел не от запрошенного устройства или с другой функцией, то этот запрос будет также отброшен. Но если запрос по структуре совпадает с предыдущим, сервер его примет и запишет значения в теги, которые будут некорректными. Избежать данной ситуации можно установив несколько настроек – включите реинициализацию узла при ошибке, а количество попыток установите равным 1. В этом случае, при первом же неудачном опросе сервер закроет порт, тем самым очистив буфер, а затем откроет его снова.
Такая ситуация может возникать при работе по радио и GSM каналам по протоколу Modbus RTU и ASCII (при работе по Modbus TCP такая ситуация не возможна). Это происходит из-за «наслоения» ответов. В Modbus RTU нет специального поля, по которому можно было бы определить соответствие ответа определенному запросу (в Modbus TCP такое поле есть – Transaction ID). Представим ситуацию, ОРС сервер послал запрос в устройство, устройство ответило, но возникла задержка в сети (в GSM сетях это обычное явление), ОРС сервер не получил ответ и отправил запрос повторно, ему пришел ответ на предыдущий запрос – он корректен, ОРС сервер разобрал его и послал следующий запрос (следующего регистра), ему приходит ответ от предыдущего запрос – но в нем содержаться данные совершенно от других регистров! ОРС сервер производит анализ полученного ответа, например, если ОРС сервер запросил 2 регистра, а пришло 4, то такой запрос он отбросит. Если запрос пришел не от запрошенного устройства или с другой функцией, то этот запрос будет также отброшен. Но если запрос по структуре совпадает с предыдущим, сервер его примет и запишет значения в теги, которые будут некорректными. Избежать данной ситуации можно установив несколько настроек – включите реинициализацию узла при ошибке, а количество попыток установите равным 1. В этом случае, при первом же неудачном опросе сервер закроет порт, тем самым очистив буфер, а затем откроет его снова.