Komantsev

Добрый день, Дмитрий, Инструкцию на NPort выслал. Но это инструкция по настройке, а не по работе с программными библиотеками. Возвращаясь к Вашей проблеме - по описанию сложно понять, где именно происходит сбой: в самом NPort или в программном обеспечении. Есть ли возможность попробовать опросить прибор не софтом, разработанным с участием библиотеки PComm, а через виртуальный COM-порт? Т.е. настроить NPort в режим Real COM Mode, установить драйвер виртуального COM-порта и исключить влияние софта собственной разработки. Изменится ли поведение системы?

Здравствуйте, Радик, Порт для протокола Modbus/TCP по умолчанию - 502. Если у Вас в сети Master находится со стороны TCP (т.е. MGate работает как TCP Slave), то к преобразователю MGate нужно обращаться только по порту 502. Если же Master находится со стороны RS-232/485 (т.е. MGate работает как TCP Master, опрашивая сетевые Modbus-контроллеры), то Вы можете указывать TCP-порт опрашиваемого устройства при настройке MGate во вкладке Slave ID Map.

Добрый день, Евгений, Благодарю Вас за отзыв! Да, действительно, проблемы были и с Вашей и с нашей стороны. Так получилось, что с Вашей стороны их удалось решить раньше. Насколько я знаю, помимо письма, был ещё телефонный звонок 12 мая. У нас действительно пока нет никаких существенных новостей, проблема сейчас решается в центре разработки. По поводу техподдержки - нам кажется, что такими, откровенно говоря, нестандартными и сложными случаями должен с нашей стороны заниматься один человек, детально вникающий во все особенности проблемы и следящий за проведением работ. Если Вам по каким-то причинам не удобно работать с этим человеком, то дайте знать, мы назначим другого специалиста, ответственного за решение Вашей проблемы. Действительно, Ваш случай - нестандартный. Как Вы признались, были проблемы и с Вашей стороны. Понимая, что текущая версия EDS SNMP OPC Server не в состоянии решить поставленную Вами задачу, мы стараемся делать всё возможное для решения проблемы, а также предлагаем выкупить у Вас товар обратно, если у Вас нет возможности ждать решения.

Здравствуйте, Николай, Это известная проблема, возникающая с ioLogik со старым Firmware. Попробуйте обновить Firmware при помощи утилиты ioAdmin. Последняя прошивка находится здесь. Пожалуйста, сообщите о результате.

Добрый день, Евгений, Совершенно искренне благодарю Вас за сообщение. Информация о совместимости очень важна для нас, для выработки дальнейших рекомендаций нашим клиентам по настройке и по использованию оборудования. Имея плотный ежедневный контакт с R&D-центром MOXA в Тайване, могу сказать, что разработчики очень адекватные. Если Вы являетесь автором предыдущих сообщений в этой ветке, то Ваша информация несомненно будет учтена в дальнейшем. К сожалению, мгновенно решить Вашу проблему не удалось. Если же с описанной сейчас проблемой Вы столкнулисьуже давно, то Вам надо было обратиться к нам сразу же. Возможно, Ваша проблема решилась бы оперативно. Как я писал ранее, задачи бывают разные, и "универсальных" эмуляторов COM-портов, без проблем работающих везде и всюду, не бывает. К сожалению, в Вашем случае UPort не подошел. В качестве контрпримера могу назвать такие уважаемые компании как SEW-Eurodrive или Инсат, которые, перепробовав преобразователи других марок и разочаровавшись в них, для решения своих задач выбрали именно UPort 1110. Вообще, преобразователи UPort 1110 "разлетаются" по России сотнями в месяц, а реальных проблем с их использованием - буквально единицы за год. Поэтому мы уверены в их надежности, но опять же, повторюсь, всегда готовы предоставить на бесплатное тестирование. Ещё раз благодарю за полезную информацию! Она обязательно будет принята к сведению.

Уважаемый Гость, Благодарю Вас за подробный и аргументированный отзыв :-) На самом деле, конвертер интерфейсов никогда не будет работать в точности так же, как и "родной" COM-порт. При работе с некоторыми системами, критичными ко времени обработки сообщений, могут возникать сбои. Причем сбои могут возникнуть как по вине конвертера, так и по вине разработчиков ПО из-за не всегда оптимального программного кода. В любом случае, перед принятием решения о приобретении, Вы всегда можете воспользоваться возможностью взять оборудование на тестирование.

Здравствуйте, Михаил, Большое спасибо за указание на существующую проблему. Мы сделаем всё возможное, чтобы защититься от спаммеров, чтобы работа с форумом была для Вас комфортна и не доставляла неудобств.

