[dimanisu 0]

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

 

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

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

2. непонятно, что за протокол должен задействовать мастер в этом случае.

и т.д.

 

Кто нибудь может привести хотя бы приближенный алгоритм работы слэйв устройства в этом режиме.

Т.е. что такого типа:

1. подали питание и перешли в состояние lssInit

2. Проверили id узла. Если invalid то Что то делаем ( что? :07: ). Если valid - то переход в состояние nmtInit (дальше тут все ясно - идет норм работа)

 

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

 

 

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

[Fakir 0]

Если 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 0]

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

т.е. принимаем только пакеты от мастера и обрабатываем их как написано в 305 стандарте(LSS)

 

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

вот цитата из стандарта:

 

 

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

 

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

 

А как должен вести себя мастер в этом случае?:

Если я правильно понял, мастер при своем включении должен прогнать протокол 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 0]

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

ну да тупо сидит, вобщем-то логично, а что он еще должен посылать если у него 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 и потом обслуживает его по полной программе.

[dimanisu 0]

Спасибо Fakir за столь обстоятельный ответ. Но вопросы се же остались :)

 

Вы писали:

Вот мастер и рулит как хочет, хочет сразу всех конфигурирует(например скорость сети), а хочет по одному(NODE-ID). Если мастер хочет с кем-то поработать, он сначала переводит клиента в configuration mode и потом обслуживает его по полной программе.

 

Ведь если он все узлы переведет в конфиг режим, то скажем при использовании LSS Identify Remote Slaves протокола, могут отвечать несколько узлов одновременно, а ведь они имеют одинаковые cob-id, что по идее должно привести к какой нибудь ошибке.

 

Причем в п. 5.1 LSS Slave Synchronisation написано:

"Since in the LSS Protocol all LSS Slaves use the same COB to send information to the LSS

Master, there must be only one LSS Slave at a time that communicates with the LSS Master. For all

protocols the LSS Master takes the initiative, a LSS Slave is only allowed to transmit within a

confirmed service after it has been uniquely switched into configuration mode."

 

Как такую ситуацию разруливать?

[Fakir 0]

Да, все верно, dimanisu очень хорошее замечание,я честно говоря не знаю.

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

[dimanisu 0]

Да, все верно, dimanisu очень хорошее замечание,я честно говоря не знаю.

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

 

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

 

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