Unitronics CanOpen Primer One of the most frequent requests in the Uni User Community is more information about

CanOpen itself, and how the protocol operates. The help files and documentation are designed for implementing the protocol in the PLC, and assume a great deal about a user's familiarity with it. I created this document to assist those who are exploring the protocol, and need general information about how things work, nomenclature and such, without getting too nuts-and-bolts about it. Basic Concepts: A CanOpen network has one master device (the PLC) and several slave devices (I/O, Servos, Etc). The master gives the orders and the slaves execute. Every device has to have it's own Unit ID on the network (which can be set in several ways depending on the device manufacturer). Every unit must be set to the same baud rate. There are various flavors of CanOpen for different jobs. Unitronics supports DSP-301, plain vanilla . Every slave must also support this. The only other DSP I've encountered is 402, which is for motion control. Unitronics does not support it. CanOpen is a serial protocol. Electrically, it's closest cousin is RS-485. It uses a differential signal, which makes it inherently noise-resistant. The CanOpen port also takes 24 VDC power, so an isolated power supply can be used just for the network. This makes it very robust and reliable. CanOpen is a balanced network, which means you have to put a resistor at either end of the bus. Since everything depends on this electrical stability, don't mess around put the resistors in. CanOpen takes advantage of it's electrical stability by being a single-sided communication scheme. Unlike Modbus, where every message sent requires a reply from the receiver, CanOpen just sends the data, and relies on the robust electrical design to ensure the data got there. There is no reply from the slave device. This makes communication over CanOpen very efficient. Data collisions (two or more devices talking at once), garbled messages (it can happen) and a host of other nuts-and-bolts communication stuff is handled by the CanOpen chips in all the devices. You don't have to resend a bad message in CanOpen it does it for you. Configuration is the most critical aspect of the system. Once it is set up, it will run like a tank, and data moves around as if on it's own. Getting to that point is the challenge. A Word about Software: Unitronics uses Visilogic and the CanOpen Config function blocks to set itself up the master. Slave devices vary tremendously. Some use switches, some come with software built in, some come with nothing at all. Some slave devices retain their setup across power cycles some don't, and that really sucks. In theory, you can use Unitronics SDO function blocks (later) to configure a slave device. But that really stinks. I mean it. Don't try this. On the order of don't drink bleach or don't stick a fork in the light socket.

Buy a CanOpen adapter and software package. I use PcanOpen Magic Pro from EAS Academy. It isn't cheap ($1700 when I bought mine), but for setting up and troubleshooting your network, it is MANDATORY. It will save you hours and hours and hours of slogging through the EDS file manually looking for the right parameter, then figuring out how to configure it with a series of SDO functions in Visilogic, then trying to figure out why it didn't work. I've been there. Learn from my pain. Buy a kit. The rest of this guide will assume you did.

The Object Dictionary The OD is nothing but a fancy term for a parameter list. The dictionary defines what a device can do, how it communicates, and what information it sends. The Object Dictionary contains all sorts of parameters. Some are dicated by the standard. Some depend on the manufacturer. Some depend on the kind of device you are using. In short, there's a lot of different ones out there, and you'll need to familiarize yourself with your specific devices. Most devices include an EDS file, which is a list of all these parameters in electronic form. Good setup software can read this file and use it to change all those little codes floating around into something human-ish. You can also read it yourself by using UniEDS, which is just a reader to let you, well, read the EDS file. Message Types: CanOpen uses messages to communicate (as opposed to analog or smoke signals [unless you really mess up the wiring]). There are 4 basic types of message. 1. Network Management Telegrams these are used to manage the nodes themselves, distinct from the data in the nodes. You can start a node, stop it, put it in configuration mode, etc. 2. Service Data Objects used to read and write parameters in a node's object dictionary. Usually, this is done while the node is in configuration mode, before it is started. 3. Process Data Objects shortcuts to parameters in the node, the main means of communication between master and slave 4. Emergency Objects messages tossed from node to master when something goes awry. Most of these are associated with buffers inside the devices. From the PLC perspective, the buffers are used by the chip to manage traffic. When you send an NMT message, it goes into the buffer and then onto the network when there is an opening in the NMT traffic on the network. Your main concern in this is not to overload the buffers by sending too many commands of a particular type in a single ladder scan. We'll explore each in turn in the rest of this guide.

Understanding CanOpen via Unitronics While the documentation on CanOpen itself in Unitronics is admittedly sparse, the approach they use is very comprehensive. So to understand the protocol better, we'll examine it through the Unitronics lens. To do so, we'll look at the example program I posted at my blog.

