отправлено / posted
Доброго времени суток. Прошу помощи в разъяснении мне следующих вопросов. Задача такова: есть GPRS-модем, который связан с микроконтроллером по UART. Этот модем при возникновении определенных событий включается и настраивается микроконтроллером, чтобы передать определенные данные с использованием Socket профиля и протокола TCP. Эти данные нужно принять на другом конце системы и выполнить с ними определенные действия, например, разобрать и отобразить. IP-адрес модема динамический и меняется всякий раз, когда он(модем) включается. У меня вот какой вопрос: 1. Можно ли с помощью ТМ настроить такого рода обмен и в общих чертах описать как это можно сделать?
отправлено / posted
Если этот контроллер не программируется Trace Mode 6, но имеет протокол, поддерживаемый в Trace Mode 6 (например, Modbus TCP), то обращение к нему может быть только при условии наличия статического IP-адреса. Если контроллер, WinPAC CE, программируется средствами Trace Mode 6, то динамические адреса GPRS-модемов контроллера не являются препятствием для обмена с МРВ 6.
Сообщения / Posts 17109 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Контроллер MSP430F1611 Texas Instrument, модем MutliTech MTSMC-E. Тогда можно ли, например слушать и собирать данные одной программой, которая слушает Socket, а отображать данные в ТМ?
Сообщения / Posts 95 | Из / From: Российская Федерация
| IP / IP: IP адрес / IP address |
отправлено / posted
А можно ли обойтись без написания драйвера. Например так, слушать Socket, передавать его на виртуальный COM-порт а с COM-порта данные забирать TM?
Сообщения / Posts 95 | Из / From: Российская Федерация
| IP / IP: IP адрес / IP address |
отправлено / posted
"Слушать Socket" и передавать на COM-порт будет какая-то Ваша программа. Но чтобы Trace Mode 6 забирал эти данные из COM-порта, нужен драйвер.
Сообщения / Posts 17109 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Но, если я не ошибаюсь в ТМ можно настроить COM-порт. Там же есть стандартный компонент.
Сообщения / Posts 95 | Из / From: Российская Федерация
| IP / IP: IP адрес / IP address |
отправлено / posted
Я пишу программу, которая слушает Socket и передает принятые данные на виртуальный COM-порт. В ТМ настраиваю этот виртуальный COM-порт и через него передаю данные в систему. Или я чего не правильно понимаю? Ведь те данные, которые пришли через COM-порт можно в ТМ программно обработать, разнести их на соответствующие переменные, привязать значения этих переменных к нужным мне каналам и эти каналы будут отображать то, что в них было передано.
Сообщения / Posts 95 | Из / From: Российская Федерация
| IP / IP: IP адрес / IP address |
отправлено / posted
Trace Mode 6 должен обращаться к COM-порту с каким-то протоколом. Если этот протокол поддерживается каким-то драйвером, уже существующим в Trace Mode 6, то можно подключиться через этот драйвер. Если такого драйвера нет, надо его написать.
Сообщения / Posts 17109 | Из / From: Россия
| IP / IP: IP адрес / IP address |
ilovefiniki
Forum Member / Участник форума
Участник № / Member № 4106
отправлено / posted
Пытаюсь настроить работу TM для обмена по modbus TCP. Но TM не получает ответ от удалённого устройства. Точнее получает, но не отрабатывает. Если заменить TM на тестовую программу для работы с сокетами, то все данные проходят в обе стороны без искажений. В случае с TM, на удалённом модеме (GPRS с стат. IP) запросы от TM появляются, ответ отсылается, но ничего не происходит. Формат команд правильный, проверял на прямом соединении контроллера с TM. TM всё чётко понимал. Есть такая догадка: ответ не успевает дойти. Всё таки GPRS как ни как. Экспериментально замечено, что TM отсылает сразу около 6 (точно не помню) одинаковых запросов modbus. Причём очень быстро, около 1 сек это занимает. И помойму отключается. Возможно ответ приходит уже после этого. Возможно ли такое? И как можно регулировать в TM эти таймауты? И количество попыток? В настройках в файле ip_modbus ничего подходящего не нашёл.
Сообщения / Posts 52 | Из / From: Беларусь
| IP / IP: IP адрес / IP address |
отправлено / posted
В файле ip_modbus есть параметр 100 RECTIMEOUT Он задает в миллисекундах таймаут ожидания ответа от устройства. Увеличивайте его до 2-3 тыс. или более.
Сообщения / Posts 17109 | Из / From: Россия
| IP / IP: IP адрес / IP address |
ilovefiniki
Forum Member / Участник форума
Участник № / Member № 4106
отправлено / posted
Попытался отредактировать файл 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?
Сообщения / Posts 52 | Из / From: Беларусь
| IP / IP: IP адрес / IP address |
ilovefiniki
Forum Member / Участник форума
Участник № / Member № 4106
отправлено / posted
Небольшая поправка, параметр TMDICONN добавляется и сохраняется. А вот CSC по прежнему нет. Причём не важно с какой цифрой. Также не добавляется 0 NONDBIDNT. Его тоже хотелось бы использовать, потому как ответ придётся посылать в формате обычного modbusRTU. т.е. с контрольной суммой и без префикса или с произвольным префиксом.
Сообщения / Posts 52 | Из / From: Беларусь
| IP / IP: IP адрес / IP address |
отправлено / posted
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. В протоколе профайлера будут даны все сообщения об ошибках по сетевому обмену. Проанализируйте из. Если положительного результата не будет, пришлите нам на адрес техподдержки проект и папку узла.
Сообщения / Posts 17109 | Из / From: Россия
| IP / IP: IP адрес / IP address |
ilovefiniki
Forum Member / Участник форума
Участник № / Member № 4106
отправлено / posted
Спасибо, буду тестить. Что касается п.1, то прямое соединение пробовал по modbusRTU через rs232, дело в том что контроллер поддерживает только RTU. А в нём есть CRC. И так уже слишком много функций пришлось перекинуть на программу в модеме. Не хочется делать чтоб модем помимо работы с gprs и TCP/IP стэком, ещё и CRC считал, формировал пакеты в нужном формате для modbusTCP и тп. А то ещё чуть-чуть и PLC контроллер вообще не нужен будет если GPIO входы/выходы в модеме задействовать .
Сообщения / Posts 52 | Из / From: Беларусь
| IP / IP: IP адрес / IP address |
ilovefiniki
Forum Member / Участник форума
Участник № / Member № 4106
отправлено / posted
Почитал мануал на 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 байт)?
Сообщения / Posts 52 | Из / From: Беларусь
| IP / IP: IP адрес / IP address |
ilovefiniki
Forum Member / Участник форума
Участник № / Member № 4106
отправлено / posted
И если добавить параметр CSC, то к пакету просто добавится в конце 2 байта контрольной суммы? Или TM и в ответе от контроллера тоже будет проверять контрольную сумму?
Сообщения / Posts 52 | Из / From: Беларусь
| IP / IP: IP адрес / IP address |
отправлено / posted
Очень хочется посмотреть точное содержание запросов от Trace Mode и ответов от контроллера. Пришлите протокол сниффера вместе с протоколом профайлера, проектом и папкой проекта.
Если прописать 0 NONDBIDNT, то в ответе не будет иметь значения только номер транзакции (1-й байт).
CRC от контроллера будет приниматься, но не будет проверяться? т.к. защита TCP-пакета вполне достаточна.
ilovefiniki
Forum Member / Участник форума
Участник № / Member № 4106
отправлено / posted
Попробовал поиграться с NONDBIDNT и CSC, но это ни к чему не привело. Во-первых, как прописывать в файле .cnf ключ NONDBIDNT. Как в 0 NONDBIDNT, NONDBIDNT=0 или просто NONDBIDNT. Потому как проверить экспериментально не особо возможно. Не работает и так и так. Во-вторых, CSC ни чего не дало. Пробовал в разных вариациях. И до запуска самой оболочки профайлера прописывал и непосредственно перед запуском проекта. CRC не появляется. ключ TIMEOUT поставил 3000, с ним всё нормально, по крайней мере сохраняется постоянно. Но 3 сек таймаута нет. Как слал приблизительно пакета 2-3 в секунду, так и шлёт. Единственное что, один раз таймаут действительно был 3 секунды. Но я так и не понял закономерности. Этот параметр поменял лишь один раз. Запускал проект раз 10 - таймаут маленький. Вдруг один раз запустил - был 3 сек таймаут. А потом опять все последующие разы таймаут как и был раньше. Вообщем теряюсь в догадках как ввести эти ключи?
Сообщения / Posts 52 | Из / From: Беларусь
| IP / IP: IP адрес / IP address |
ilovefiniki
Forum Member / Участник форума
Участник № / Member № 4106
отправлено / posted
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, размещенного на другом ПК. Никаких проблем при этом не возникает. Алгоритм реализации протокола не зависит от того, по каким физическим каналам осуществляется обмен.
Сообщения / Posts 17109 | Из / From: Россия
| IP / IP: IP адрес / IP address |
ilovefiniki
Forum Member / Участник форума
Участник № / Member № 4106
отправлено / posted
Так и не удалось заставить работать параметры NONDBIDNT и CSC. Единственное что заработало корректно - это TIMEOUT. Поэтому пришлось написать полноценный преобразователь modbusTCP-modbusRTU. В итоге удалённый модем выполняет все функции с контрольной суммой и номером транзакции. TM по прежнему требует ответ БЕЗ 2 байт с CRC и правильный номер транзакции в начале. Поэтому проблема как бы осталась, но для меня уже не актуальна. Проект действительно забыл отправить, но думаю уже не имеет смысла. Есть ещё вопросы , но это уже в другую ветку.
Сообщения / Posts 52 | Из / From: Беларусь
| IP / IP: IP адрес / IP address |
ilovefiniki
Forum Member / Участник форума
Участник № / Member № 4106
отправлено / posted
Вылезла такая вот непонятная проблема. Как я уже писал выше, мне надо было выставить таймауты заметно больше чем по умолчанию. Вроде как всё получилось. Но иногда TM вдруг ни с того ни с сего начинает беспрерывно отправлять пакеты, интервал между пакетами 200-300мс. Что никаким боком не похоже на выставленные несколько секунд. Причём отправляет он их до бесконечности. т.е. такое ощущение что в определённый момент TM забивает на все ключи в файле ip_modbus. Вроде как ключи выставлены так, что таймауты должны быть пару сек(разные варианты пробовал), и в случае получения ответа, и в случае отсутствия ответа от PLC. Количество попыток ставил 3, после чего канал должен выставить недостоверность и перестать слать пакеты. И всё хорошо работает до определённого момента. Может раз 10 обновить всё без проблем. Всё делать чётко как описано в файле ip_modbus. А в один прекрасный момент начинает работать с настройками по умолчанию. Как с этим быть? Возможно моё удалённое оборудование каким то образом работает некорректно, но по моему ключи в файле ip_modbus описывают все возможные ситуации обмена, хоть там ответ от PLC в формате modbus приходит, хоть полный бред не похожий на modbus и близко, таймауты и количество попыток в любом случае должны соблюдаться и не зависеть от удалённого устройства.
Сообщения / Posts 52 | Из / From: Беларусь
| IP / IP: IP адрес / IP address |
ilovefiniki
Forum Member / Участник форума
Участник № / Member № 4106
отправлено / posted
Ещё такую закономерность заметил. Если ставить таймауты 3 сек( TIMEOUT и RECTIMEOUT ), то выше описанная проблема возникает довольно редко, а если поставить 1 сек, то чуть ли не через раз. И в таком неправильном режиме TM работает пока не остановишь профайлер или не отключишь контроллер. т.е. пока приходят ответы от контроллера, TM работает в неправильном режиме. Ответы приходят неправильные, поскольку за 200-300 мс ответ по GPRS не успевает дойти и как только ответов нет(PLC выдернут из розетки), режим работы восстанавливается, таймауты 3 сек( или 1 сек), количество попыток ограничено до 3 и тп.
Сообщения / Posts 52 | Из / From: Беларусь
| IP / IP: IP адрес / IP address |
отправлено / posted
1. Задержка между транзакциями формируется только при получении правильного ответа на запрос. Поэтому параметр TIMEOUT надо выставлять только тогда. когда устройство действительно требует специальной задержки после отсылки ответа до приема следующего запроса или команды. Это бывает только в очень специальных случаях. Как правило, реальные устройства не требуют задержки между транзакциями. Искусственое введение такой задержки может привести к тому, что устройство будет посылать ответы на предыдущие запросы, которые будут восприниматься как ошибки.
2. Ответом считается получение нужного числа байтов за время, меньшее, чем RECTIMEOUT. Ответ анализируется на корректность. Если ответ некорректный (если, как написано выше, "приходит полный бред"), каналу выставляется НЕДОСТОВЕРНОСТЬ (не путать с недостоверностью, выставляемой по таймауту!). Далее БЕЗ ЗАДЕРЖКИ (даже если и задан TIMEOUT) формируются следующие транзакции.
3. Опыт реальных проектов показывает, что задержки по реальному каналу GPRS могут составлять более 10 сек. Поэтому правильнее не использовать TIMEOUT, но RECTIMEOUT задавать большим.
Сообщения / Posts 17109 | Из / From: Россия
| IP / IP: IP адрес / IP address |
ilovefiniki
Forum Member / Участник форума
Участник № / Member № 4106
отправлено / posted
Спасибо, буду пробовать, действительно както неправильно я таймауты настроил.
Сообщения / Posts 52 | Из / From: Беларусь
| IP / IP: IP адрес / IP address |
Printer-friendly view of this topic
![[Улыбка / Smile]](smile.gif)
.
