help with timeout error on setup_402_state_machine function

[danielluehr]

Hi,

first,I would like to thank everyone for the great work developing this module.

I am using this module to command a Xenus XTL Controller. Some years ago we (my team and I) started using version 0.3 of the canopen module and we tried to implement some parts of the 402 standard so we can control a rotary motor. The development stalled and a few weeks ago we resumed it. We decided to upgrade to the current version (1.0.0) to try the 402 profiles added to the module. In general, it is a great enhancement and we are replacing most of our code with the this project's 402 implementation.

However, we are experiencing and odd behaviour (it might be that we don't yet understand the 402 standard logic completely).

After creating a node and network and adding the node object to the network object, we send an sdo command to the controller to enter full CANopen mode (on reset, it is currently starting on a limited canopen monitoring mode, while the control is taken by internal routines of the controller).
Then we try to use the setup_402_state_machine function, but it fails with a timeout error on the last action (change state to "SWITCH ON DISABLED"). I have found similar situations in other issues here in github.
Nevertheless, if we send a mode of operation command using a direct call to the sdo, and then we repeat the call to setup_402_state_machine it doesn't fail.

We have tried to change the mode of operation before calling setup_402_state_machine for the first time but it fails anyway, and again a change of operation mode after failing seems to reset something and then re-executing the setup_402_state_machine works.

A sample code would be the following:

can_network = canopen.Network()
can_network.connect(channel='can0', bustype='socketcan', bitrate=250000)
can_node = canopen.BaseNode402(1, 'dict.eds')
can_network.add_node(can_node)
can_network.sync.start(0.1)
# enable servomode with CANopen interface
can_node.sdo[0x2300].raw = 30
# next command fails with timeout when changing state to 'SWITCH ON DISABLED'
can_node.setup_402_state_machine()
# change mode of operation
can_node.sdo[0x6060].raw = 3
# now it works
can_node.setup_402_state_machine()

I guess we are doing something wrong, however we cannot find what it is. Any help is appreciated.

Thanks

[af-silva]

Hi @danielluehr, it is nice to see this work being used.

Let's get to the point, inside p402.py you have this code that has been discussed in other issues here.

 def setup_402_state_machine(self):
        """Configure the state machine by searching for a TPDO that has the
        StatusWord mapped.
        :raise ValueError: If the the node can't find a Statusword configured
        in the any of the TPDOs
        """
        self.nmt.state = 'PRE-OPERATIONAL' # Why is this necessary?
        self.setup_pdos()
        self._check_controlword_configured()
        self._check_statusword_configured()
        self.nmt.state = 'OPERATIONAL'
        self.state = 'SWITCH ON DISABLED' # Why change state?

You can see that there are two comments regarding the need to define the self.nmt.state = 'PRE-OPERATIONAL' at the beginning and self.state = 'SWITCH ON DISABLED at the end. There are two state machines implementation inside can, one for the Network Management State Machine (nmt) and other for the devices. So this is translated to the code above, i'm just making sure the sate machine is at the desired state.

(courtesy of micrium )

(courtesy of nanotec)

In the NMT state machine, normally after reset (or power on) the devices tend to swith automatically to Pre-Operational mode, and when changing to Operational i'm just making sure the state machine of the devices is at Swith On Disabled, meaning there is no power applied, for instance on the motors . But @gsulc mention that there is no need to make this state change, and for now i'm not able to drive test this, I have a robot with 3 independent motors running on this code, so this I know it works and with do different types of controllers, but this library should be able to support multiple configurations and should work with any type of controller. So, pearhphs when powered the drive is set to a different state than "SWITCH ON DISABLED" and thus the timeout.

Can you please comment that line and see the behavior. Another thing may be the need of a sleep between, since that "command to the controller to enter full CANopen mode" may need some time to take effect on the controller, and the timeout of the setup_402_state_machine() give it the necessary time for when calling the second time it works.

can_node.sdo[0x2300].raw = 30
#--->  here  <---- 
# next command fails with timeout when changing state to 'SWITCH ON DISABLED'
can_node.setup_402_state_machine()

I will wait for your feedback,
Good hacking ;)

