canOpen и сервис lss Опции

[dimanisu]

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

Я занимаюсь разработкой устройства, поддерживающего протокол canOpen и у меня возникли некоторые трудности реализации протоколов lss. Прочитал 305 стандарт - вроде ничего сложного. Но мне не понятен сам алгоритм работы slave при его конфигурации.
1. неясно каким образом он должен сообщить мастеру о неверном id (если он неверный)
2. непонятно, что за протокол должен задействовать мастер в этом случае.
и т.д.

Кто нибудь может привести хотя бы приближенный алгоритм работы слэйв устройства в этом режиме.
Т.е. что такого типа:
1. подали питание и перешли в состояние lssInit
2. Проверили id узла. Если invalid то Что то делаем ( что? ). Если valid - то переход в состояние nmtInit (дальше тут все ясно - идет норм работа)

В самом стандарте я не нашел подобном информации – только информация о том, какие протоколы бывают, но не в какой последовательности их использовать.


Заранее благодарен

[Fakir]

Если invalid то переходим в режим приема только тех пакетов у которых COBID = 0x07e5 (COBID в пакетах мастера)
т.е. принимаем только пакеты от мастера и обрабатываем их как написано в 305 стандарте(LSS)

1. неясно каким образом он должен сообщить мастеру о неверном id (если он неверный)

никак не сообщает, т.е. мастер сам должен первым начать домогаться по LSS.
вот цитата из стандарта:

If the Node-ID is invalid the slave remains in this "LSS Init" state in
LSS "Operation Mode" where only service requests by a LSS master can be executed.

[dimanisu]

Если invalid то переходим в режим приема только тех пакетов у которых COBID = 0x07e5 (COBID в пакетах мастера)
т.е. принимаем только пакеты от мастера и обрабатываем их как написано в 305 стандарте(LSS)

никак не сообщает, т.е. мастер сам должен первым начать домогаться по LSS.
вот цитата из стандарта:

Просто по вашему получается, что для реализации поддержки lss слэйвом, не нужно даже замарачиваться этими вещами, а тупо принимать запросы lss-мастера и отсылать соответствующие ответы? Я правильно понял?

Т.е. получается, что slave тупо сидит в своем LssInit и в сетку ничего не выстреливает (т.е. его сетевая активность = 0) ?

А как должен вести себя мастер в этом случае?:
Если я правильно понял, мастер при своем включении должен прогнать протокол LSS Identify Remote Slaves чтобы определить, все нормальные узлы.
Затем должен прогнать протокол LSS Identify Non-Configured Remote Slaves чтобы определить инвалидные. Или же достаточно одного LSS Identify Non-Configured Remote Slaves?
Так и здесь не все понятно - Мастер присылает cob (единичный чтоли? - п.5.6.3) c cs =79, а слэйв отвечает cob-ом с cs=76. Это вообще зачем делать - ведь мастер не поймет кто ему прислал это сообщение если в сетке сразу несколько инвалидов сидит?

Или же это делается для того, чтобы просто определить что в сети ЕСТЬ инвалиды ( и даже не важно сколько их)? Тогда какие дальнейшие действия мастера? Как найти инвалида?

Если мастер отрабатывает LSS Identify Remote Slaves - то как слэйв должен реагировать на таймауты между пакетами в этом протоколе (их там 6 с cs70- 75). Т.е., если предположим, что пришли пакеты с cs70 cs71, а пакет с cs пришел ну скажем через 5сек или пришел пакет с каким то другим cs или другим cob-id, то как должен выкручиваться слэйв (это наверное можно рассматривать как три отдельных вопроса)?

[Fakir]

Просто по вашему получается, что для реализации поддержки lss слэйвом, не нужно даже замарачиваться этими вещами, а тупо принимать запросы lss-мастера и отсылать соответствующие ответы? Я правильно понял? Т.е. получается, что slave тупо сидит в своем LssInit и в сетку ничего не выстреливает (т.е. его сетевая активность = 0) ?

ну да тупо сидит, вобщем-то логично, а что он еще должен посылать если у него ID не определен?

А как должен вести себя мастер в этом случае?:
Если я правильно понял, мастер при своем включении должен прогнать протокол LSS Identify Remote Slaves чтобы определить, все нормальные узлы.

LSS Identify Remote Slaves нужен просто чтобы определить какие узлы есть в сети, с выбором их по параметру, когда мастер делает LSS Identify Remote Slaves (п.5.6.1), то в параметрах обязательно указывается
cs=70 vendor-id
cs=71 product-code
cs=72 revision-number-low
cs=73 revision-number-high
cs=74 serial-number-low
cs=75 serial-number-high
все кто "попался на удочку" говорят LSS Identify Slave(п.5.6.2): COB-ID = 2020(cs =79), таким образом можно просто посчитать количество устройств с заданными параметрами.
В общем-то, мне кажется, мастеру не обязательно каждый раз при включении прогонять LSS Identify Remote Slaves.

Затем должен прогнать протокол LSS Identify Non-Configured Remote Slaves чтобы определить инвалидные. Или же достаточно одного LSS Identify Non-Configured Remote Slaves? Так и здесь не все понятно - Мастер присылает cob (единичный чтоли? - п.5.6.3) c cs =79, а слэйв отвечает cob-ом с cs=76. Это вообще зачем делать - ведь мастер не поймет кто ему прислал это сообщение если в сетке сразу несколько инвалидов сидит?

Да достаточно одного LSS Identify Non-Configured Remote Slaves , но опять же только чтобы определить количество инвалидов. LSS Identify Non-Configured Remote Slaves работает следующим образом: мастер посылает единичный COB-ID(0x07e5)cs =76, все слэйвы ивалиды(у которых Node-ID is not configured (FFh)) отвечают COB-ID = 0x07e4 cs =80.
Можно также запросить наличие в сети конкретных слэйвов с помощью команд п.5.5 Inquiry protocols

Или же это делается для того, чтобы просто определить что в сети ЕСТЬ инвалиды ( и даже не важно сколько их)? Тогда какие дальнейшие действия мастера? Как найти инвалида?

Инвалиды же знают свою печальную участь и сидят в "LSS Init" state in LSS "Operation Mode".
В "Operation Mode" возможны только Switch mode services это:
4.1.1 Switch mode global.(This service is used to switch all LSS Slaves in the network between operation mode and configuration mode.)
и Switch mode selective (This service is used to switch the LSS Slave, whose LSS address attribute equals LSS_address)
Если использовать Switch mode global, тогда все слэйвы перейдут в режим конфигурирования.
Если использовать Switch mode selective, тогда в режим конфигурирования перейдет только те слэйвы у которых параметры соответствуют запросу:
cs =64 vendor-id
cs =65 product-code
cs =66 revision-number
cs =67 serial-number
слэйвы при этом должны ответить cs =68 - типа я готов
Вот мастер и рулит как хочет, хочет сразу всех конфигурирует(например скорость сети), а хочет по одному(NODE-ID). Если мастер хочет с кем-то поработать, он сначала переводит клиента в configuration mode и потом обслуживает его по полной программе.