Jump to content
Форум по продукции MOXA

Recommended Posts

Здравствуйте!
Использую Moxa NPort 5650-8, прошивка 3.6 Build 15041515. Драйвер NPort Real TTY для Linux (Linux 4.x.x) (версия 4.0 от 24.10.2019)
https://moxa.ru/files/drivers_utilities_3/real-tty-drivers-for-linux-4_x_x-driver-v4_0_2.tgz
Система Ubuntu 18.04.4 LTS x64, kernel 4.15.0-96.

Также использовал Ubuntu 16.04 и драйвер https://www.moxa.ru/files/drivers_utilities_2/npreal2_mainline_v1_19_build_17110917.tgz

Столкнулся с такой проблемой: во время обмена с устройством через Moxa стабильно происходит подвисание на 10 секунд с разной периодичностью. В ходе тестирования убедился, что проблема именно в драйвере. Я использую программу на Qt и библиотеку QSerialPort для работы с COM-портом. То же самое повторяется с библиотекой QExtSerialPort. Также без использования Qt, с системными библиотеками Linux.

В Windows подобных проблем не возникает. Если подключить порт Moxa из Windows к виртуальной машине на Linux - также всё работает без проблем.
Воспроизводится проблема в Linux следующем образом, даже без отправки и приёма данных по порту:
1. Программа в цикле открывает/закрывает порт Moxa /dev/ttyr00. Периодически закрытие порта будет подвисать на 10 секунд.
2. Программа открывает порт, затем в цикле устанавливает/снимает DTR. Периодически установка DTR будет подвисать на 10 секунд.
3. Программа открывает порт, затем в цикле устанавливает/снимает RTS. Периодически установка RTS будет подвисать на 10 секунд.
Иногда всё стабильно работает несколько сотен и даже тысяч циклов, но рано или поздно возникает подвисание.
У меня в программе, где нужно отправлять и получать несколько запросов в секунду - подвисания возникают гораздо чаще и в итоге всё сильно тормозит.

Link to comment

У меня получились такие результаты при тестировании.
1. Циклическое открытие/закрытие порта (rep - номер цикла, на котором возникла проблема. один цикл занимает меньше 100 мсек)

rep: 488
time : 10186 msec

rep: 1731
time : 10094 msec

rep: 2058
time : 10294 msec

rep: 2383
time : 10262 msec

rep: 2866
time : 10194 msec

rep: 3230
time : 10246 msec

rep: 4552
time : 10255 msec

rep: 4904
time : 10218 msec

rep: 5156
time : 10158 msec

rep: 5970
time : 10310 msec

rep: 7605
time : 10147 msec

rep: 7756
time : 10199 msec

rep: 9288
time : 10225 msec

rep: 10050
time : 10242 msec

rep: 10799
time : 10265 msec

rep: 10889
time : 10253 msec

rep: 11883
time : 10070 msec

rep: 13185
time : 10258 msec

rep: 15219
time : 30099 msec

rep: 19574
time : 10086 msec

rep: 19732
time : 10306 msec

rep: 20462
time : 10142 msec

rep: 20472
time : 10209 msec

rep: 20757
time : 10258 msec

rep: 20787
time : 10280 msec

rep: 21024
time : 10102 msec

rep: 21300
time : 10062 msec

rep: 21517
time : 10270 msec

rep: 28557
time : 30698 msec

rep: 30055
time : 31806 msec

2. Циклическая установка/снятие DTR, не закрывая порт.

rep: 18768
time : 10020 msec

rep: 21452
time : 10068 msec

rep: 48065
time : 10051 msec

rep: 59705
time : 10031 msec

rep: 64762
time : 10028 msec

rep: 111593
time : 10229 msec

rep: 120156
time : 10190 msec

rep: 142371
time : 10024 msec

rep: 142795
time : 10118 msec

rep: 176107
time : 10236 msec

rep: 244274
time : 10179 msec

rep: 257130
time : 10081 msec