The basic CanOpen setup is accomplished by setting a Unit ID for the PLC, and initialize Com FB to set the baud rate. After that, all the configuration action is in the CanOpen Config function block. Remember when I said CanOpen data seems to move around the network by itself? The Config block tells the PLC what ladder operands to use with that data.

First, note the Enable Node Operand, MB120. This actually serves no direct function as far as CanOpen is concerned. What it does is tell the ladder program whether or not to deal with the node. If the operand is set, Visilogic will pay attention to the node. If MB120 is off, Visilogic will ignore the node and all messages and logic pertaining to it, as if it was never configured at all. NMT - Network Management Telegrams NMT is the first thing to come online in the system when it is powered up. NMT does not carry any data about IO status, servo position and such it's all about the node itself, and it's condition. The slave uses an NMT message to report it's status to the master (stopped, running, configuration mode). The master uses an NMT message to tell the node to start, stop, or go to configuration mode. Pretty basic, eh?

NMT can be enabled or disabled in case the node does not support it. This is rare, but can happen, usually in the case of IO nodes that are bricks - a fixed number of IO and expected to just run. MI 125 is the node status. This is reported by the node to the PLC, either in response to a Node Guard request, or automatically through Heartbeat. We'll look at those in a second, for now, just know that a CanOpen Slave has the following states: 00 7F 05 04 Bootup. Like your computer, just faster. Pre-Operational. This is the configuration mode, where you use SDO (later) to change the node's setup. Operational. Now the inputs are sent, the outputs are changed and the servo runs hither and yon. Stopped. Either the node stopped itself (like for an internal error) or you stopped it.

So how do you get the node status into your PLC? You don't. The chip does it for you (isn't that nice?) All you have to do is tell Visilogic where to put it in PLC memory. In this case, we told it to drop the value in MI 125. Now, here's the catch CanOpen communications are one-sided. If your node reports 7F Pre-Op, and then you unplug it from the network, it will remain 7F forever. So how do we know if the status we have in MI 125 is fresh? That's where node guarding and heartbeat come into play. Node Guarding is the older method, where the PLC sends a request for status to the node, and the node replies. When the node answers, the status goes into MI 125, and the Toggle bit, MB 122, changes state, from 0-1, or 1-0. This isn't widely used anymore, because it increases traffic (two messages instead of one), and violates the single-sided principle of CanOpen. The modern way of checking status freshness is Heartbeat. The slave device is configured, either through software or via SDO from the PLC, to throw it's status onto the network at specified intervals. So node 1 will, all on it's own, write it's status into MI 125, say, every three seconds. Unitronics sees this new data come in, and sets the Received bit, MB 123, in response. So what does all of this look like in ladder? To begin, be aware that the wago node in the example uses node guarding, and that Unitronics recently changed the PLC operating system approach to node guarding to make it more closely resemble heartbeat. Node guarding starts by sending a request to the slave device to update it's status. This is done by T 2, which is designed to recycle itself as long as the PLC is running. It's good practice, if you have several nodes, to stagger these out a bit (T2 = 3.00 seconds, T3 = 3.1 seconds, etc), so the NMT buffer does not fill up. If you sre doing heartbeat, you should do the same with the heartbeat times of the slave devices. SB 293 is a system bit that reports if the NMT send buffer is full, so you don't overload it. Assuming it's not full, the Send NMT Node Guard FB is pulsed, targetting the slave node with Unit ID 1. The node sees the message on the line and coughs up it's status.

Now typically, the status is updated and the toggle bit changes. Just recently, Unitronics moved away from this slightly and started to set the received bit instead. This deviates slightly from Standard, but in this case it's worth it the same logic will work for Node Guarding or Heartbeat. When the status is received by the PLC, the PLC sets MB 123, the received bit. In respose, in logic, we turn on MB 127 Guard Received (this is not a CanOpen related bit, but a status bit used for logic purposes) and reset MB 123. Why do we reset MB 123 right away? Single-sided communications if we don't reset it, it will stay on forever. MB 127 is a direct coil, so in this logic setup, it will only be on for one scan. It breaks the rung leading to T0, the heartbeat timeout for ID 1. If MB 123 (and therefore, MB 127) are not set, T0 will time out, and force MI 125 (node status) to 00, so we know in logic the node is offline. Pay attention to the timing. A node status request is sent every three seconds, but the timeout is 5 seconds. That way, there is plenty of time to get fresh status before the node is declared offline in logic. So now we have NMT status for ID1, periodically updated and we can trust the freshness of it. What do we do with it?

The NMT State Machine: All CanOpen devices are State Machines, meaning that what they can do, and what commands they respond to, depends on the condition (state) they are in. We use NMT commands to move from one state to another. This sounds a bit complex, but it's only a fancy was of saying run / stop / config. All devices power up in Boot (state 00). Most will then fall through to Pre-Operational (7F) or Operational (5) on their own. With software, you can also change this behavior and pick which state to land in after Boot.

