NPort 5650-8-DT-J

[Guest Олег]

Добрый день!

 

Локализовали след.проблему для "Firmware Version 1.0 Build 07032011"

 

При последовательном опросе ВСЕХ 8 портов преобразователя на примерно 130 цикле опроса моха перестает отвечать.

 

Данные в RS485 порт передаются, наш прибор их принимает и передает в моху, моха данные принимает, но не передает по TCP/IP каналу.

Протестированы скорости обмена 19200 и 38400, результат аналогичен.

 

Этот сбой в работе повторяется стабильно. При перезапуске компьютера обмен не восстанавливается. Помогает лишь рестарт мохы.

Восстанавливается обмен и без перезапуска/перезагрузки обмена с компьютера, но при рестарте мохы.

 

Последовательно выполняются след. обмены

 

В наш прибор на линии 1 посылается 15 байт, прибор отвечает 95 байтами.

В наш прибор на линии 2 посылается 15 байт, прибор отвечает 95 байтами.

В наш прибор на линии 3 посылается 15 байт, прибор отвечает 95 байтами.

В наш прибор на линии 4 посылается 15 байт, прибор отвечает 95 байтами.

В наш прибор на линии 5 посылается 15 байт, прибор отвечает 95 байтами.

В наш прибор на линии 6 посылается 15 байт, прибор отвечает 95 байтами.

В наш прибор на линии 7 посылается 15 байт, прибор отвечает 95 байтами.

В наш прибор на линии 8 посылается 15 байт, прибор отвечает 95 байтами.

 

и так далее в цикле. На 129-130 цикле получение данных от мохы прекращается.

 

При необходимости могу выслать лог обмена.

 

При исключении обмена по линии 8 (обмен по 7 портам) указанной проблемы нет.

 

Работа с мохой идет через moxattyd, ОС QNX4.25.

 

Что-то можно предпринять?

[Komantsev]

Добрый день!

 

Локализовали след.проблему для "Firmware Version 1.0 Build 07032011"

 

При последовательном опросе ВСЕХ 8 портов преобразователя на примерно 130 цикле опроса моха перестает отвечать.

 

Данные в RS485 порт передаются, наш прибор их принимает и передает в моху, моха данные принимает, но не передает по TCP/IP каналу.

Протестированы скорости обмена 19200 и 38400, результат аналогичен.

 

Этот сбой в работе повторяется стабильно. При перезапуске компьютера обмен не восстанавливается. Помогает лишь рестарт мохы.

Восстанавливается обмен и без перезапуска/перезагрузки обмена с компьютера, но при рестарте мохы.

 

Последовательно выполняются след. обмены

 

В наш прибор на линии 1 посылается 15 байт, прибор отвечает 95 байтами.

В наш прибор на линии 2 посылается 15 байт, прибор отвечает 95 байтами.

В наш прибор на линии 3 посылается 15 байт, прибор отвечает 95 байтами.

В наш прибор на линии 4 посылается 15 байт, прибор отвечает 95 байтами.

В наш прибор на линии 5 посылается 15 байт, прибор отвечает 95 байтами.

В наш прибор на линии 6 посылается 15 байт, прибор отвечает 95 байтами.

В наш прибор на линии 7 посылается 15 байт, прибор отвечает 95 байтами.

В наш прибор на линии 8 посылается 15 байт, прибор отвечает 95 байтами.

 

и так далее в цикле. На 129-130 цикле получение данных от мохы прекращается.

 

При необходимости могу выслать лог обмена.

 

При исключении обмена по линии 8 (обмен по 7 портам) указанной проблемы нет.

 

Работа с мохой идет через moxattyd, ОС QNX4.25.

 

Что-то можно предпринять?

Олег,

Попробуйте, прежде всего, обновить Firmware до версии 1.1 и, главное, установить последнюю версию драйвера (прикрепляю во вложении). В последней версии драйвера были модифицированы механизмы обмена данными именно для ОС QNX.

 

Если проблема не устранится, то дайте, пожалуйста, дополнительную информацию, которую NPort показывает на Web-консоли в разделе Monitor -> Async.

Уточните количества принятых/переданных данных, которые показывает NPort. При прекращении обмена данными:

- будет ли NPort показывать факт передачи данных на оконечное устройство?

- будет ли NPort показывать факт приема данных от устройства?

- или количество принятых/переданных данных вообще изменяться не будет (т.е. проблема чисто в драйвере)?

