Стабильность работы преобразователя АС4-М

Здравствуйте.

В очередном проекте к компьютеру требуется подключить устройства по интерфейсу RS485 и я думаю как это будет лучше сделать:
купить PCI-E контроллер COM портов для компьютера и стабильно работающий АС3-М или только преобразователь АС4-М / АС4.

Для преобразователей АС4 раньше (года 2-4 назад) были свойственны произвольные зависания или потери/отпадания при работе под windows 7 и windows 10. То есть раз в несколько дней преобразователь произвольно "терялся" в системе и для продолжения его нормальной работы требовалось его переткнуть в USB порту или перезагрузить компьютер. Насколько свойственны такие проблемы для новых преобразователей АС4-М, а также удалось ли вылечить эту проблему у новых модификаций преобразователя АС4? Насколько стабильно работают преобразователи АС4-М и новые модификации (от 2017) АС4 при круглосуточной непрерывной эксплуатации?

Во, значит не у одного меня такая же фигня с зависаниями АС4 имеет место быть.

Но могу ответить на один вопрос: новые АС4 (выпущенные в 2017 году и позже) также склонные к зависаниям - у меня они иногда (раз в неделю/ежедневно/вообще не понятно по какому принципу) виснут и при работе под Owen Process Manager'ом, и под Телемеханикой Лайт, и под софтом от Тензо-М. Иногда виснут, намертво "завешивая" работающее с ними приложение, так что помогает только перезагрузка компа, иногда удается обойтись только убиением зависшего приложения и его перезапуском. Чаще это происходит на компьютере с Windows 2012 Server 64 bit, иногда (пока очень редко) - под Windows 7 32 bit.

Разработчики пока ничего вразумительного не сказали - только что AC4 не тестировались под Windows 2012 Server. Самое грустно, думаю что и не скажут, т.к. драйвера и сами чипы не их а от Silicon Labs.

В общем, пока как-то так. Самое для меня грустное, что по Windows 7 похоже та же фигня...

Так того, этого... Поставьте родные драйвера с сайта silab, перешив VID и PID микросхемы.

Там производитель где-то пишет, что изменение VID приводит к "окирпичеванию" АС4.

А вообще я нарыл ветку про АС4 - там народ с 2009 по 2017 год пишет о наличие подобных проблем. Рекомендации просты - переход на преобразователь RS-485<->USB другого производителя либо установка пары AC3-M с внешней платой с интерфейсами RS-232. За прошедшие 9 лет в части стабильности работы АС4 никаких особых подвижек похоже не произошло...слава производителю.

И как раньше я этой ветки не увидел, сразу бы не стал мучаться...

Уточните по новому АС4, вроде Овен одумался лепить свои VID_PID.
з.ы. а нельзя разве поколдовать с inf файлом драйверов и туда всунуть VID_PID овеновские, чтобы микросхему не шить ?

Не факт что это даст, овеновские драйвера все равно делаются на основе Silicon Labs. Корень зла скорее всего именно в их чипе/драйверах.
Сейчас вот ищу преобразователи от другого производителя чипов.

Цитата:

---

Сообщение от Svarog257

Во, значит не у одного меня такая же фигня с зависаниями АС4 имеет место быть.

---

Спасибо за ответ, а то от разработчиков как обычно ничего не услышишь. Значит ничего не изменилось. При таком зависании/отваливании, то что виснут приложения это нормально, обычно такое происходит при попытке закрыть виртуальный COM от отвалившегося преобразователя. Несколько лет назад, когда столкнулся с этой проблемой и копался пытаясь ее решить, была одна идея, которую я не проверил, возможно она вылечила бы проблему. Если вкратце, то я обратил внимание на то, что такие зависания преобразователя как-то чудным образом совпадают с запуском планировщиком заданий задачи с именем "UsbCeip". Есть подозрения, что если эту задачу заблокировать, то зависания и отвалы преобразователя могут прекратиться. В описании к UsbCeip, находящейся в планировщике заданий в ветке "Windows\Customer Experience Improvement Program", говорится следующее:

Цитата:

---

"При выполнении задачи программы улучшения качества ПО шины USB (USB CEIP) осуществляется сбор статистических данных об использовании универсальной последовательной шины USB и сведений о компьютере, которые направляются инженерной группе Майкрософт по вопросам подключения устройств в Windows. Полученные сведения используются для повышения надежности, стабильности и общей производительности шины USB в Windows. При отсутствии согласия пользователя на участие в программе улучшения программного обеспечения Windows задача не выполняет никаких действий."

---