rep: 299515
time : 10055 msec

rep: 304461
time : 10043 msec

3. Циклическая установка/снятие RTS, не закрывая порт.

begin
rep: 6201
time : 10065 msec

rep: 13387
time : 10008 msec

rep: 24559
time : 10146 msec

rep: 41982
time : 10076 msec

rep: 64287
time : 10060 msec

rep: 71755
time : 10155 msec

Link to comment

Добрый день! Попробуйте, для начала, обновить прошивку на NPort (последняя доступная версия 3.9, https://moxa.ru/files/drivers_utilities_3/nport-5600-series-firmware-v3_9.rom ), хотя навряд-ли это поможет. Что бы протестировать описываемый дефект соответственно потребуются и программы, которыми вы оперируете.

Link to comment

Хорошо, попробую новую прошивку.
У меня проблема воспроизводится с любой программой/библиотекой. Например, в Ubuntu есть графическая утилита CuteCOM. Если в ней нажимать октрыть/закрыть порт /dev/ttyr00, то также иногда возникают подвисания на 10 с. Но для этого нужно терпение )

Link to comment
1 час назад, Знайка сказал:

Добрый день! Попробуйте, для начала, обновить прошивку на NPort (последняя доступная версия 3.9, https://moxa.ru/files/drivers_utilities_3/nport-5600-series-firmware-v3_9.rom ), хотя навряд-ли это поможет. Что бы протестировать описываемый дефект соответственно потребуются и программы, которыми вы оперируете.

Перепрошил на 3.9. Не помогло.

Link to comment

Здрасте коллеги, оговорюсь сразу - ниже это мой опыт, статистика компании Moxa может отличаться. Мотивация к написанию поста - смотрю люди тоже мучаются с зависанием  npreal & nport 5xxx - для меня это пройденный этап - решение найдено, глюк мохи побежден.

Итого, имею три объекта, запускались в разные года 2016, 2017, 2019  на двух (года пуска: 2016, 2017) стоят по одной штуке MOXA NPort 6650-32 48V, а на третьем (2019) стоят 4 штуки MOXA NPort 5450I, чтобы набрать те же 32 порта. Если интересно,  используются в системах мониторинга (СТД-МПК) для съема телеметрии на станциях Салым Св.ж.д., Островной Св.жд. и Кинель Кб.ж.д. соответственно.

Возникшая проблема. - Там где стоят NPort-6000 серии все работает четко и нет проблем - порты не подвисают. А на 5000 серии зависают с рандомным интервалом от 5 минут до часа. Драйвер npreal один и тот же на всех трех объектах, и софт и хард для коммуникации с которым используются NPort так же одинаков. Питание всех четко по номиналу: 48V так 52V, 24V так 28V :). Т.е условия работы идентичны,

Перепрошивка одного NPort 5450 на последнюю на август 2019 года прошивку -  эффекта не принесла.

Симпомы болезни: прекращается опрос датчиков телеметрии, исследования показали, что провалившись в системный вызов tcdrain (tcdrain():  waits until all output written to the object referred to by fd has been transmitted) из него уже не возвращаемся никогда. Если учесть, что нужно подтверждение передачи всего буфера - проблема явно в драйвере, но это противоречит устойчиво работающим NPortам 6ххх серии. Вобщем, есть гемор, надо решать его, а не исследовать проблему в коммуникации ядерного модуля и удаленного девайса по tcp (вангую: проблема в tcp - udp на мой взгляд в режимах потоковой передачи данных лучше работает - т.к. потеря одного пакета не критична по сравнению с таймингами tcp).

Решение оказалось простое в моей архитектуре: на работу с каждым последовательным портом выделена отдельная нить (pthread), поэтому ее останов не влияет на работу системы в целом она прогрессирует хоть и менее эффективно.  Поэтому решение очевидно: отловить момент останова нити опроса модулей и закрыть и открыть порт.

