Прозрачное подключение устройств RS-485

У меня есть основной компьютер с платой RS-485. Он связывается со своими подсистемами через эту плату связи.
У меня также есть тестовый компьютер, подключенный к основной плате по каналу RS-485. Он будет использоваться для тестирования и обновления подсистем, использующих эти каналы RS-485.

Я хочу, чтобы основной компьютер вел себя прозрачно для тестового компьютера, чтобы главный компьютер не знал об алгоритме тестирования. Я не хочу обновлять основной компьютер при изменении алгоритмов тестирования.
Если бы я спроектировал свое оборудование, я бы использовал FPGA для физического подключения тестового компьютера к подсистемам, чтобы тестовый компьютер подключал подсистемы напрямую, а основной компьютер не знал о тестах, но я использую стандартный компьютер и связь карта.

Что бы вы сделали, чтобы соединить тестовый компьютер и подсистемы, не добавляя алгоритмы, связанные с тестированием, к основному компьютеру.

блок-схема

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

Ответы (1)

Ну, есть много возможных решений... но вы не дали достаточно информации о том, как выглядит связь между тестовым компьютером и подсистемами. Это полностью зависит от вас, что реализовать? Я собираюсь предположить, что это так, но решение, вероятно, изменится, если протокол через RS485 уже определен или выбран.

Большинство коммуникационных протоколов на этом уровне содержат какой-либо встроенный тип адресации .

Если вам удобно отправлять бинарные структуры, просто определите структуру, с которой начинается каждое сообщение и которая содержит:

  • Длина в байтах всего сообщения
  • Адрес подсистемы, с которой вы пытаетесь связаться
  • Адрес подсистемы, с которой вы говорите (необязательно)
  • Команда, которую вы пытаетесь передать подсистеме

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

В этот момент главному компьютеру ничего не нужно делать, кроме как прочитать заголовок сообщения, увидеть его длину и передать ее соответствующей подсистеме. Ему даже не нужно знать, где находятся адреса... вы можете просто передать сообщение всем трем подсистемам. По мере изменения команд и данных формат сообщения не меняется... так что логика главного компьютера может остаться прежней.

Ответ от подсистемы должен быть в том же формате.

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

Напоследок. Поскольку вы называете это «главным компьютером», я предполагаю, что вы говорите о настоящем ПК. С реальными ПК под управлением современной ОС, такой как Windows, OS / X или Linux, у вас будет задержка в том, насколько быстро приложение на этом компьютере может ответить ... поэтому встройте в свой протокол достаточно большие тайм-ауты. Многие последовательные протоколы представляют собой настоящую головную боль на современных ПК из-за жестких тайм-аутов, разрешенных для ответов, и т. д. Вероятно, вы не сможете передать MODBUS через современный ПК так, как вы описываете, например... по крайней мере, нет. без каких-либо специальных драйверов последовательных устройств или нарушения тайминга (что иногда нормально для фиксированных решений).

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