[andrewlekar 0]

Проектируем новую систему и закладываем туда магистраль для подключения всяких удалённых приборов. Очевидное решение - модбас по RS485. Однако модбас уже применяем в нынешнем устройстве и как-то не особо радует. Модбас RTU совсем не завёлся потому что требует точное соблюдение времени с микросекундной точностью и непрерывных фреймов. А модбас ASCII (используем сейчас) не особо эффективно использует шину.

Порекомендуйте, что делать? Оставлять модбас ASCII? Забарывать модбас RTU? Переехать на другой протокол? Как насчёт профибас?

[lisstret 0]

А на Ethernet пихнуть?

[andrewlekar 0]

Дороговато. И свитчей кучу ставить.

[kovigor 5]

Дороговато. И свитчей кучу ставить.

Зато все до предела стандартно, отработано, легко масштабируемо, и проч., и проч. А при покупке множества свитчей вам наверняка скидку сделают ...

 

[Гость MALLOY2]

CAN ?

[VCucumber 0]

CAN вместо RS485 хорошо подойдет, ethernet - плохо

[Lagman 1]

Проектируем новую систему и закладываем туда магистраль для подключения всяких удалённых приборов. Очевидное решение - модбас по RS485. Однако модбас уже применяем в нынешнем устройстве и как-то не особо радует. Модбас RTU совсем не завёлся потому что требует точное соблюдение времени с микросекундной точностью и непрерывных фреймов. А модбас ASCII (используем сейчас) не особо эффективно использует шину.

Порекомендуйте, что делать? Оставлять модбас ASCII? Забарывать модбас RTU? Переехать на другой протокол? Как насчёт профибас?

Зря вы так про modbus RTU, на самом деле там всего два тонких момента (я имею ввиду версию для последовательного порта RS), по версии "MODBUS over serial line specification and implementation guide V1.02" это то что во фрейме (посылке) не должно быть интервалов, между байтами, больше 1.5 char (времени отправки байта на вашей скорости) и следующий фрейм не должен идти раньше чем через 3,5 chara. Первый обычно без проблем реализуется через прерывание и выдачу буфера, а второе на таймере. Остальные времянки обговариваются/просчитываются и при скоростях больше 19200 не меняются (For baud rates greater than 19200 Bps, fixed values for the 2 timers should be used: it is recommended to use a value of 750μs for the inter-character time-out (t1.5) and a value of 1.750ms for inter-frame delay (t3.5).).

Но есть еще толстый момент, если вы (мастер) сделали запрос у слейва и есть ошибка (в передаче фрейма, в CRC или таймаут не выдержали) то в modbus нет подтверждения этих ошибок, и понять почему слейв не отвечает можно только с анализатором.

[andrewlekar 0]

То есть я правильно понимаю, что модбас RTU забарывается без запрета прерываний, с возможностью использования ртос, на обычном UART, мастер и слейв? Если так, то можно ещё пободаться с модбасом.

CAN - приятное решение, но на слейвах хочется использовать как можно более дешёвые cortex-m0 или PIC. Там CAN редок и дорог.

[MrYuran 21]

То есть я правильно понимаю, что модбас RTU забарывается без запрета прерываний, с возможностью использования ртос, на обычном UART, мастер и слейв?

Абсолютно.

msp430, 115200 Modbus RTU - без вопросов.

между байтами - 100мкс, вагон времени. Если ещё и очередь регулируемой глубины или DMA - вообще замечательно.

Причем RTU в обработке даже легче, чем ASCII, поскольку можно тупо кидать байты в буфер до возникновения тайм-аута, а потом обработать весь пакет.

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

[skyvmicro 0]

Зря вы так про modbus RTU, на самом деле там всего два тонких момента (я имею ввиду версию для последовательного порта RS), по версии "MODBUS over serial line specification and implementation guide V1.02" это то что во фрейме (посылке) не должно быть интервалов, между байтами, больше 1.5 char (времени отправки байта на вашей скорости) и следующий фрейм не должен идти раньше чем через 3,5 chara. Первый обычно без проблем реализуется через прерывание и выдачу буфера, а второе на таймере. Остальные времянки обговариваются/просчитываются и при скоростях больше 19200 не меняются (For baud rates greater than 19200 Bps, fixed values for the 2 timers should be used: it is recommended to use a value of 750μs for the inter-character time-out (t1.5) and a value of 1.750ms for inter-frame delay (t3.5).).

Но есть еще толстый момент, если вы (мастер) сделали запрос у слейва и есть ошибка (в передаче фрейма, в CRC или таймаут не выдержали) то в modbus нет подтверждения этих ошибок, и понять почему слейв не отвечает можно только с анализатором.

 

Если использовать свою систему (в качестве master) и свои удаленные устройства (в качестве slave), то для применения modbus RTU нет вообще никаких проблем.

Я не понимаю для чего в такой системе выдерживать временные интервалы с микросекундной точностью.

 

 

 

 

[_Pasha 0]

Вы все старательно обходите один вопрос: длина физ. линии. При CAN это может быть макс. 40метров.

[VCucumber 0]

Сделать звезду (хаб) на драйверах от CAN (или точнее по принципу) , между хабом и девайсами драйверы от rs422. Можно будет гонять и CAN и UART. Или еще что-нибудь. Про оптоволокно еще можно не забывать.