Видимо вызову close плевать на подвисший tcdrain, а ядерный npreal в этом случае закрывает tcp соединение. А потом по новой open и пока снова не повисним.

В общем уже скоро будет год как этот костыль работает, и никто больше не помнит об этой проблеме. Акромя логов куда валяться варнинги о перезапуске опроса модулей телеметрии.

Если это вам поможет - значит не зря писал - всем удачи.

 

Link to comment
15 часов назад, boris_r_v сказал:

Здрасте коллеги, оговорюсь сразу - ниже это мой опыт, статистика компании Moxa может отличаться. Мотивация к написанию поста - смотрю люди тоже мучаются с зависанием  npreal & nport 5xxx - для меня это пройденный этап - решение найдено, глюк мохи побежден.

Итого, имею три объекта, запускались в разные года 2016, 2017, 2019  на двух (года пуска: 2016, 2017) стоят по одной штуке MOXA NPort 6650-32 48V, а на третьем (2019) стоят 4 штуки MOXA NPort 5450I, чтобы набрать те же 32 порта. Если интересно,  используются в системах мониторинга (СТД-МПК) для съема телеметрии на станциях Салым Св.ж.д., Островной Св.жд. и Кинель Кб.ж.д. соответственно.

Возникшая проблема. - Там где стоят NPort-6000 серии все работает четко и нет проблем - порты не подвисают. А на 5000 серии зависают с рандомным интервалом от 5 минут до часа. Драйвер npreal один и тот же на всех трех объектах, и софт и хард для коммуникации с которым используются NPort так же одинаков. Питание всех четко по номиналу: 48V так 52V, 24V так 28V :). Т.е условия работы идентичны,

Перепрошивка одного NPort 5450 на последнюю на август 2019 года прошивку -  эффекта не принесла.

Симпомы болезни: прекращается опрос датчиков телеметрии, исследования показали, что провалившись в системный вызов tcdrain (tcdrain():  waits until all output written to the object referred to by fd has been transmitted) из него уже не возвращаемся никогда. Если учесть, что нужно подтверждение передачи всего буфера - проблема явно в драйвере, но это противоречит устойчиво работающим NPortам 6ххх серии. Вобщем, есть гемор, надо решать его, а не исследовать проблему в коммуникации ядерного модуля и удаленного девайса по tcp (вангую: проблема в tcp - udp на мой взгляд в режимах потоковой передачи данных лучше работает - т.к. потеря одного пакета не критична по сравнению с таймингами tcp).

Решение оказалось простое в моей архитектуре: на работу с каждым последовательным портом выделена отдельная нить (pthread), поэтому ее останов не влияет на работу системы в целом она прогрессирует хоть и менее эффективно.  Поэтому решение очевидно: отловить момент останова нити опроса модулей и закрыть и открыть порт.

Видимо вызову close плевать на подвисший tcdrain, а ядерный npreal в этом случае закрывает tcp соединение. А потом по новой open и пока снова не повисним.

В общем уже скоро будет год как этот костыль работает, и никто больше не помнит об этой проблеме. Акромя логов куда валяться варнинги о перезапуске опроса модулей телеметрии.

Если это вам поможет - значит не зря писал - всем удачи.

 

Спасибо за подробный отзыв! Я был удивлён, когда нигде не нашёл информации по моей проблеме.

Дело точно в драйвере, не знаю почему в 6xxx серии такого нет - проверить нет возможности. Но драйвер под Windows работает без всяких проблем с NPort 5xxx серии.

У меня также отдельный поток на каждый порт. Но зависает он не насовсем, а на 10 секунд периодически. Т.е. драйвер не может обеспечить нормального быстродействия. Не думаю, что описанный вами костыль даст необходимое мне быстродействие - несколько запросов/ответов в секунду. Как я писал выше, у меня на 10 секунд подвисает в том числе операция закрытия порта.

Link to comment

Отсутствие информации легко объяснить тем, что подавляющее большинство скад написаны под винду и там другой драйвер.

 

Link to comment
  • 5 months later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...