Сергей, В устройствах MOXA стоит UART, полностью совместимый со "стандартным" 16550. Так что все функции, работающие с родными COM-портами компьютера, будут работать и с портами MOXA. Вообще, 1.5 стоповых бита актуальны только при передаче 5 бит в посылке данных. В остальных случаях - используется 1 или 2 стоповых бита. Если Вы своей функцией откроете COM-порт с 5 битами данных и 2 стоповыми, то автоматически аппаратно будет выставлен режим 1.5 бита.

Алекс, Хочется понять, в чем заключается проблема, в самом COM-порте (проблемы с приемником/передатчиком) или в логике взаимодействия с модемом. Если к COM-порту ttyM0 подключить не модем, а другой COM-порт компьютера, то будет ли происходить передача данных между двумя COM-портами? Т.е. у Вашей платы обмена данными нет только с модемом или его нет в принципе? Если проблема наблюдается только с модемом, то уточните модель модема.

Добрый день, К сожалению, раньше с такой проблемой мы не сталкивались. Что значит "достучаться до модема невозможно"? Он не снимает трубку? А если попробовать открыть ttyM0 терминальной программой и передавать в последовательный порт данные? Нормально ли они передаются? Если посылать AT-команды модему вручную, будет ли модем отвечать?

Добрый день, Алекс, На самом деле, слишком большим параметр Force TX Timeout тоже ставить не следует. Этот таймаут должен быть не больше, чем пауза между посылками данных. В противном случае, две соседние посылки модуль NE может посчитать за один пакет данных. Тогда и задержка в передаче будет большой, и несколько посылок передадутся "склееными" в одну. Как показывает практика, время 10~20 мсек является оптимальным. Если это не помогает, попробуйте запротоколировать несколько сетевых обменов, осуществленных компьютером с модулем NE, при помощи бесплатной утилиты Wireshark и вышлите нам LOG-файл этого обмена. Попробуем разобраться, почему NE срабатывает так небыстро. По результатам наших тестирований, задержка при передаче через NE составляет порядка 10 мсек. Также пришлите нам файл конфигурации NE-модуля для анализа. Конфигурацию можно сохранить в файл при помощи утилиты NE Administrator в меню Configuration -> Export Configuration

Добрый день, На самом деле, какой-то стандартной раскладки по цветам кабелей в таких переходниках не существует. Поэтому подсказать по цветам я не смогу. Лучше прозванивайте получающийся кабель. Если делаете кабель с однотипными разъемами ("мама"-"мама" или "папа"-"папа"), то распайку см. во вложении. Если кабель нужен с разнотипными разъемами ("мама"-"папа"), то он делается "прямой": 1 --- 1 2 --- 2 ... 9 --- 9

Уважаемый Николай, Вряд ли имеют место быть проблемы с питанием. Если модули C32045T подключены через стандартный кабель C32020T, то этот кабель должен обеспечивать питание, необходимое для работы 32 COM-портов без применения внешнего адаптера. Уточните, пожалуйста, если пробовать работать с модемом без определения его в операционной системе (т.е., например, программой Hyper Terminal открыть один из COM-портов и попробовать отправить какие-либо AT-команды модему), будет ли модем адекватно реагировать? Или вообще никакой реакции от него не будет? Если будут проблемы с модемом, то попробуйте соединить два соседних COM-порта перекрёстным кабелем и попередавать данные. Будут ли они успешно передаваться? Вообще, по нашему опыту систему C320 часто используют именно для организации модемного пула. И проблем не возникает. Вполне возможно, что имеет место какой-то аппаратный дефект Вашего экземпляра.

Добрый день, Скорее всего, имеет место электрическая несовместимость сигналов RS-485 устройства MGate и подключаемого Вами устройства. Прежде всего, попробуйте изменить номиналы резисторов Pull Hi/Lo устройства MGate (т.е. замкнуть перемычки JP3 и JP4 на базовой плате устройства). Информация на этот счет - во вложении. MGate_Pull_Hi_Lo.pdf

Добрый день, Боюсь, что нет. Устройство MGate предназначено для преобразования протокола Modbus из формата RS-232/422/485 в формат Modbus/TCP. А если Вы будете передавать любой другой протокол, то данные передаваться просто не будут. Для "общего" преобразования RS-232/422/485 в Ethernet есть устройства NPort. Наиболее популярные модели - NPort 5110 (RS-232 в Ethernet) и NPort 5150 (RS-232/422/485 в Ethernet)

