Petals on a wet, black bough

"""
Two methods to insert a dictionary tree node :
- create a sausage element; add the element in original dictionary
- insert directly in original dictionary
"""

insert_node(self, dot_name, value):
"""
Insert a MAPPED node
:param dot_name: string name such as 'x.y.z'
:param value: value of the dotted item
"""
    try:
        dot_name_str = str(dot_name)
        name_list = dot_name_str.split('.')
        key = name_list[-1]

        """
        # Create a sausage element first
        sausage_element = {key: str(value)}
        for i in reversed(name_list[:-1]):
            sausage_element = {i:sausage_element}

        # insert the element into dict
        dictionary = self.original_dict
        for i in name_list:
            if dictionary.has_key(i):
                dictionary = dictionary[i]
                sausage_element = sausage_element[i]
            else:
                dictionary[i] = sausage_element[i]
                break
        """

        # insert the element into dict
        dictionary = self.original_dictionary
        for i in name_list[:-1]:
            if not dictionary.has_key(i):
                dictionary[i] = {}
            dictionary = dictionary[i]
        dictionary[name_list[-1]] = str(value)
    except Exception as e
        print e

The process of CANOpen master determination is called flying master process.

Flying master is required when current CANOpen master fails, or is removed from network. If a new master is chosen, all devices on network will reset and thus all services have to be reset. This might have influence on current working CAN nodes. To avoid system crash, there should be a higher level mechanism.

The master arbitration procedure can be:

• Random sleep

Sleep proportion to its temporary CAN ID.

• Master detection

0x73 (ID Master request), ox71(ID Master response).

• Master collision detection

Just an overwriting of compile

from waflib import Build
from waflib import Runner

def compile(self):
for x in xrange(5):

try:
self.producer=Runner.Parallel(self,self.jobs)
self.producer.biter=self.get_build_iterator()
self.returned_tasks=[]
self.producer.start()

except KeyboardInterrupt:
self.store()
raise

except:
continue

else:
if not self.producer.error:
break

if self.producer.dirty:
self.store()

if self.producer.error:
raise Errors.BuildError(self.producer.error)

BuildContext.compile = compile

Service Data Object, or simply SDO, provides confirmed communication service between a SDO server and a SDO client. For each device, associated SDOs has to be configured. If more than 1 SDO server or client are configured, it means node’s space is narrowed by the more SDOs.

SDO indicates a peer-to-peer communication. The communication can be a segment or block based. The purpose of this communication is to write or read the other end’s object dictionary.

SDO has to be protected by timer for the transmission of a segment, a whole block. If timer expires, the state machine in CANOpen can handle. Depending on application scenario, there can be different expirations.

There are collisions if more than one SDO client starts a SDO transaction with a SDO server. These collision are still there even if more than one SDO server in one device. Actually, a device can not config too many SDO servers because this will sqash node id space.

To serve multiple SDO clients, CSMA/CD could be used to get a sensible CANOpen network communication. In case a SDO client is refused a SDO service, this client sleeps a random time and retries again.

SDO is a node to node service. When a SDO client communicates with a server, the client sets its SDO server node identifier as SDO client identifier. This means a SDO server can get another SDO client request in the middle of current SDO transfer. So any unrequested transfer from any new SDO client should be DROPPED SILEENTLY, even for a new request message.

SDO server cannot know a SDO request from which node.

To transfer a file via CAN networks, it can be split into many blocks and sent via CAN SDO service. If all file blocks are transfered, they can be assembled to the original file. The block based transfer can share the SDO service for different modules. In this way, the timeout of SDO transfer can be short, which results in a fast transfer generally.

For simple implementation, a stop-wait mechanism can be used. TFTP, XMODEM can be mapped into SDO blocks. Any implementation of block file transfer is similar to such open protocols. In such protocols, one end sends a block and peer send acknowledge an ACK packet. But here in CAN, a different acknowledge can be used: One sends packet to peer end and read acknowledge from peer end. So it is “write read check” (WRC).

SDO client SDO Server

Write block x
————————–>

Read block x status
————————–>

1. Transfer by SDO directly.

One control communication object is set for sesssion control. The other data communication object is set for file data.

If file is big, one disadvantage is that the data communication cannot be data in RAM, but data in NVM; another disadvantage is SDO is blocked with the file transfer for long time.

2. Transfer file block by block.
Same as above, one control communication object is used for session control. Another block control object to manage the block transfer. The last object is used for block transfer.

3. SDO as a data link layer.
External module similar to TFTP, or XMODEM uses CANOpen SDO as a data link layer. The external module manages the file blocks.

There are cases of using SDO to transfer files between different nodes via CAN bus. Different ways can realize the requirement. Here, we limit the implementation only in CAN application.

The scenario: One SDO server; multiple SDO clients; only one SDO transaction can exist.

1. Define 2 objects in dictionary (only for example): ftoCtrl (index, 1234) and ftoData(1235)

ftoCtrl keeps file transfer state, while ftoData carries data. They both have subindexes as well

2. Only client can initiates transfer and server will confirm the request. If within a certain time without confirmation, client fails the transfer.

3. After server confirms, client transmit the file over ftoData. ftoData should use type ‘domain’.

When configuring nodes by Layer Setting Services (LSS), some nodes can share the same serial number. In order to configure nodes efficiently and dynamically, the following sequence can be used:
Master                 Slave …

Procedure: Inquire Identity Product-Code

Inquire Identity Product-Code
————————–>

…

Inquire Identity Product-Code
<————————–

Timeout
Procedure: Inquire Identity Serial-Number of a certain Product-Code

Selective Product-Code
————————–>

Inquire Identity Serial-Number
————————–>

…
Inquire Identity Serial-Number
<————————–

Timeout
Procedure: Inquire Identity Serial-Number of another certain Product-Code

…
Procedure: Configure a node with Serial-Number of Product-Code

Selective Product-Code
————————–>

Selective Serial-Number
————————–>

Configure Node-ID
————————–>

…

Configure Node-ID
<————————–

Switch Mode Global
————————–>

Timeout