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, то как должен выкручиваться слэйв (это наверное можно рассматривать как три отдельных вопроса)?