Pavel Urkaev

Добрый день, на днях решил проблему, однако забыл сразу сюда отписать... Причина была в самописном ПО для обмена данными с вычислителем ВКТ7, однако в неожиданном для меня месте - ведь в постановке проблемы, я гарантировал его работоспособность. Заранее благодарю всех, кто проявил интерес к нашей проблеме, особенно - Komantsev'а. Извиняюсь за потраченное вами время. Далее подобно описываю ситуацию, мало ли у кого то возникнет подобная проблема... Самописное ПО работало в следующей ситуации: имелся ВКТ7, подключенный через RS232 к GSM-модему, и на борту одной из машин в подсети организации имелся GSM-модем. Между модемами устанавливалось соединение в режиме передачи данных, через которое и производился необходимый обмен по протоколу MODBUS...Самописное ПО обращалось к GSM-Модему машины (а в после установления соединения - обменивалось данными с вычислителем ВКТ7) через COM-порт, к которому подведен GSM-Модем. В качестве программного интерфейса к COM-порту был задействован - класс .NET, представляющий ресурс последовательного порта (System.IO.Ports.SerialPort)...в данной ситуации проблем с обменом данными посредством этого программного интерфейса не было (ну кроме установления нужной кодировки порта)... Естественно, большая часть логики работы с COM-портом "перекочевала" в самописное ПО для обмена данными через указанную МОКСУ...однако, как говорится в постановке проблемы, в этом случае в ответе вычислителя были неожиданные данные, не похожие и близко на то, что ожидалось... Причина была в неосведомленности о тонкостях обмена данными через RS232 - для ресурса последовательного порта (System.IO.Ports.SerialPort), в нашем случае виртуальный COM-порт МОКСЫ, через который производится удаленное обращение к вычислителю ВКТ7, необходимо было выставить в ИСТИНУ 2 свойства (DtrEnable и RtsEnable), которые по умолчанию имеют значение - ЛОЖЬ. К этому решению пришли после прочтения базового материала о COM-порте (http://www.denvo.ru/pub/hardware/rs-232.html). Видно, что взаимодействие с вычислителем ВКТ7 через GSM-модем и непосредственно через RS232 (хоть и виртуальный) осуществляется с различными методами управления обменом данных.

Добрый День, приветствую сообщество Форума. Столкнулся с проблемой при использовании оборудования MOXA, прошу помощи по этому вопросу, возможно кто-то сталкивался с подобными ситуациями Имеется MOXA NPort 5250, установленная в режим Real COM Mode, к которой уже непосредственно через RS-232 подключен вычислитель VKT7 (с ним то и требуется осуществлять удаленный обмен данными). MOXA заведена в подсеть некоторой организации, а Я, находясь в другом городе, имею доступ к некоторым машинам этой подсети... На удаленном рабочем столе одной из этих машин создаю виртуальный COM порт, через который планирую осуществлять обмен данными с вычислителем VKT7. Разворачиваю на этой машине самописное ПО, которое обменивается данными с вычислителем VKT7 по протоколу MODBUS через данный COM порт (это ПО и сам вычислитель - РАБОЧИЕ) Проблема возникает в процессе самого обмена данными через виртуальный COM-порт - кадры запросов MODBUS успешно уходят через МОКСУ на вычислитель VKT7, но ответы приходят неожиданные ("0xFF", либо "0xFD", либо "0xFFFF", либо "0xFFFD"...), никак не похожие на кадры ответа MODBUS... Использовал утилиту NPort Administration Suit для создания виртуальных COM-портов и последующей отладки (при запуске самописного ПО для обмена данными с VKT7 на машине). MOXA успешно определяется, осуществляется ее мониторинг (живая), осуществляется мониторинг созданных виртуальных портов (успешное соединение с портом при запуске ПО, размер отправленных/принятых данных при обмене соответствует действительности). Виртуальный COM-порт настроен в соответствии с документацией на вычислитель VKT7 (биты данных. стоповые, четность, скорость...). Пробовал на разных машинах подсети организации - результат один и тот же (в ответ от вычислителя приходит БРЕД)... Помогите пожалуйста с этой проблемой, возможно какие то тонкте настройки или особенности???....