Самое забавное, что задача включена у всех пользователей как windows 7 так и windows 10 и microsoft не особо интересуется, а хотят ли они участвовать в программе улучшения качества. Под windows 7 данная задача стартовала где-то раз в 3 дня, под windows 10 - условия ее запуска недоступны из штатного редактора.

Безумно интересно, попробую пошаманить. На компе с Windows Server 2012 нашел и уже отключил, на компе с Windows 7 она уже была отключена - а на нем и не было зависаний по меньшей мере c 29.08.2018, т.е. с момента установки и запуска на нем OPM.

А вообще-то не нашел я в широком доступе альтернативные варианты преобразователей RS-485->USB в промышленном исполнении на DIN-рейку. Всякие Болиды в виде "свистка" не утешают.

У меня в одном здании более 10 лет тогдашние АС-4 работают под одной ХР круглые сутки и практически постоянно качая данные. Что тогда было не так?
А переправить inf затруднительно по причине цифровой подписи, а так - генерилка текущего драйвера под любые VID/PID лежит на SiLabs. Поэтому - переливаются и не имею проблем.

Цитата:

---

Сообщение от ASo

У меня в одном здании более 10 лет тогдашние АС-4 работают под одной ХР круглые сутки и практически постоянно качая данные. .

---

Думаю проблемы начались после того, как АС4 стали ставить под Win7. У меня тоже три АС4 на компе с XP c 2009 года работали и вроде ничего не вешалось, проблемы начались когда тот комп сдох, а на новый поставили Win7 или Win2012S.

А насчет шаманства с драйверами спасибо, попробую сделать.

Цитата:

---

Сообщение от ASo

У меня в одном здании более 10 лет тогдашние АС-4 работают под одной ХР круглые сутки и практически постоянно качая данные. Что тогда было не так?
А переправить inf затруднительно по причине цифровой подписи, а так - генерилка текущего драйвера под любые VID/PID лежит на SiLabs. Поэтому - переливаются и не имею проблем.

---

Под XP и у нас древние AC4 тоже прекрасно работают, но то-ли потому что древние, то-ли потому что XP.

Цитата:

---

Сообщение от Svarog257

Безумно интересно, попробую пошаманить.

---

Еще можно зайти в настройки управления питанием и на всякий случай запретить всякие экономии на питании USB.

Давно сделано...не заметил что помогает.

Здравствуйте.

В старых образцах АС4 до 2017 года мы действительно меняли VID и PID микросхемы. Это вызывало некоторые трудности при эксплуатации.

В январе 2017 мы выпустили обновленный АС4 [М01] с микросхемой Silicon Labs CP2104 и оригинальными VID и PID. Драйвера также поставляются оригинальные Silicon Labs.

Аналогичная ситуация и с новым АС4-М - оригинальные VID и PID микросхемы CP2104: VID_10C4 PID_EA60.
Вложение 38748

Цитата:

---

Сообщение от Svarog257

Но могу ответить на один вопрос: новые АС4 (выпущенные в 2017 году и позже) также склонные к зависаниям - у меня они иногда (раз в неделю/ежедневно/вообще не понятно по какому принципу) виснут и при работе под Owen Process Manager'ом, и под Телемеханикой Лайт, и под софтом от Тензо-М. Иногда виснут, намертво "завешивая" работающее с ними приложение, так что помогает только перезагрузка компа, иногда удается обойтись только убиением зависшего приложения и его перезапуском. Чаще это происходит на компьютере с Windows 2012 Server 64 bit, иногда (пока очень редко) - под Windows 7 32 bit.

---

Сложно сказать в чем именно кроется проблема в вашем конкретном случае. Возможно, конфликт используемого по с какими-либо службами Windows 2012 Server.

Цитата:

---

Сложно сказать в чем именно кроется проблема в вашем конкретном случае. Возможно, конфликт используемого по с какими-либо службами Windows 2012 Server.

---

Спасибо, конечно, за конкретный и содержательный ответ.

P.S.
Реализовал схему с ежечасным перезапуском сервера сбора данных DAServer (заодно с OPC-сервером opc_ac3) при помощи штатного шедулера Windows 2012 Server как средства профилактики от подвисания каналов, связанных с модулями АС4 (известная и давняя проблема этих модулей при длительной работе на компах с Win7 и моложе).

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

Да и не поможет это в случае "мертвого" зависания драйвера модуля АС4, если не удастся "убить" процесс командой taskkill. Но пока ничего умнее в голову не приходит, разве что собрать комп на Windows XP и поднять все это на нем.

Цитата:

---

Сообщение от Svarog257

Но пока ничего умнее в голову не приходит, разве что собрать комп на Windows XP и поднять все это на нем.

---

Собрать на Малинке сервер для сбора данных, а ОПС данные забирать уже с него.