Some of you may know that I have grandchildren but never had any children – I skipped the middle step and went right to the fun part! I married a woman who had a daughter and after a few years I became a grandfather to a boy, Chris, and a girl, Lyric.

Chris is now 14. He’s never met his dad and I’ve filled the role of dad for him in a lot of ways. He’s spent more time with me than any other male. The raising of young men is something that’s been on my mind lately and I’ve been studying how young men are raised today.

100 years ago we were an agricultural society. A boy worked the farm with his dad, grandfather, and uncles. He was around men most of the day and had a chance to observe and pattern himself after how those men responded to adversity, handled their daily responsibilities and related to each other.

Today, boys don’t get much of that. Many are being raised by single mothers. Those in two parent homes seldom spend time working with their father and learning by his direct example. What boys learn about being a man is often from females.  Don’t misread me, men learn a lot of important things from the women in their lives but there are a few lessons that must come from the source.

Boys need to explore and learn to manage their natural aggression, competiveness and boundary testing. For example, Chris’ grandmother was horrified that he learned he could make plastic bottles explode by combining vinegar and baking soda. I made sure he knew how to be safe and was OK with him playing like that. He’s a boy. He’s testing himself by doing something that’s a tiny bit dangerous and getting some self-confidence from it. Besides, it’s fun for boys to make things explode.

It’s up to me to teach Chris to be a man. 90% of our mailing list is male so I am asking for your help. What are the key things that I need to teach him?  I’ve thought a lot about this and some of the topics I am considering are:

Honesty & Integrity – If you’re not a man of your word, how can you respect yourself as a man?

Discipline & Focus – Men are mission oriented.

Self-Reliance – A man is self-reliant.

Principles – A real man has a set of guiding principles that govern how he lives.

Challenge – Men seek challenge and continually find ways to test their limits.

Fearlessness – Men NEVER make fear based decisions. Fear based decisions lead to misery.

So, what do you think? What are the top 3 or 4 things that he has to know? I couldn’t help but find myself doing a bit of interpersonal reflection trying to define these traits. I’ll be waiting for your insight.

Email me at: jrinaldi at rtaautomation.com

Network Type: Multi-master Slave Communication system
Topology: Line with Trunkline, Dropline with Termination at each end
Cabling: 4 wire (2 data 2 power)
Data Rate: 125K, 250K, 500K, 1M
Max Number Devices: 127

CANopen™ is another CAN application layer protocol like DeviceNet and J1939. Like those other application layers, CANopen is a low-level industrial application layer protocol for automation applications. CANopen connects automation devices together using peer messaging. Built on the standard CAN (Controller Area Network) physical communications standard, CANopen uses CAN hardware to define an application layer protocol that structures the task of configuring, accessing and messaging between various kinds of automation devices.  The data structure of CANopen is also the base of the newer high speed protocol EtherCAT.

Data Structure:
CANopen is an object-based communications protocol. An Object Dictionary describes the complete functionality of a device. The Object Dictionary is the connection point between the communication interface and the application program. All communication objects are described in the Object Dictionary in a standardized way. These objects are accessible by a 16-bit index and, in the case of some objects in an additional 8-bit sub-index.

The CANopen Object Dictionary provides standardized communication objects for real-time data (PDOs - Process Data Objects), configuration data (SDOs - Service Data Objects), and special functions (Time Stamp, Sync Message, and Emergency Message) as well as network management data (Boot-up Message, NMT Message, and Error Control Message).

There are explicit and implicit messages that are embedded in the CAN Application layer that allow access to the Object Dictionary. Explicit messages allow a device to request the data value of a specific item in the Object Dictionary or set the value of an item in the Object Dictionary. Implicit messages allow predefined data transfers from one device to another without any overhead.

CANopen devices are not strictly peer-peer devices and not strictly Master-Slave devices. It is possible for a CANopen device to be a Master to another CANopen device and command it to take some action. At the same time, it can be a Slave device to another CANopen device that wishes to command it to take some action. And, at the same time it can exchange peer data with yet another CANopen device.

This is all possible because of the Object Dictionary, the organizing structure for all communications and all data exposed to the network within a CANopen device. If access is allowed, a device on a CANopen network can configure another CANopen device to perform peer communications or accept acyclic messages. Typically, this kind of general access is not made available to random nodes on the network. Instead, communication is preconfigured and provided to devices acting as a CANopen Master.

The CANopen Object Dictionary is the core of a CANopen device. The CANopen Object Dictionary contains the supported data types, communication objects, objects specific to the vendor and the device and objects specific to any profile supported.

Message and Data Types:

PDO data transfers are high priority, unconfirmed data transfers that move I/O and high priority status information from one device to another device. PDOs are the most common mechanism for two devices to exchange data. PDOs are initiated either internally by the device or from some kind of external message.

To simplify configuration of devices and avoid the problem of configuring all the PDOs in both of the CANopen devices, the CANopen specification defines a PreDefined Connection set. This is simply a set of pre-configured, well-understood PDOs. By using the PreDefined Connection Set you don’t need to go through the trouble of setting up the PDOs on both sides, making sure they match and testing the communications. You have a set of PDOs that already have preconfigured COB-IDs that you can use. The Predefined Connect set include four transmit PDOs, four receive PDOs, 1 SDO, 1 Emergency object and 1 Node Error Control identifier.

Service Data Objects support the transfer of asynchronous commands and data between two CANopen devices. SDOs exist primarily for configuration, though some vendors seem to like to use them for data transfer. The target of the SDO message, the Object Dictionary that is acted upon, is the Server for the SDO. The initiator is the Client of the SDO.

SDOs have two purposes; to read an Object Directory entry in another CANopen device or to write an Object Dictionary entry in another CANopen device. Every SDO contains a full complement of 8 bytes of data even though sometimes data bytes will go unused. Unlike PDOs, SDO transfers are always confirmed by the receiver. Also unlike PDOs, SDOs can transfer much more data and have multiple types.

To simplify configuration of devices and again avoid the problem of configuring all the SDOs in both of the CANopen devices, the CANopen specification defines a Predefined Connection set. The Predefined Connection set contains a single SDO in each direction.

Just like with the Predefined Connection set for PDOs, the connection IDs of the SDOs are configured with the node address of the CANopen device so that a Maser type device can easily send SDOs to the device and get the SDO response messages.

CANopen also supports a number of other message types:

SYNC Messages - A set of messages that are issued by a Master type device that serve to synchronize the actions of a group of CANopen devices. CANopen reserves a connection ID in the highest priority group (lowest CAN ID) to ensure that the SYNC message is reliably transmitted over the network

NMT Messages – A set of messages that a Master uses with a set of CANopen slave devices implementing the Predefined Connection set. The NMT (Network Management) protocol is implemented using a single CAN frame and is given the highest priority CAN ID (0). The NMT command consists of a command byte indicating the action to perform and a Node ID. A Node ID of zero is used to indicate that all devices on the network should execute the given command.

EMERGENCY Messages – The set of messages used by a CANopen device to transmit some internal error condition. The Emergency Protocol transmits the Emergency Data Object once per occurrence of a device internal error. No additional messages are transmitted unless a different device internal error condition is raised. Typically, the CANopen Master device is the only device that will consume the Emergency Protocol message.

HEARTBEAT Messages – A single CAN frame that periodically transmits the current NMT state of the device.

CiA (CAN In Automation) provides both a certification test laboratory and a test tool. The Certification laboratory tests devices and certifies them compatible with the CANopen specification. The test tool evaluates whether a device behaves properly in a CANopen network. The test tool is available for purchase from CiA.