[khach 35]

Не путаюсь- хост- Винда с адаптером USB-RS485. Хоть самопрослушка и используется но получить точное время начала приема пакета невозможно. Самопрослушка видит, что "крикун" испортил пакет и начинается процедура переустановки связи. Слейвы- куча разных устройств начиная от Атмеля 2051 и кончая АРМами современными и не очень, например есть несколько ADuM. Фирмварь слейвов в основном самописная, но были и варианты со стороннним разработчиком.

14 hours ago, jcxz said:

И причём тут wireshark?

Вроде драйвер wireshark реализует более точный таймстамп пакетов чем оригинальный драйвер винды.

[artemkad 54]

5 часов назад, khach сказал:

Вроде драйвер wireshark реализует более точный таймстамп пакетов чем оригинальный драйвер винды.

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

[khach 35]

3 hours ago, artemkad said:

То что посылка развалена ты и так знаешь и более точное время  прихода разваленной посылки тут бесполезная информация.

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

зы. на многих слейвах логирование организовать невозможно- нет свободных ресурсов аппаратных.

[artemkad 54]

17 часов назад, khach сказал:

а например перед драйвером шины у подозрительного слейва-

Вроде как раз выше главная проблема и состояла в том, что слейвов много и который из них виновен неизвестно. Ну а если известен  - логический анализатор за 10$ в руки и все увидишь. 

[Сергей Борщ 121]

20 часов назад, khach сказал:

Была еще идея сделать направленный токовый датчик в разрыв линии для того чтобы определять с какой стороны от разрыва находится передатчик который шину перетягивает, но что то на тех скоростях что у нас шина работает такой направленный датчик работает нестабильно.

А если в разрыв одного из проводов RS485 воткнуть резистор, с обоих его выводов сигналы подать на компаратор, выход компаратора на тактовый вход регистра-защелки, на входы данных регистра - сигналы TxEN с драйверов RS485 подозреваемых, на выходы - светодиоды? В случае конфликта на шине через резистор будет течь ток, компаратор сработает и в какой бит регистра запишется 1 - тот ведомый и виновен. Регистр можно сделать сколь угодно длинным по необходимому количеству подозреваемых. Точность и скорость от компаратора особая не требуется - лишь бы за время половины бита переключиться успел. Можно сигналы шины и сигнал компаратора завести на лог. анализатор и по сигналу в канале компаратора очень быстро найти конфликт в записанном сигнале. Или на вход синхронизации осциллографа с разверткой в однократном режиме.

[khach 35]

15 hours ago, Сергей Борщ said:

А если в разрыв одного из проводов RS485 воткнуть резистор,

Пробовали, надо в оба провода втыкать резистор, иначе линии слегка перекашиваются и фронты парафазных сигналов разезжаются по времени. А вот с регистром хуже- вытянуть наружу сигналы TxEN и удлинить их чтобы до регистра или LA дотянуть физически- не такая уж простая задача- длина проводов и их паразитная емкость садит TxEN до полной неработоспособности системы. Надо буфера ставить на каждый TxEN.

Мы пробовали дифференциальный индуктивный детектор направления тока использовать по типу CAN crocodile,  тоже что то видит, но слишком много ложных срабатываний на фронтах ( короткие иголки). Надо фильтровать по длительности импульса. Оптимально при срабатывании детектора конфликтов надо бы захватить как посылку мастера, так и ответ слейва, чтобы понять что творится на шине. Впечатление такое, что слейв не дожидается конца посылки мастера и начинает сообщать об ошибке. Но сообщает не тот слейв, с которым мастер сейчас говорит а непонятно какой ( и не предидущий по адресации тоже).