By looking at MI 125, we can determine the state we are in, and act accordingly with NMT Control Fbs. If stopped or Pre-Op, we will issue a Node Start command every 1 second until the node reports Operational Mode. If operational, we energize a bit that reports that to the ladder (MB123) You may notice that Bootup (00) is conspicuously absent. That's intentional. Remember earlier when we said if we didn't get fresh status data from the node, we would force it's status to 00? This prevents

the ladder from trying to start a node that may be damaged or disconnected. We want state 00 to be ignored in the ladder. If, however, we replace the damaged node, how will it start up again? Even though no NMT controls are issued, the Node Guard logic runs all the time. So if a fresh node is plugged in to replace a damaged one, fresh status data will be received, then acted on, automatically bringing the node online. A final thought before we move on EMCY. CanOpen is extremely versatile, but that versatility comes at a price. You can start a node by sending a start command directly to it, or by broadcasting a start command to all nodes but some devices will not recognize a broadcast command and ignore it. You'll need to experiment with your devices to see which approach works, and which you prefer.

EMCY Emergency Telegrams So you know now if your node is there, and what condition it's in. But what if it simply malfunctions? Or, if it's a sophisticated device like a servo, what if you get a following error or overload? That's where EMCY comes into play.

Like NMT, you must enable it, because not every manufacturer has it. And in this case, you may even

choose to ignore it, even if it is there (not a good practice, obviously). When a node gets hosed up somehow, it throws an EMCY telegram back to the PLC, again all on it's own. The configuration tells the PLC where to drop the data it receives in the telegram. The Receive bit, MB 121, lets us know an error has come in from this node. Pretty basic. Remember single-sided communication it will stay lit until you reset it in logic. The Error code , MI 120, will contain the, uhm, error code. Some of these codes are dictated by the standard, some are manufacturer specific to the device (no following error for an IO node, right?) The Error register, MI 121, is a data register that will provide more information about the error code, if nescessary. The Manufacturer-specific registers (MI 122 CAUTION this uses 2 MI addresses, 122 and 123) will provide even more detail. Everything is in hexadecimal code numbers. If you bought software, and loaded the EDS file for the node into it, it will tell you everything wrong in human-ish. If you didn't, have fun slogging through the books, then go buy the software. EMCY in the example program is very basic, but before digging into it, be aware that some devices will kick out an EMCY even when there is no error Lenze 940 servo drives dump a blizzard of them onto the network while booting up. I cannot think of any earthly reason for this, but it sucks. When such a null frame comes in, you can distinguish it in ladder by the fact that the receive bit is set, but the code is 00 (hence the null).

In the example, if a condition appears that matches a Null Frame, we simply reset the Received bit so we can see if a real EMCY comes in later. If it IS a real EMCY (indicated by the code being something other than 00), we set a separate alarm bit, then reset the Received bit to look for further alarms. What you do with the received data from an EMCY is up to you. You can add whole chunks of code to examine the error, choose to reset or restart the node, ignore it or let it die quietly, all depending on the particular code you received. All EMCY tells you is something is amiss how you deal with it in ladder is all yours.

SDO - Service Data Objects An SDO is a special message that is used in ladder to read and write parameters to a slave device. Thay have two special distinctions they can read anything in the device and write to anything that's writable (not everything can be put into a PDO), and they are the only messages (apart from Node Guards) that the device will send an acknowledgment about. Send an SDO, and you will get data, an OK (or something to that effect) or an error, but you will get something back. That said forget them. If you bought software, it handles SDO for you when you need to configure a PDO or set a hearbeat. If your boss refuses to buy the software for you, point out to him that he will lose dozens of hours in development, calls to technical support of various companies, experimentation and struggle. If he's still not convinced, point out that he will lose even more time struggling to debug the network and jeapordizing the delivery date at a critical and high-profile moment. The only time I've ever used SDO in a real program was with an old Lenze drive that did not retain it's setup across power cycles. It was a 3-node network with light traffic, so I used SDO to directly read and write target and position values to the drive. I can forward the example to anyone who asks on the forum, but that really is all I have to say on the matter. If, in spite of my warnings, you are still masochistic enough to try using SDO to configure your device, Fantasia wrote an extensive article on the subject at the Unitronics website.