README.TXT

VERSION.TXT

moxattyd_3.2.13.tar

[Guest Олег]

Олег,

Попробуйте, прежде всего, обновить Firmware до версии 1.1 и, главное, установить последнюю версию драйвера (прикрепляю во вложении). В последней версии драйвера были модифицированы механизмы обмена данными именно для ОС QNX.

 

Если проблема не устранится, то дайте, пожалуйста, дополнительную информацию, которую NPort показывает на Web-консоли в разделе Monitor -> Async.

Уточните количества принятых/переданных данных, которые показывает NPort. При прекращении обмена данными:

- будет ли NPort показывать факт передачи данных на оконечное устройство?

- будет ли NPort показывать факт приема данных от устройства?

- или количество принятых/переданных данных вообще изменяться не будет (т.е. проблема чисто в драйвере)?

 

Заставить работать Nport 5650-8-DT-J не удалось, (в отчаяннии) нашли три NPort 5650-16, сконфигурировали по 8 портов,

проапгрейдили до Firmware Version 3.3 Build 08042219.

Установил присланный Вами драйвер moxattyd.

 

Результат тот же. Вот характерная для всех трех устройств статистика

 

Async

Port TxCnt RxCnt TxTotalCnt RxTotalCnt DSR CTS DCD

1 5404 13791 5404 13791 ON ON ON

2 5176 14142 5176 14142 ON ON ON

3 5176 14142 5176 14142 ON ON ON

4 5404 13791 5404 13791 ON ON ON

5 5396 13661 5396 13661 ON ON ON

6 5396 13661 5396 13661 ON ON ON

7 5396 13661 5396 13661 ON ON ON

8 5312 13590 5312 13590 ON ON ON

 

Где-то при RxCnt около 13000 обмен прекращается - нет ответа от мохы.

 

При этом в устройство поступают TCP/IP пакеты, передаются в RS485 порт, принимаются данные от наших приборов, но до moxattyd не доходят IP пакеты. Вроде бы моха живет, но не выдает пакеты наружу.

 

У нас конфигурация каждой мохы следующая

 

Alias Baud rate Data bits Stop bits Parity FIFO Flow ctrl Interface

Port 1 38400 8 1 None Enable None RS-485 2Wire

Port 2 38400 8 1 None Enable None RS-485 2Wire

Port 3 38400 8 1 None Enable None RS-485 2Wire

Port 4 38400 8 1 None Enable None RS-485 2Wire

Port 5 38400 8 1 None Enable None RS-485 2Wire

Port 6 38400 8 1 None Enable None RS-485 2Wire

Port 7 38400 8 1 None Enable None RS-485 2Wire

Port 8 38400 8 1 None Enable None RS-485 2Wire

 

Operating Settings

Port Operating mode Packing length Delimiter 1 Delimiter 2 Delimiter process Force transmit

1 Real COM Mode 0 0 (Disable) 0 (Disable) Do Nothing 0

TCP alive check time: 7

Max connection: 2

Ignore jammed IP: No

Allow driver control: No

2 Real COM Mode 0 0 (Disable) 0 (Disable) Do Nothing 0

TCP alive check time: 7

Max connection: 2

Ignore jammed IP: No

Allow driver control: No

3 Real COM Mode 0 0 (Disable) 0 (Disable) Do Nothing 0

TCP alive check time: 7

Max connection: 2

Ignore jammed IP: No

Allow driver control: No

4 Real COM Mode 0 0 (Disable) 0 (Disable) Do Nothing 0

TCP alive check time: 7

Max connection: 2

Ignore jammed IP: No

Allow driver control: No

5 Real COM Mode 0 0 (Disable) 0 (Disable) Do Nothing 0

TCP alive check time: 7

Max connection: 2

Ignore jammed IP: No

Allow driver control: No

6 Real COM Mode 0 0 (Disable) 0 (Disable) Do Nothing 0

TCP alive check time: 7

Max connection: 2

Ignore jammed IP: No

Allow driver control: No

7 Real COM Mode 0 0 (Disable) 0 (Disable) Do Nothing 0

TCP alive check time: 7

Max connection: 2

Ignore jammed IP: No

Allow driver control: No

8 Real COM Mode 0 0 (Disable) 0 (Disable) Do Nothing 0

TCP alive check time: 7

Max connection: 2

Ignore jammed IP: No

Allow driver control: No