Добрый день, Вадим, Да, можно объединять несколько NPort-серверов через хаб (лучше - через коммутатор). Можно использовать как 200 штук 1-портовых NPort-серверов, так и многопортовые (есть модели с 1, 2, 4, 8, 16 и 32 портами). Многопортовые, конечно же, удобнее и дешевле (при подсчете стоимости одного порта), но если все 200 опрашиваемых Modbus-устройств территориально разнесены друг от друга, то многопортовые NPort'ы вряд ли удастся использовать. В любом случае, в одной сети можно без ограничений комбинировать различные модели. При одновременном опросе большого количества устройств надо обращать внимание на сетевой трафик. Так, трафик при передаче COM-порта через Ethernet будет примерно в 2 раза больше, чем скорость COM-порта. К примеру, если COM-порт работает на 9600 бит/сек, то при передаче через NPort сетевой трафик составит 9600 x 2 = 19200 бит/сек. А если взять 200 опрашиваемых устройств, то 19.2 Кбит/сек * 200 = 3840 Кбит/сек, т.е. примерно 4 Мбит/сек. Так что обычной сети в 100 Мбит/сек будет вполне достаточно. Даже если COM-порты работают на скорости 115.2 Кбит/сек, то требуемая пропускная способность сети будет 50 Мбит/сек. А если учесть, что вряд ли все 200 устройств будут беспрерывно передавать данные, то реальная загрузка сети будет меньше.

Добрый день, Ситуация понятна. Мне все-таки кажется, что дело не в физических параметрах порта, а в потере TCP-сокета вследствие каких-то сбоев в сети. Во вложении - пошаговое руководство по мониторингу и отладке соединения. Обратите внимание на раздел 2. В NPort Administrator, в разделе Port Monitor, параметр "Tx/RX after Conn". При пропадании связи в протоколе обмена регистрируются посылки в СК3-13. А будут ли они доходить до NPort'а при этом? Что покажет Port Monitor? Будет ли изменяться счетчик переданных и принятых байтов (Tx/RX after Conn)? NPort___мониторинг_и_отладка.pdf

Сделано!

Выслал Выслал Аналогично :-)

Честно говоря, не совсем понял вопрос. О каком приборе идет речь? По какому интерфейсу он работает?

Добрый день, Прежде всего, надо обратить внимание на то, что при использовании локальной сети IP-адрес компьютера и IP-адрес NPort'а должны быть из одной IP-сети. К примеру, если у NPort стоит IP-адрес по умолчанию (192.168.127.254, маска 255.255.255.0), то попробуйте переставить IP-адрес компьютера в ту же подсеть (например, сделать адрес компьютера 192.168.127.253 с той же маской 255.255.255.0) и повторить процедуры ping, telnet. В плане сетевого взаимодействия NPort является обычным сетевым устройством, никаких хитроестей в его работе нет. Поэтому, я думаю, по поводу настройки IP-параметров лучше проконсультироваться у системного администратора, который знаком с особенностями имеющейся у Вас сети. Уверен, проблем с настройками не возникнет.

Максим, Решить задачу можно двумя вариантами: сделать удаленный COM-порт компьютера по сети Ethernet; либо преобразовать Modbus/RTU в Modbus/TCP. Всё зависит от того, какой протокол понимает OPC-сервер. Бывает, что OPC-сервер умеет работать только с Modbus/RTU (по сети RS-485). В таком случае можно сделать удаленный COM-порт компьютера по сети Ethernet при помощи преобразователя NPort 5130. Если же OPC-сервер понимает протокол Modbus/TCP, то надо осуществлять конвертацию протокола из одной версии Modbus'а в другую. Это умеет делать MGate MB3180. Головной офис MOXA советует использовать серию MGate, т.к. она предназначена именно для трансляции протокола Modbus и делает конвертацию Модбаса быстрее, чем "универсальный" NPort. По настройкам преобразователя и компьютера - всё подскажем. В обоих случаях они несложные.

Подскажите, пожалуйста, как организован обмен данными через OPC-сервер и как именно пропадает связь? Главное, что меня интересует под "организацией обмена данными" - это механизм работы программы с COM-портом: 1) виртуальный COM-порт открывается единожды, а затем на протяжении многих дней идет обмен данными или 2) перед каждым обменом COM-порт открывается, производится обмен данными, и COM-порт закрывается. И какая выдается ошибка при потери связи? Невозможность открытия COM-порта, невозможность приема/передачи данных или что-то другое? Честно говоря, специалисты нашей компании с OPC-сервером Теплокома не работали. Поэтому Ваша информация значительно поможет нам в решении проблемы. Скорее всего, проблема возникает из-за каких-то сбоев сети. Все-таки, судя по Вашей диаграме, свзь идет через Интернет, а не локалку, поэтому со стабильностью передачи всё может быть не очень хорошо. Надо только понять, как лучше эту проблему обойти. Кстати, есть ли возможность в качестве эксперимента использовать не Интернет, а локальную сеть? При этом идеальный случай - соединение компьютера и NPort'а напрямую Ethernet-кабелем. Будут ли в таком случае возникать сбои?

Спасибо за сообщения! Будем использовать как наглядную агитацию :-)

Готово!