Devicenet Slave NS Slave

494DS
NetSilicon DeviceNet Slave Source Code Stack

The Fastest Way to DeviceNet Enable Your Factory Floor Product

DeviceNet Expands Your Market
DeviceNet is and has been the standard for factory floor I/O applications in North America for more than 20 years. Millions of DeviceNet devices populate the factory floors of large and small manufacturing systems. Enabling your product to communicate over DeviceNet vastly increases your potential market. If you are ready to DeviceNet enable your devices to better integrate with your customers DeviceNet automation system you’ve come to the right place.

So, What’s DeviceNet Really?
If you new to industrial networking you might not be getting this whole DeviceNet thing. So what is it? It’s a way for a bunch of industrial devices to transfer data to a Master device in a standard way. It uses an electrical and software interface called CAN (Controller Area Networking) that specifies the electrical signals and moves messages between nodes on the CAN network. DeviceNet is simply the definition of the devices on that network. For a more thorough definition of DeviceNet, go to DeviceNet Explained.

Taking The First Step
You need DeviceNet but probably don’t know much about it and certainly don’t have a year or more to properly code it in house, deploy it and ring it out in 10 or 20 prototype systems. You make devices that do all kinds of wonderful things but you’re not an industrial networking expert nor should you be. That’s where we come in. Our only business is helping automation people, engineers just like you that need to get things done, get network enabled. It is all we’ve been doing for more than 20 years.

The Perfect Solution For Your Platform

1. No hardware Dependencies (Well there is one – you do need a CAN interface)
2. No RTOS dependencies,
3.  ANSI C source code,
4. A SINGLE TASK solution with a small code footprint,
5. 5A really easy to use API and support for different CAN Controller interfaces

Getting Connected To DeviceNet
To get physically connected to the network you need a CAN Controller and a Transceiver. The CAN controller provides the low level software interface that enables all the CAN nodes to transfer data to each other. The Transceiver is simply the electrical interface that converts the board level signals to the signal levels of the CAN network. Thankfully a lot of microprocessors now come with the CAN controller built right in so you won’t have to worry about that. And RTA has the interface software for many, many of these CAN controllers so that will save you some time and vastly lower your risk. The CAN controller controls the timing on the DeviceNet network and if it’s not setup perfectly you’ll have one of those situations where your device works MOST of the time. You probably don’t want that….

What You’re Going To Get
Outta the box you’ll get not only the DeviceNet source code but a working Windows project that you can use to test it, an extensive user manual and a PC Tool that you’ll use to send DeviceNet Messages to your device. Some folks have been able to take this tool and get some messaging working within a few hours!

If Your A CIP (Common Industrial Protocol) Geek – You’ll Want To Know What Objects and Features are Supported
(for the rest of us just know that you’ll be getting everything that you’ll need to work with all the DeviceNet Masters)

• Message Router Object
• Connection Manager Object
• Identity Object
• DeviceNet Object
• Assembly Object
• User Defined Application Objects – These are objects that you can create (dynamically if you want) that present your data to a DeviceNet network.

Features for those of you that like that kind of thing

• Full DeviceNet Application including Explicit message Master and Slave
• Unconnected Message Manager
• Class 3 Explicit message Slave
• Class 1 Implicit I/O
• Signal task solution that runs on a single thread
• ANSI C Source Code
• CAN interfaces for Phillips, Atmel, Freescale, Reneasas and many more

ODVA Certification
You’ll want to know that all DeviceNet vendors are encourage (it’s not required) to have their devices tested against the ODVA standards at the ODVA lab. With RTA you’re getting software that has been through that lab more than 50 times in all kinds of devices. In fact we were the very, very first DeviceNet device certified by the ODVA even before Allen-Bradley!

You’ll like the fact that our support team will pretest and validate your device before it goes to the lab for official certification. And we’ll represent you at the lab. Anything goes wrong – we get the phone call, not you.

OK, Why RTA?
RTA is your best solution for DeviceNet. RTA’s DeviceNet royalty free source code stack is a single task solution for DeviceNet. This solution was built from the ground up specifically for embedded microcontroller applications. It has an incredibly straight forward, easy to understand API that makes integration of DeviceNet into your device almost effortless.

The support and responsiveness or our support team is second to none. You receive support from the engineers that wrote the code and sit on the committees that define it. When you call RTA you will never get an automated voice or redirected to India. You get a live, industry recognized DeviceNet expert. That is the RTA difference.

Information To Help You Understand DeviceNet The Top 7 Lessons

1. DeviceNet is an application layer protocol that is transferred on the CAN physical layer. That means that DeviceNetis simply the way data is organized in a CAN packet. The wire carries the data packets and 24VDC.
2. All devices on an DeviceNet network present their data to the network as a series of data values called attributes grouped with other similar data values into sets of attributes called Objects.
3. There are DeviceNet Required Objects – Identity, , Router that every device must have. The DeviceNet Specification defines those objects.
4. There are DeviceNet Application Objects that have the data for your specific device. For example, a DeviceNet Drive device has a Motor Object. DeviceNet devices that support specific devices all have the same set of DeviceNet application objects.
5. There are two kinds of messages that are transferred between an DeviceNet Master Device (opens connections and initiates data transfers) and DeviceNet Slave devices (provides data to Masters). These messages are Explicit Messages (asynchronous, as needed) and I/O Messages (Data messages that are continuously transferred).
6. DeviceNet is part of CIP, the Common Industrial Protocol. CIP defines the Object structure and specifies the message transfer. CIP protocol over CAN is DeviceNet. CIP protocol over Ethernet is EtherNet/IP. CIP on a ControlNet physical network is ControlNet.
7. WHAT IS THE DIFFERENCE BETWEEN DEVICENET MASTER AND SLAVE?
   This is the one of the first questions everyone asks because it’s confusing. A DeviceNet Master is a device like a Programmable Controller that makes connections with some number of DeviceNet Slaves. DeviceNet Master Devices control the data exchange with the DeviceNet Slaves. The DeviceNet Slave accepts “outputs” from the Programmable Controllers and returns “Inputs” to the DeviceNet Master. A Rockwell Automation ControlLogix is a DeviceNet Master device.

[wptabs rotate=”6000″] [wptabtitle]Features[/wptabtitle] [wptabcontent] [/wptabcontent] [wptabtitle]Benefits[/wptabtitle] [wptabcontent] [/wptabcontent] [/wptabs]