9 Disabled

 

Что-то еще можете посоветовать?

 

Могу завтра позвонить в офис, обсудить. ОК?

[Guest Олег]

Добавлю еще следующее:

 

1. Рестарт программ, драйверов, TCP/IP прог, полный рестарь компьютера не помогает.

2. После рестарта мохы обмен начинается и идет какое-то время. Рестарта ПО компьютера выполнять не надо.

 

У нас QNX4.25, TCP/IP Version 4.25.

 

Параллельно (для трех мох) выполняется поочередной опрос 8 портов на каждой мохе.

[Guest Олег]

И еще:

 

У нас два ПК - основной и резервный.

Опрашивает только основной ПК.

Резервный полностью готов к работе (запущена в том числе и moxattyd), но на нем не выдаются запросы на обмен с мохами.

При просмотре Monitor/Line видно, что для мохы оба компьютера активны.

 

При убитии moxattyd на резервном компьютере на мохе состояние линии для IP2 перешло в listen и обмен на основном ПК возобновился.

 

Возможно, что-то с обработкой нескольких соединений в мохе?

[Komantsev]

И еще:

 

У нас два ПК - основной и резервный.

Опрашивает только основной ПК.

Резервный полностью готов к работе (запущена в том числе и moxattyd), но на нем не выдаются запросы на обмен с мохами.

При просмотре Monitor/Line видно, что для мохы оба компьютера активны.

 

При убитии moxattyd на резервном компьютере на мохе состояние линии для IP2 перешло в listen и обмен на основном ПК возобновился.

 

Возможно, что-то с обработкой нескольких соединений в мохе?

Олег, два ПК - это существенное дополнение.

Возвращаясь к настройкам режима работы портов NPort-сервера:

Operating Settings

Port Operating mode Packing length Delimiter 1 Delimiter 2 Delimiter process Force transmit

1 Real COM Mode 0 0 (Disable) 0 (Disable) Do Nothing 0

TCP alive check time: 7

Max connection: 2

Ignore jammed IP: No

Allow driver control: No

Попробуйте поставить Ignore jammed IP в значение Yes. Суть этого параметра при одновременном подключении нескольких ПК такова:

• No: если хоть на один из принимающих компьютеров нельзя доставить данные, то данные не будут переданы никуда
  
• Yes: сбой одного компьютера никак не скажется на передаче данных остальным ПК
  

[Guest Олег]

Олег, два ПК - это существенное дополнение.

Возвращаясь к настройкам режима работы портов NPort-сервера:

 

Попробуйте поставить Ignore jammed IP в значение Yes. Суть этого параметра при одновременном подключении нескольких ПК такова:

• No: если хоть на один из принимающих компьютеров нельзя доставить данные, то данные не будут переданы никуда
  
• Yes: сбой одного компьютера никак не скажется на передаче данных остальным ПК
  

 

Спасибо за информацию!

 

Целиком согласен с Вами, что 2 ПК - это существенное дополнение!!!

 

Ситуация оказалась следующая:

 

1. При запросе из одного компьютера ответ приходит на оба. Для Real Comm режима это свойство, увы, не сумел найти в тексте мануала, для TCP Server'а явно указано в документации.

 

2. Предоставляемый драйвер moxattyd принимает всю приходящую к нему информацию (т.е. оба компьютере). На главном ПК это информация обрабатывается, не резервном данные нашим ПО не обрабатываются (работа ПО в режиме запрос-ответ). В результате через какое-то время (величина порядка длины буфера в QNX4.25 - в нашем случае около 18Кб данных) системный буфер ОС переполняется и процесс обмена с обоими ПК приостанавливается. Сюда по описанию, установка Ignore jammed IP в Yes должна помочь в этой ситуации.

 

3. Написал простенькую программку по периодической очистке буфера Dev.pty на резервной машине - ситуация несколько улучшилась, системный буфер перестал переполняться и обмен наладился.

 

4. Модифицировал код moxattyd так, чтобы ответ от мохы передавался только в том случае, если до этого был запрос на обмен. Не совсем правильно, но сработало. Однако при отключении одной из 4х мох начался постоянный рестарт moxattyd с попытками соединиться с отключенным устройством и сделанная модификация кода оказалась некорректной. Буду дальше .... )))

 

Как я теперь понимаю, изначально надо бы использовать мохы 6000й серии, с которыми можно работать в режиме запрос-ответ.