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

[dimanisu]

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

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

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

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


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

[Fakir]

Да, все верно, dimanisu очень хорошее замечание,я честно говоря не знаю.
Наверное остается последовать совету CiA - подключать к мастеру одно устройство(в зависимости от ситуации) или стараться не допускать ситуаций, когда слэйвы будут отвечать одновременно одинаковыми пакетами.

[dimanisu]

Да, все верно, dimanisu очень хорошее замечание,я честно говоря не знаю.
Наверное остается последовать совету CiA - подключать к мастеру одно устройство(в зависимости от ситуации) или стараться не допускать ситуаций, когда слэйвы будут отвечать одновременно одинаковыми пакетами.

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

Fakir большое спасибо.