PDO Process Data Objects There are two kinds of PDO, Transmit and Receive. This nomenclature gets very confusing, but as you can imagine, this means one type of PDO receives data from another node, and the other transmits data to another node. Unitronics kindly added a Tx and Rx to the PDO descriptions in the Config FB, and since most people are familiar with these classic RS-232 designations, I'll keep with those. A Process Data Object is like a short-list of parameters within a CanOpen device. For instance, if you want to know a servo's position and current speed, you load the addresses for those parameters into the PDO during setup. At run time, the Tx PDO pulls the values of those parameters out and places them inside itself, making them available to the PLC. An Rx PDO takes values sent to it from the master and distributes them to the addresses within itself. If that sounds like indirect addressing, that's because it is. Unitronics supports 4 PDOs of each type. A device may have more than this, even a lot more, but you will only be able to see the first four of each. A PDO has a finite size 64 bits. That's 2 ML, or 4 MI, per PDO. During setup, as you choose items to stuff into PDOs, each item you choose has a size in bytes that it will occupy in the PDO. Eight is the limit, then you need to use an additional PDO. Just like you package and parse the data into PDOs in the slave, you must do the same in the master. PDOs cannot send bits, so all data comes across into ML, MI, and such. If you are getting inputs for a device, you must use a numeric-to-MB function to break the value out into bits for use in the program. A PDO's mode determines when it sends data to the master, and when it implements data received from the master. Each PDO can be different. These are either defaults, or set up with commissioning software.

1. Change of state when the information in the PDO changes (for instance, an input turns on), send data to the master. If a PDO itself changes (master sent outputs to the device), write them to the hardware immediately. 2. RTR Only update the master's data when specifically asked by a special PDO message, Request to Read. This flies in the face of CanOpen single-sided communication principles, and seems political to me. Some devices do not support it. 3. Sync Send data to the master, and apply output data to the hardware, after a certain number of Sync signals have been received (more on sync in a bit) 4. Timed send data to the master at specified intervals. Not really a CanOpen standard mode, but some devices support it. When configuring PDOs, keep in mind a few limitations. 1. Not everything can be placed in a PDO. In Lenze 940 drives, parameters with floating point values are disallowed. There is usually a way around this though either a different address that does allow transmission, or some creative scaling. The software will help you sort out what can and cannot be loaded. 2. Some devices don't care if the byte count is accurate some care a lot, and will error if too much or too little data is sent by the PLC.

Now that we've glanced at how PDOs are used and what they entail, let's dig into how to implement them in Unitronics. We'll start with Rx PDOs. The tPDO Rx is a PDO that receives data from the slave device. The cob ID is the hexadecimal address of the PDO in question. Essentially, if the master sees a PDO message with this address floating on the network, it will grab it and stuff it's data into ML 20, and set MB126 to let you know fresh data has shown up. As long as you only set the unit ID and don't mess around with the addressing objects in the dicitionary, you can safely ignore the Cob ID. The slave node in the example is an IO node with 16 input bits, or 2 bytes of data. Depending on your device, you may need exactly 16 bits, or wind up with an error. The wago devices are pretty tolerant. That's all there is to it. Now, when an input changes, the new value magically appears in ML 20. Use a numeric to MB function block to parse it out and there you have it - inputs. The rPDO Tx is even simpler, it sends data from the PLC to the slave device.

In the Wago example, I have 10 outputs. When I trigger a Send PDO function, a message is put onto the network with address 201, containing 2 bytes of data taken from ML 25. When the slave device sees this address pass by, it grabs the data and stuffs it into the parameters named in the PDO setup

within itself. A couple of quick things yes, you can send half an ML, and yes, that's 16 bits of data fed into a system with 10 outputs attached. The Wago node feeds the data to the outputs until the outputs run out, then ignores the leftovers. Let's take a look at the PLC logic for all of this:

The first thing you'll notice is, if the slave node is not operational, exit the subroutine without processing any PDOs. Next, we pack the output bits, starting at MB 20, into ML 25, and parse the input bits from ML 20 in to a vector of MB starting at MB 10. Lastly, if the PDO buffer is not full, compare the output word ML25 to XL 25. If they don't match, then an output has changed in the PLC. This triggers the Send PDO1 command for Unit 1. After sending, XL25 is updated to match ML25, so the PDO is only sent once when the outputs change.

A couple of things to remember about PDOs: 1. Wago automatically configures your PDOs for you based on the number of IO you have attached. Up to 64 inputs or outputs will fit into PDO1. After that, it starts using PDO2 for the overflow, and so on. 2. Analog values in Wago devices default onto PDO2. If there are more than 64 digital IO, and the extras are on PDO2, the analog values are pushed down to PDO3. Convenient, really, but you need to be aware of it. 3. Unitronics only supports sending PDOs from within ladder logic, as shown above. Received PDOs are loaded into their addresses autmatically, with no intervention from you.

This concludes our little treatise on CanOpen in Unitronics. I hope you find it helpful, and if you have questions, post them to the forum. Best of Luck, Tim Moulder