[danielluehr]

Hi @danielluehr, it is nice to see this work being used.

Thanks for the prompt reply @af-silva !

Let's get to the point, inside p402.py you have this code that has been discussed in other issues here.

 def setup_402_state_machine(self):
        """Configure the state machine by searching for a TPDO that has the
        StatusWord mapped.
        :raise ValueError: If the the node can't find a Statusword configured
        in the any of the TPDOs
        """
        self.nmt.state = 'PRE-OPERATIONAL' # Why is this necessary?
        self.setup_pdos()
        self._check_controlword_configured()
        self._check_statusword_configured()
        self.nmt.state = 'OPERATIONAL'
        self.state = 'SWITCH ON DISABLED' # Why change state?

You can see that there are two comments regarding the need to define the self.nmt.state = 'PRE-OPERATIONAL' at the beginning and self.state = 'SWITCH ON DISABLED at the end. There are two state machines implementation inside can, one for the Network Management State Machine (nmt) and other for the devices. So this is translated to the code above, i'm just making sure the sate machine is at the desired state.

(courtesy of micrium )

(courtesy of nanotec)

In the NMT state machine, normally after reset (or power on) the devices tend to swith automatically to Pre-Operational mode, and when changing to Operational i'm just making sure the state machine of the devices is at Swith On Disabled, meaning there is no power applied, for instance on the motors . But @gsulc mention that there is no need to make this state change, and for now i'm not able to drive test this, I have a robot with 3 independent motors running on this code, so this I know it works and with do different types of controllers, but this library should be able to support multiple configurations and should work with any type of controller. So, pearhphs when powered the drive is set to a different state than "SWITCH ON DISABLED" and thus the timeout.

We haven't read the 402 standard thoroughly, however we are starting to think that maybe the Xenus Controller implements parts of the standard with its own interpretation.

Can you please comment that line and see the behavior. Another thing may be the need of a sleep between, since that "command to the controller to enter full CANopen mode" may need some time to take effect on the controller, and the timeout of the setup_402_state_machine() give it the necessary time for when calling the second time it works.

We hunted down the issue and it has something to do with the PDOs (controlword and statusword).
Before going in detail about that, we do have a sleep after the CANopen mode, also the response of the controller is pretty fast.

So, back to the issue. The timeout error occurs when sending the controlword command using the pdo to change the state. Instead, we tried using the SDO method and it worked fine. Moreover, after sending the SDO command the PDO method starts working correctly.

Furthermore, when the controlword pdo is not working, nor is reading the statusword pdo, which results always in the value 0. Reading the statusword using SDO gives the correct value, but it doesn't "reset" the pdos. After setting the state using the SDO method, the statusword gives the same value using both methods, PDO and SDO.

Another particular behaviour of the Xenus controller is that after sending the CANopen command, the Mode of operation is set to zero, which makes the op_mode setter routine to fail. So the first time the mode of operation is set, we use a direct SDO write to the 0x6060 register.

We will try to do more testing regarding the change of states on the device, however we are more focused now in making our application work. I don't know whether to keep this issue open or not, since we found a workaround writing the controlword using SDO.

Thanks again,

can_node.sdo[0x2300].raw = 30
#--->  here  <---- 
# next command fails with timeout when changing state to 'SWITCH ON DISABLED'
can_node.setup_402_state_machine()

I will wait for your feedback,
Good hacking ;)

[af-silva]

We will try to do more testing regarding the change of states on the device, however we are more focused now in making our application work. I don't know whether to keep this issue open or not, since we found a workaround writing the controlword using SDO.

@danielluehr Go for it ;)

Just a word of advice, i don't know and have any experience with Xenus XTL Controllers, but you should read carefully the documentation to see how the controllers works and what are the expected behaviors at boot and so on. A question, have you guys define the Object Dictionary through the provided EDS file (if any) for your Xenus Controller ?? If so, the Controlword and Statusword are mapped to any PDO?

Good coding ;)