This is topic Передача данных по GPRS модему с использованием TCP in forum Общие вопросы / Common questions at Форум TRACE MODE: техническая поддержка.
Доброго времени суток. Прошу помощи в разъяснении мне следующих вопросов. Задача такова: есть GPRS-модем, который связан с микроконтроллером по UART. Этот модем при возникновении определенных событий включается и настраивается микроконтроллером, чтобы передать определенные данные с использованием Socket профиля и протокола TCP. Эти данные нужно принять на другом конце системы и выполнить с ними определенные действия, например, разобрать и отобразить. IP-адрес модема динамический и меняется всякий раз, когда он(модем) включается. У меня вот какой вопрос: 1. Можно ли с помощью ТМ настроить такого рода обмен и в общих чертах описать как это можно сделать?
Заранее спасибо. P.S.: Если написал не в тот TOPIC заранее извините.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Если этот контроллер не программируется Trace Mode 6, но имеет протокол, поддерживаемый в Trace Mode 6 (например, Modbus TCP), то обращение к нему может быть только при условии наличия статического IP-адреса. Если контроллер, WinPAC CE, программируется средствами Trace Mode 6, то динамические адреса GPRS-модемов контроллера не являются препятствием для обмена с МРВ 6.
Posted by Сидоров Александр Александрович (Участник № / Member № 3279) on :
Контроллер MSP430F1611 Texas Instrument, модем MutliTech MTSMC-E. Тогда можно ли, например слушать и собирать данные одной программой, которая слушает Socket, а отображать данные в ТМ?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Надо писать дополнительный драйвер.
Posted by Сидоров Александр Александрович (Участник № / Member № 3279) on :
А можно ли обойтись без написания драйвера. Например так, слушать Socket, передавать его на виртуальный COM-порт а с COM-порта данные забирать TM?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
"Слушать Socket" и передавать на COM-порт будет какая-то Ваша программа. Но чтобы Trace Mode 6 забирал эти данные из COM-порта, нужен драйвер.
Posted by Сидоров Александр Александрович (Участник № / Member № 3279) on :
Но, если я не ошибаюсь в ТМ можно настроить COM-порт. Там же есть стандартный компонент.
Posted by Сидоров Александр Александрович (Участник № / Member № 3279) on :
Я пишу программу, которая слушает Socket и передает принятые данные на виртуальный COM-порт. В ТМ настраиваю этот виртуальный COM-порт и через него передаю данные в систему. Или я чего не правильно понимаю? Ведь те данные, которые пришли через COM-порт можно в ТМ программно обработать, разнести их на соответствующие переменные, привязать значения этих переменных к нужным мне каналам и эти каналы будут отображать то, что в них было передано.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Trace Mode 6 должен обращаться к COM-порту с каким-то протоколом. Если этот протокол поддерживается каким-то драйвером, уже существующим в Trace Mode 6, то можно подключиться через этот драйвер. Если такого драйвера нет, надо его написать.
Posted by ilovefiniki (Участник № / Member № 4106) on :
Пытаюсь настроить работу TM для обмена по modbus TCP. Но TM не получает ответ от удалённого устройства. Точнее получает, но не отрабатывает. Если заменить TM на тестовую программу для работы с сокетами, то все данные проходят в обе стороны без искажений. В случае с TM, на удалённом модеме (GPRS с стат. IP) запросы от TM появляются, ответ отсылается, но ничего не происходит. Формат команд правильный, проверял на прямом соединении контроллера с TM. TM всё чётко понимал. Есть такая догадка: ответ не успевает дойти. Всё таки GPRS как ни как. Экспериментально замечено, что TM отсылает сразу около 6 (точно не помню) одинаковых запросов modbus. Причём очень быстро, около 1 сек это занимает. И помойму отключается. Возможно ответ приходит уже после этого. Возможно ли такое? И как можно регулировать в TM эти таймауты? И количество попыток? В настройках в файле ip_modbus ничего подходящего не нашёл.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
В файле ip_modbus есть параметр 100 RECTIMEOUT Он задает в миллисекундах таймаут ожидания ответа от устройства. Увеличивайте его до 2-3 тыс. или более.
Posted by ilovefiniki (Участник № / Member № 4106) on :
Попытался отредактировать файл ip_modbus. Параметр RECTIMEOUT изменил на 3000. Но запросы всё равно идут приблизительно с периодичностью 500 мс. И этот период совершенно не меняется от параметра RECTIMEOUT. Но это не самое главное. Основное это то, что в запросах modbus нет CRC. В файле ip_modbus у меня следующие поля: ;502 Port 3000 RECTIMEOUT 0 TIMEOUT 5 ERROR 0 OFFCOUNT 1 77.74.37.220
Изменить значение можно, а вот добавить новое поле из справки не получается. Очень надо добавить контрольную сумму. Нашел параметр CSC. Но после повторного сохранения проекта для MPB, все новые поля удаляются из ip_modbus. Перепробовал все возможные параметры для этого файла. Но кроме изначально сгенерированных MPB параметров в файле ip_modbus ничего не сохраняется. 1. Как добавить контрольную сумму в пакет modbus? 2. И как увеличить задержки между запросами modbus?
Posted by ilovefiniki (Участник № / Member № 4106) on :
Небольшая поправка, параметр TMDICONN добавляется и сохраняется. А вот CSC по прежнему нет. Причём не важно с какой цифрой. Также не добавляется 0 NONDBIDNT. Его тоже хотелось бы использовать, потому как ответ придётся посылать в формате обычного modbusRTU. т.е. с контрольной суммой и без префикса или с произвольным префиксом.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1. В первом посте Вы пишете: "Формат команд правильный, проверял на прямом соединении контроллера с TM. TM всё чётко понимал." "Прямое соединение" - тоже Modbus TCP? Если "да", то формат команды должен быть сохранен таким же, добавлять контрольную сумму не надо.
2. Если говорить о задержке между запросами, то это параметр TIMEOUT - в миллисекундах.
3. Ключ NONDBIDNT можно ввести в файл конфигурирования запуска МРВ TMcom_<ordinal>.cnf. Файл с параметром CSC придется каждый раз перезаписывать перед запуском узла.
4. Есть диагностические переменные @e_MODBUS и @e_TCP_ModBus, по которым можно получить информацию об ошибках обмена. Особенно обратите внимание на атрибуты канала, связанного с @e_TCP_ModBus.
5. Задайте в файле конфигурирования запуска МРВ TMcom_<ordinal>.cnf ключ DEBUG=400. В протоколе профайлера будут даны все сообщения об ошибках по сетевому обмену. Проанализируйте из. Если положительного результата не будет, пришлите нам на адрес техподдержки проект и папку узла.
Posted by ilovefiniki (Участник № / Member № 4106) on :
Спасибо, буду тестить. Что касается п.1, то прямое соединение пробовал по modbusRTU через rs232, дело в том что контроллер поддерживает только RTU. А в нём есть CRC. И так уже слишком много функций пришлось перекинуть на программу в модеме. Не хочется делать чтоб модем помимо работы с gprs и TCP/IP стэком, ещё и CRC считал, формировал пакеты в нужном формате для modbusTCP и тп. А то ещё чуть-чуть и PLC контроллер вообще не нужен будет если GPIO входы/выходы в модеме задействовать .
Posted by ilovefiniki (Участник № / Member № 4106) on :
Почитал мануал на modbusTCP и посмотрел сниффером что присылает TM. Так вот хотелось бы уточнить. А то может и нечего мудрить с NONDBIDNT и CSC. формат команд такой: Чтение запрос: 01 00 00 00 00 06 01 03 01 00 00 01 ответ: 01 00 00 00 00 05 xxxxxxx(не помню точно) Так вот. Если прописать 0 NONDBIDNT, то в ответе первые 6 байт не будут иметь значения? Я так понял. Или только номер транзакции (1 байт)?
Posted by ilovefiniki (Участник № / Member № 4106) on :
И если добавить параметр CSC, то к пакету просто добавится в конце 2 байта контрольной суммы? Или TM и в ответе от контроллера тоже будет проверять контрольную сумму?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Очень хочется посмотреть точное содержание запросов от Trace Mode и ответов от контроллера. Пришлите протокол сниффера вместе с протоколом профайлера, проектом и папкой проекта.
Если прописать 0 NONDBIDNT, то в ответе не будет иметь значения только номер транзакции (1-й байт).
CRC от контроллера будет приниматься, но не будет проверяться? т.к. защита TCP-пакета вполне достаточна.
Будем ждать результатов Вашего тестирования.
Posted by ilovefiniki (Участник № / Member № 4106) on :
Попробовал поиграться с NONDBIDNT и CSC, но это ни к чему не привело. Во-первых, как прописывать в файле .cnf ключ NONDBIDNT. Как в 0 NONDBIDNT, NONDBIDNT=0 или просто NONDBIDNT. Потому как проверить экспериментально не особо возможно. Не работает и так и так. Во-вторых, CSC ни чего не дало. Пробовал в разных вариациях. И до запуска самой оболочки профайлера прописывал и непосредственно перед запуском проекта. CRC не появляется. ключ TIMEOUT поставил 3000, с ним всё нормально, по крайней мере сохраняется постоянно. Но 3 сек таймаута нет. Как слал приблизительно пакета 2-3 в секунду, так и шлёт. Единственное что, один раз таймаут действительно был 3 секунды. Но я так и не понял закономерности. Этот параметр поменял лишь один раз. Запускал проект раз 10 - таймаут маленький. Вдруг один раз запустил - был 3 сек таймаут. А потом опять все последующие разы таймаут как и был раньше. Вообщем теряюсь в догадках как ввести эти ключи?
Posted by ilovefiniki (Участник № / Member № 4106) on :
Проект отправил на hotline@adastra.ru.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1. Файла проекта Вы не отправили.
2. Задание параметра CSC не означает, что МРВ будет формировать CRC. Это только означает, что он готов принять кадр с контрольной суммой. Контролироваться значение CRC не будет, но отсутствие CRC в кадре ответа будет восприниматься как ошибка. При этом каналу Modbus-запроса будет выставлен флаг НЕДОСТОВЕРНОСТЬ и в диагностических переменных Modbus и Modbus_TCP должны быть сообщения об ошибках.
3. В файле .cnf ключ задается "просто NONDBIDNT". Если этот ключ не работает, как в Вашем примере, то контроль транзакций осуществляется. И в ситуации 14:35:03> 06 00 00 00 00 06 01 03 07 D0 00 01 14:35:03> 07 00 00 00 00 06 01 03 07 D0 00 01 ->14:35:03 Пакет 3 отправлен > 01 00 00 00 00 05 01 03 02 00 01 14:35:04> 08 00 00 00 00 06 01 03 07 D0 00 01 14:35:04> 09 00 00 00 00 06 01 03 07 D0 00 01
Отправленный Вами пакет не будет принят МРВ.
4. В протоколе профайлера есть указание на установление коннекта, но нет ни одного сообщения об ошибках. Из этого можно было бы сделать вывод, что на запросы получаются корректные ответы. Но смоделировать Вашу ситуацию мы не можем, т.к. у нас нет модели того Modbus-Slave, который Вы используете.
5. Мы проверяем функционирование драйвера Modbus TCP с помощью эмулятора Modbus, размещенного на другом ПК. Никаких проблем при этом не возникает. Алгоритм реализации протокола не зависит от того, по каким физическим каналам осуществляется обмен.
Posted by ilovefiniki (Участник № / Member № 4106) on :
Так и не удалось заставить работать параметры NONDBIDNT и CSC. Единственное что заработало корректно - это TIMEOUT. Поэтому пришлось написать полноценный преобразователь modbusTCP-modbusRTU. В итоге удалённый модем выполняет все функции с контрольной суммой и номером транзакции. TM по прежнему требует ответ БЕЗ 2 байт с CRC и правильный номер транзакции в начале. Поэтому проблема как бы осталась, но для меня уже не актуальна. Проект действительно забыл отправить, но думаю уже не имеет смысла. Есть ещё вопросы , но это уже в другую ветку.
Posted by ilovefiniki (Участник № / Member № 4106) on :
Вылезла такая вот непонятная проблема. Как я уже писал выше, мне надо было выставить таймауты заметно больше чем по умолчанию. Вроде как всё получилось. Но иногда TM вдруг ни с того ни с сего начинает беспрерывно отправлять пакеты, интервал между пакетами 200-300мс. Что никаким боком не похоже на выставленные несколько секунд. Причём отправляет он их до бесконечности. т.е. такое ощущение что в определённый момент TM забивает на все ключи в файле ip_modbus. Вроде как ключи выставлены так, что таймауты должны быть пару сек(разные варианты пробовал), и в случае получения ответа, и в случае отсутствия ответа от PLC. Количество попыток ставил 3, после чего канал должен выставить недостоверность и перестать слать пакеты. И всё хорошо работает до определённого момента. Может раз 10 обновить всё без проблем. Всё делать чётко как описано в файле ip_modbus. А в один прекрасный момент начинает работать с настройками по умолчанию. Как с этим быть? Возможно моё удалённое оборудование каким то образом работает некорректно, но по моему ключи в файле ip_modbus описывают все возможные ситуации обмена, хоть там ответ от PLC в формате modbus приходит, хоть полный бред не похожий на modbus и близко, таймауты и количество попыток в любом случае должны соблюдаться и не зависеть от удалённого устройства.
Posted by ilovefiniki (Участник № / Member № 4106) on :
Ещё такую закономерность заметил. Если ставить таймауты 3 сек( TIMEOUT и RECTIMEOUT ), то выше описанная проблема возникает довольно редко, а если поставить 1 сек, то чуть ли не через раз. И в таком неправильном режиме TM работает пока не остановишь профайлер или не отключишь контроллер. т.е. пока приходят ответы от контроллера, TM работает в неправильном режиме. Ответы приходят неправильные, поскольку за 200-300 мс ответ по GPRS не успевает дойти и как только ответов нет(PLC выдернут из розетки), режим работы восстанавливается, таймауты 3 сек( или 1 сек), количество попыток ограничено до 3 и тп.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1. Задержка между транзакциями формируется только при получении правильного ответа на запрос. Поэтому параметр TIMEOUT надо выставлять только тогда. когда устройство действительно требует специальной задержки после отсылки ответа до приема следующего запроса или команды. Это бывает только в очень специальных случаях. Как правило, реальные устройства не требуют задержки между транзакциями. Искусственое введение такой задержки может привести к тому, что устройство будет посылать ответы на предыдущие запросы, которые будут восприниматься как ошибки.
2. Ответом считается получение нужного числа байтов за время, меньшее, чем RECTIMEOUT. Ответ анализируется на корректность. Если ответ некорректный (если, как написано выше, "приходит полный бред"), каналу выставляется НЕДОСТОВЕРНОСТЬ (не путать с недостоверностью, выставляемой по таймауту!). Далее БЕЗ ЗАДЕРЖКИ (даже если и задан TIMEOUT) формируются следующие транзакции.
3. Опыт реальных проектов показывает, что задержки по реальному каналу GPRS могут составлять более 10 сек. Поэтому правильнее не использовать TIMEOUT, но RECTIMEOUT задавать большим.
Posted by ilovefiniki (Участник № / Member № 4106) on :
Спасибо, буду пробовать, действительно както неправильно я таймауты настроил.
![[Улыбка / Smile]](smile.gif)
.