Plc Notes 2009 Plc Docx

8/6/2019 Plc Notes 2009 Plc Docx

1/23

===================================================

****** HART... A real 'oldie but goodie' - Part 2

===================================================

Last time we saw the details about the HART protocol. We learned that it is intended to 'sit on top of' an existing 4-

20ma current loop system. This was a large part of its value to us as a user of a communication system. Re-read

the previous notes if necessary to refresh your memory. Then let's move forward...

HART allows us to send commands as one of three different types. Let's examine each type and see where they are

used.

1- Universal Commands: These commands are common to all HART devices. They ensure that devices from one

manufacturer will be able to communicate with devices made from another manufacturer. They are generally the

most basic of commands. There is a whole list in the actual standard but some of the more common ones include

things such as reading process measurement results, reading upper and lower limits in the device, who

manufactured the device, etc.

All sub-devices connected to the HART network must be able to respond to all Universal Commands issued by the

main device on the HART network. The commands are 'universal' to all devices on the network.

2- Common Practice Commands: These commands are common to all products of a specific type (ie. proportional

valves, pressure transmitters, etc) It is not required to use these commands in a device but most products within a

category will use them. The commands are many, but generally include items to set a parameter, read a variable,

etc. Up to 256 variables are allowed in each device and up to four of them can be transmitted at once.

3- Device Specific Commands: These commands are specific to a device made by a manufacturer. They are solely

used for communication to that manufacturers specific device. Things like configuring some device specific

parameters or changing the set point of a PID loop or whatever is special to a particular manufacturers device are

handled with these commands.

How are these commands transmitted? That's a good question. Let's take a closer look...

Most communications is done with the tried-and-true method of main- sub communications(also called master/slave).

Here the main unit(ie. the plc) sends a command to the sub device. The sub device immediately replies with either a

response to the question or an acknowledgement that it received the command.

The other communications method (although less common than the main- sub method) is called 'burst

communications mode'. Here, the sub device will send a message to the main unit every x-milliseconds. This is

useful for data collection and storing of data by the main device for future analysis.

What do these messages actually look like?

Simple. It's an 11-byte message with start, stop and parity bits. Here are the details for your review:

--Preamble: Three or more hex FF characters tell the system that some data is coming and allows the devices to

synchronize with each other.

--Start Byte: This byte tells us which device(main, sub, or sub in burst mode)is going to be sending the data and

whether we'll be using a short or long frame message format.

--Address Field: The address field of the short frame format only contains 1 byte, with 1bit distinguishing between 2

mains and 1 more bit indicating burst mode messages. 4 bits are used for the actual addressing of the device(ie.

address 0-15) If we're using the long frame format then this address field will be 5 bytes(ie. for 38 bit addressing)

--Command Byte: This is the actual command (1 byte) from the list of possible commands used by the 3 command

modes we discussed above (ie. Universal, Command and Device Specific)


2/23

--Byte Count: This is the total number of bytes within the message itself. This is important because we need to know

we got the message as it can vary between 0 and 25 bytes.

--Status Bytes: Two status bytes are only used in reply messages from sub devices. They tell whether the message

they received was ok or not. When all is well both status bytes are zeros. --Data Bytes: This is the actual data itself.

Depending on the command byte sent before, it can be in any number of formats. (for you numbers gurus, it can be

unsigned integer, floating-point, or ASCII encoded) Remember that this Data Byte field can also be empty as not

every command will need a reply with data.

--Error Checking: This last section simply contains the error checking section. A checksum is calculated and sent

with the message. The receiver recalculates the checksum after it gets the message and compares it to the one

sent. If they are equal then the message was received without error.

That's just about all there is to using HART. If you followed along you should be ready to use the technology... or at

least know what's going on in the communication. Not too complicated anymore... is it??

===================================================

****** FOUNDATION Fieldbus... A real 'standard' bus

===================================================

Discussing FOUNDATION Fieldbus is a great way to continue on with our 4-20ma progress so far. This is another

protocol that's been around for quite a while. A benefactor of the fieldbus standards war of 10+ years ago. Can you

remember back that far??

As always, we'll skip the marketing nonsense and give you the 'straight scoop' on the protocol and what we can do

with it.

But first... what is it used for? Basically it's meant to try and replace the conventional 4-20ma control loop wiring in

the factory with the latest and greatest (of its time long ago) digital communication system. FOUNDATION Fieldbus

allows for bi-directional communication between devices connected on a bus type of network. That basically means

we can talk from our plc to many other sensors, valves, measuring instruments, and other devices on the factory

floor.

Communication between the plc and other devices in the field can be important in many applications. This protocol

allows that. Start-up commands as well as operating parameters of devices can be sent back and forth between the

devices and the plc. Diagnostic information can also be included which can certainly be helpful when we are

troubleshooting or doing maintenance on the system.

Reality is though... unless we're building a new factory or expanding our existing one, FOUNDATION Fieldbus is

going to be hard to implement. Oooops... was I supposed to say that - marketing people? Sorry, but that's reality.

The reason is because the existing wiring and system setup can't be easily converted to a bus configuration. The

wiring will have to be redone and replaced with shielded cable. Therein lies the problem for existing applications and

the benefit of something we talked about previously... HART.

But anyway, the most popular form of the bus(arguably)has a maximum communication speed of 31.25kbps(kilo bitsper second). It allows us to connect up to 32 devices to each segment of the bus. That's plenty for most

applications.

The nice part is that it uses standard shielded twisted pair cable and power can be supplied to the devices that are

connected to the system. Best of all, for some of you, intrinsic safety is supported so our factory won't go 'boom'.

You can also get quite far of a distance as going up to 1900 meters (about 6175 feet) is possible. Not bad if you

need to run that much cable...


3/23

Remember that in 4-20ma communication we are dealing with an analog signal. It is also a one-to-one type of

communication. The bus will allow one-to-many communication. That's benefit enough to make a switch for some of

us. 4-20ma is also one way communication. The bus is two way. Again, maybe that's enough to make a switch.

Let's look at the history of FOUNDATION Fieldbus before we get into the deep technical details that will really allow

us to make an intelligent decision to see if this is the right bus for us.

Back in 1984 a group got together to get rid of (modernize) the 4-20ma standard. It was to be a new and improved

digital standard. The standard was proposed to the IEC.

In 1985 the IEC recognized the digital communication protocol and called it Fieldbus. The ISA also joined in that year

and we were well on our way to a new standard.

Naturally, the manufacturers got into the mix and everyone had their own views on what the new standard should be.

7 years later and still no standard... so a group of makers gets together and forms the ISP (Interoperable Systems

Project) to create their Fieldbus. Yokogawa, Fisher Control, Siemens and Rosemount go in this direction in 1992. In

1993 they are officially a team.

In the meantime, not to be outdone, in March of 1993 the WorldFIP (Factory Instrumentation Protocol) is also

created by AB, Honeywell, Telemechanique, and some others.

So, now we have two groups going in different directions towards a standard. (funny, isn't it...) But to make a long

story short, the minds get together and thought it would be best for the industry (and profits) to unite as one. So, in

September of 1994 The Fieldbus Foundation was officially formed. And 2 years later in August of 1996 the

FOUNDATION Fieldbus H1 standard is published.

===================================================

****** FOUNDATION Fieldbus... A real 'standard' bus - part 2

===================================================

Let's quickly get back to where we left off before and find what makes FOUNDATION FIELDBUS 'work'.

Remember that we can use this bus like a tree. We run a trunk line and can tap into it as needed by adding branches

or 'spurs'. The maximum branch length can be 120m but it depends on how many branches we have as well as the

total number of devices per branch. More devices is going to mean less length.

The maximum length of the trunk is also going to be limited to about 1900m... assuming we use 18AWG cable.

Thinner cable is going to give us a less maximum length. 22AWG only gives us 1200m, for example. Please note

that 1200m is still quite far... wouldn't you agree? Oh yeah, don't forget to add terminators to each end of the bus.

So, how do the devices on the bus talk with the plc? Good question. Let's review that now...

Only one device is allowed to access the bus to talk at any given time. So, we need a way to ensure that is what

happens. Enter the LAS (Link Active Scheduler). The LAS controls and schedules any and all communication on the

bus. It is the traffic cop, if you will. It controls the bus by broadcasting different commands to all devices. It alsocontinuously polls unassigned addresses so it's possible for us to connect a new device while the bus is running and

it will be recognized.

On the bus we can have scheduled as well as unscheduled transmissions. Some things that need to be done

repeatedly are handled by the scheduled transmissions. The LAS periodically broadcasts a synchronization signal

called a TD(time distribution). This ensures all devices on the bus have the same time synchs. Since time to

transmit can be guaranteed we can say that FOUNDATION FIELDBUS is a deterministic bus.


4/23

The bus may have only one LAS. Any device that is capable of becoming an LAS is called a 'link master'. There may

be many link masters on the bus but only one can be the LAS. If the LAS fails then one of the other link masters

may take over as LAS. Kind of a semi-redundant design.

So, on the bus each activity can be scheduled for a particular time. The schedule is based on an offset from a preset

time. Based on that schedule a transmission list is generated which tells the system when a specific device can

send it's data. After getting the send data message the device broadcasts it's data to all devices that areconfigured to receive it.

The broadcasting device is called the 'publisher' and the receiving device is called the 'subscriber'. So, this is a

publisher/subscriber sequence of communication. The LAS issues a CD (compel data) command to the publisher

and when it receives the command it publishes the data to all subscribers. The subscribers then read the message.

Simple.

Since each device receives it's own schedule from the LAS, we can know exactly when any task is going to happen

and when specific data is going to be sent or received. Very organized.

But what about unscheduled transmissions? Good question.

Sometimes data is needed on an 'as needed basis'. This type of data is not time critical. FOUNDATION FIELDBUS

can handle that data as well. It takes care of that data whenever there is 'open air' on the line. If the bus is not doing

a scheduled task it is free to use.

The LAS issues a PT (pass token) command to the device wanting to send. This pass token is then rotated to all

devices on the 'live list' of devices needing to send data. Each device then gets the token and has permission to

talk. When done, the token gets passed along to the next device on the list.

The LAS asks each device not on the live list if they need to be added to the list with a PN (probe node) command.

The device sends back a PR (probe response) command if they want to be added. Devices that don't reply are not

added, or get taken off the live list.

Each 'control loop' accesses the bus only once for a short period of time. So, the bus can therefore be used for many

control loops or other things. This adds to our efficiency and shows one of the benefits to a distributed control plan.

Good stuff...

Well that's enough for this time. Lots of information to soak into the brain. Take a break and then try to reread the

above. It will make even more sense than it does now!

===================================================

****** DirectNET... Another oldie but goodie...

===================================================

This time we'll work with another of the oldie-but-goodie plc protocols... DirectNET.

DirectNET dates back to the mid-eighties. Back when RS-232C was the ruler of the communications world and one-to-one device communication was the norm. (read all about RS232-C herehttp://www.plcs.net/chapters/data30.htm)

It was actually founded by Koyo and used on many of the Koyo re-brands like the GE Series One, some TI's, et al.(it

also goes by the names Hostlink and CCM2)You can still find it today on the Automationdirect plc products. Actually,

that's probably where you will find it... unless you're a plc history buff.

But is it good for your application... even today? Well, it just might be. If you're doing simple data gathering or

transmission it could suit your needs just fine. To be sure though, let's examine how it works together...
http://www.plcs.net/chapters/data30.htmhttp://www.plcs.net/chapters/data30.htmhttp://www.plcs.net/chapters/data30.htmhttp://www.plcs.net/chapters/data30.htm


5/23

DirectNET is a simple network (most commonly main/sub) protocol. It works over an RS-232(or 422)line and is

useful for talking to a plc. Since it's running over an RS-232 line your speed limitations are there. Most often a

communications program is installed on a pc and it talks with the plc directly. If you happen to be using an

Automationdirect plc or an older Koyo re-brand you may already be using it... you just might not realize it. And if

you're talking to one of those brands via an HMI, you probably are using it.

We can connect a main unit to a single sub unit. Or we can connect a main unit to several (technically up to 90) sub

units. Or we can connect in a simple peer-to-peer configuration where nobody is in charge. So, we can either beconnected to a multi-drop network or a simple point-to-point network.

Speed wise, don't look to go too fast. 38.4Kbps would be our maximum speed whereas 19.2kbps is more the norm.

We can go a pretty far distance though... 1000meters(~3290 ft) if we are using the RS422 configuration of wiring.

Much like the other protocols 'of the time' it runs via an 'ask a question - get an answer' mindset. In other words, just

like the military of many countries, it has a 'don't ask, don't tell' policy. If you don't ask a question you won't get an

answer. You must poll for data. Either you ask the plc for data or you tell the plc where to write some data. If you

don't make a request... you get nothing. Sort of like asking for a pay raise at some jobs I've left... except sometimes

even asking got no raise (But that's a story for different day).

Speaking of why to use it, the protocol allows for all things you might need to create your own pc driven HMI, for

example. You can read/write memory values, check timer and counter current and preset values, read/write input

and output status, etc. But best of all, it's very simple to work with.

First off, your pc will have to format the commands in one of two modes... either HEX or ASCII mode. HEX mode is

good for reading/writing large amounts of data while ASCII is good for all other modes. Without getting into too much

detail, know that most applications will use ASCII mode.

Next, you need to have a conversation with the sub unit to get what you need. Generally speaking, our conversation

looks like this:

Main unit: Are you there sub-unit Joe?

sub unit: Yes main-unit Bob, I'm here.

Main unit: Ok sub-unit Joe, please do this...

sub unit: Ok main-unit Bob, I did it and here's the result...

Main unit: Ok sub-unit Joe, thanks for doing what I asked.sub unit: You're welcome main-unit Bob. Have a nice day.

Main unit: You too, sub unit Joe.

That's a typical conversation. The main unit starts the conversation and closes it. A sub-unit can't start a

conversation. If both devices need to start a conversation we need to use the peer-to-peer mode.

Well, that's enough for this time. Next time we'll replace our 'conversation human talk' with the commands the plc

actually uses. You'll see it's quite well thought out... or is it?? Hmmmm... we'll see a potential problem in

communications next time too.

===================================================

****** DirectNET... Another oldie but goodie, part 2...

===================================================You may recall from last time that DirectNET is a main/sub type of protocol which essentially means that we must

ask questions to the sub devices in order to get a response. We can connect a main device to many subs. In that

case, each sub has a unique address and we send the address with each request for information.

But, how do we send requests? What format do we use? Let's see that now, shall we...

Our overall conversation takes this format:

main: Hey sub 23, are you awake yet?

sub: Hi main. Yes, I'm here.


6/23

main: Good. What value do you have in counter 23?

sub: It's counted to 789.

main: Got it. It's 789, right?

sub: Yes, thanks for asking.

main: Ok, have a good day.

That's pretty much how our protocol works. Ask the proper sub unit a questions and get an answer. Don't ask and itwon't tell.

Now let's take that casual human conversation and convert it to how our plc will talk.

main: ENQ command (Hey sub 23, are you awake yet?)

sub: ACK response (Hi main. Yes, I'm here.)

main: HDR command (Good. What value do you have in counter 23?)

sub: ACK response and data (It's counted to 789.)

main: ACK command (Got it. It's 789, right?)

sub: EOT response (Yes, thanks for asking.)

main: EOT command (Ok, have a good day.)

ENQ is one of the ASCII codes that a computer device understands. It represents an enquiry and means to requestinformation.

ACK means to acknowledge a request meaning that it has been received. If we received NAK instead of ACK that

would mean that we received an error, so we'd Negative AcKnowledge.

HDR isn't an ASCII code and more or less just contains the question.

EOT is an End Of Transmission ASCII code and is one possible way of ending the conversation.

Lastly, let's show all the commands in greater detail as our plc will see them.

main: ENQ command (Hey sub 23, are you awake yet?)

Here we actually send an uppercase 'N', followed by the address of the sub unit we're talking to and then the ENQcommand.

sub: ACK response (Hi main. Yes, I'm here.)

Here we send an uppercase 'N', followed by the address of the sub unit that's speaking and then the ACK command

which says we got the request without error.

main: HDR command (Good. What value do you have in counter 23?)

Here we send the SOH (Start Of Header) character followed by the header itself (18 bytes consisting of the basic

message information) followed by the ETB (End of Transmission Block) character and lastly an error check byte

(called an LRC-- Longitudinal Redundancy Check byte).

sub: ACK response and data (It's counted to 789.)

Here we send an ACK character. Then we send an STX (Start Transmission) character, followed by the actual data,then the ETB and an LRC byte.

main: ACK command (Got it. It's 789, right?)

Here we just send an ACK. If the sub has more data it would reply with the rest of it.

sub: EOT response (Yes, thanks for asking.)

Here we send the EOT (End Of Transmission) character.


7/23

main: EOT command (Ok, have a good day.)

Here we also send the EOT character and close transmission.

And there you have it... Simple, wouldn't you agree? We can see the protocol (ie. a set of rules for communicating) is

nothing to be scared of once we break it down to a 'people conversation'. Geeeeee, PLCs talk just like us!

===================================================

****** SNP... Fun From GE

===================================================

This time let's take a closer look at another one of the olderserial communications programs... SNP.

SNP has been around for quite a long time. It is used with GE's brand of plc. In particular, it's used with their series

90 models. Oddly enough the name of the protocol, SNP, actually means Series Ninety Protocol... See it's easy

already!

Why would we use this protocol? Simple. We'd use it whenever we need to communicate to a GE plc through its

serial port.

But, there are some caveats (nice word, caveat). If you want the plc to talk with other plcs bidirectionally (ie. peer topeer communications) you won't be able to use this particular protocol. This protocol is only good for main-sub types

of communication. So, you can have one main unit talk with a sub unit... or even many sub units.

In other words, one plc does all the talking and the rest do all the listening. They only speak when spoken to. The

main asks all the questions and the subs do all the answering. For example, the main would ask the sub unit what the

value of a counter was and the sub unit would reply with the answer. The sub unit can never ask the main unit

anything. It just answers.

If you need both plcs to be able to ask each other questions or send each other commands, then this is not the

correct protocol for you.

This protocol communicates via the RS422 communications standard. Your computers serial port uses RS232 so you

will need a simple rs232-422 converter if you want to talk to the plc from your computer.

You should probably not be talking to any device more than 400 feet away. If you need to go further, plan on using a

repeater. That should get you about 2000 feet away. If you still need to go further than 2000 feet, try using a modem.

Now you're limited only by the phone system...

How about speed? Well if you need to fly at record speeds you're not in the right place in SNP land. However, just

like in most serial applications, you can go fast enough. That is as long as fast enough is no quicker than 19.2k bits

per second. Reality is, that's usually quick enough for most applications.

So, how about examining how the protocol actually works. It's quite simple, actually.

Firstly, the main unit transmits a long break signal. This signal usually lasts about 3 'clock pulses'. Actually, the break

signal itself is only used on legacy systems but it's probably a good habit to use it in case you're talking to some older

stuff... This break signal allows the subs to be prepared to accept a message. It's a kind of wake-up call for the sub

units.

After sending the break signal the main unit waits a specified amount of time to make sure the subs have woken up.

This time is usually about 50 milliseconds but can be up to 600 milliseconds if we're using a modem.

After waiting, the main will send an 'attach' message to the sub. The attach message contains the address of the sub

unit it needs to communicate to as well as the value of a timer we'll need later for synchronization.


8/23

The sub unit whose address is in the attach message receives the data. It then replies with a 'attach response'

message. This message basically confirms the request and acknowledges the timer value for future synchronization.

The main then sends a 'mailbox message' which is essentially a command. We'll get into what commands can be

sent a little later...

The sub sends an ACK command to tell the main unit it understood the command. It then processes and completes

the command.

Finally the main unit sends an ACK command which means that it received the subs confirmation of the command.

And that's it... not much to it, on the surface. Next time we'll examine the fine details of what's going on within the

commands themselves. It's a little more detailed when we go deeper but there is nothing too complicated for us.

===================================================

****** SNP... Fun From GE - part 2

===================================================

So how do we get the two plcs to talk with each other? Well, we have to have them speak a common language first.

The common language here is SNP. And just like with any language we need to follow a set of rules -- or protocol --

to make sure we understand each other. Let's examine those rules now.

First of all, let's make sure our plcs are set at the same communication speed and format. By default we use 19200-

8-odd-1. This is fancy type for saying that we use a speed of 19200 bits per second, each character we send is 8 bits

in size, we always send an odd number of 1's and we use 1 bit stop bit.

Now, let's take a look at the actual format of the messages.

Each message has 3 pieces to it. They are the header or start of the message, the footer or end of the message, and

the actual data that we are sending. We examine each piece in order.

The header consists of the following two bytes of data:

ESC character- Every message we send must start with an ESC character.

Message type- Here we tell the plc what type of message we are sending to it. It could be an inquiry message, an

attach message, a block transfer message, or other kind of message.

Next, we send the actual data. Here we should note that the maximum amount of data bytes allowed in a message is

1000 or 8000 depending upon which plc we are using. If our message is larger we'll need to split it into two or more

messages.

Also note that the minimum size is 40 bytes. Breaking a larger message into smaller ones is sometimes useful if there

is a lot of noise on our communication line. Since each message has error checking, a bunch of smaller ones should

have a better chance of getting through than one long one.

The footer is the end of the message and contains the following 6 bytes of data:

ETB character- Every message we send needs to include this End of Block character.

Next Message Type- If this is the end of the message this byte should be a zero. If it is not the end this should then

be equal to the type of message that will be sent next. The main purpose of this field is to signal the listening device

that it is ok to transmit if this field is zero.

Next Message Length- If we didn't send a zero in the last "next message type" field then we must put the total

number of bytes we'll transmit next into this field. If the "next message type" field was indeed zero, then this field

should also be set to zero.


9/23

Status Byte- This field is only used if the message is an 'Attach' or 'Attach Received' message. (An attach message

just specifies which device our main plc wants to communicate with. An attach received message is just the sub

devices reply to the main plc. More on this in a minute... )

If this message is indeed an 'attach' or 'attach received' message then this field will be the most significant byte of the

upcoming BCC field.

Block Check Code(BCC)- This field is used for error checking. The transmitting device runs a calculation on the data

it's going to send and sends the field. The receiving device runs the same calculation based on the data received. If

they match then there is no error. If they don't match we need to ask the transmitter to resend the data.

That's the format of our messages... nothing too complicated. But, before we end, let's take a quick look at the 'attach'

and 'attach received' message types.

The attach message is only sent by the main plc. This message contains the address of the sub device that it wants

to talk to. It also contains the time that both devices must wait before sending a reply to any message. This is usually

10ms and can be thought of as processing time.

Only the sub device with the address in the attach message will reply back to the main plc with an attach received

message. If the main plc sent zeros in the address field then all sub devices will reply.

Well that's all for SNP, Series Ninety Protocol. Hopefully we can see the operation quite clearly now. Being 'in the

know' certainly helps in our programming life, doesn't it???

===================================================

****** AS-Interface... Let the Sensors Do the Talking

===================================================

AS-Interface is a convenient bus for us... when we don't need to pass a lot of data back and forth. It's primary

intention is for your plc to be used to with simple sensors and actuators... Hence the meaning of AS-Interface is

actually 'Actuator Sensor-Interface'.

ASI came into the world back in 1994... the good old days where many (most?) plc vendors were pushing out their

buses. All felt they should be world standards and (to make a long story short) to this day we have no 'world

standard'. But ASI is in the mix.

ASI was introduced by Siemens and based around ProfiSafe (which was in itself from Profibus DP). It is an 'open

standard' which means there's an -unbiased- trade group that maintains the standard. Anyone can get (buy) a copy

of the standard and develop a product based on it. IEC 62026-2 and EN 50295 are the standards numbers.

It is a Main/Sub type of network meaning we can have one main unit (usually our plc) connect to many sub units.

Actually, depending upon the version of ASI we're using, we can have up to 31 or 62 sub units.

Generally that is large enough for all but the biggest networks. Remember, we're just connecting our plc to sensors

or actuators so 62 sensors/actuators is quite large. But again, large to some is small to others...

ASI is a two wire network and very simple to use. Power and data both flow over the cables. The cables are

Ungrounded, Unterminated and Unshielded (That's a lot of Un's...). We can connect our network in either ring, bus,

star or tree fashion.

Distance is also quite good. We can go all the way out to 100 meters (over 300 ft). And if we use a repeater we can

go out to about 600 meters... hopefully that's far enough for us to go. We can also connect a maximum of 124

inputs(31 subs x 4 inputs each = 124) and 124 outputs (31 subs x 4 outputs each = 124) according to the original

spec (2.0) or 248 inputs (62 subs x 4 inputs each = 248) and 186 outputs (62 subs x 3 outputs each = 186) according

to the 2.1 spec.


10/23

The cables can be connected to a power supply to transmit power to the devices on the network. Maximum

powercan be 8 amps at 24 VDC. Devices are simply 'tapped' into the cables at any point making installation a very

simple process. The cables are typically called 'yellow cables' because they are typically... 'yellow'.

We use 3 operating modes to communicate in. they are:

I/O data transfer mode- The inputs and outputs of connected sub units are read from and written to in this mode. So,

we transfer the status of the input/output devices to/from the plc.

Analog Value transfer mode- version 2.1 allows us to work with analog data. Here, that data is transferred and

processed.

Command mode- Here we can send/receive various commands. Some examples are address setting of the sub

units, diagnostic information reading from the subs and transferring various parameters and setting data.

How do we get/send the actual data from the sub units to the main unit?

Well that can be accomplished in one of two ways. The first way is arguably more popular. It is cyclic polling. This

simply means that at a given point in time we have the main unit ask the subs for some specific data. In other words,

the main unit polls the subs for their data. The subs get the request and send back their data.

The second way is by having the sub units send their data at specific time cycles. This is simply called cyclic datareception because we receive the data during specific cycles.

Maximum cycle time is ~5 ms when 31 subs are connected or 10 ms when 62 subs are connected. It's based on the

fact that each cycle is 150 us and there are 2 cycle required for administration... so we get: (2x150) + (31x150) =

300 + 4650 = 4950 us or 4.95 ms.

Well, hopefully that's enough of the basics to get you thinking as to whether or not this bus is right for your needs.

Next time we'll see how it actually works...

===================================================

****** AS-Interface... Let the Sensors Do the Talking - Part 2

===================================================

Let's continue with our AS-Interface discussion. You will remember from last time that we discussed the physicalhardware features. we pointed out that up to 31 sub devices can be connected to 1 main device. maximum

separation between them can be up to 100 meters... that's a far distance, isn't it?

Regarding speed, it's 'reasonably' quick. Each device added to the network increases the time needed for

communication. Each device requires a maximum of 150 us to talk. Plus the network needs 300 us to do some

housekeeping.

So, a network with the maximum 31 devices needs

(31 x 150) + 300 = 4650 + 300 = 4950 us or 4.95 ms

A network of only 15 devices would therefore require:

(15 x 150) + 300 = 2250 + 300 = 2550 us or 2.55 ms

As you can see from the above, less units mean a quicker speed. If we have 15 devices connected we can pretty

much guarantee that they will be spoken to every 2.55 milliseconds. Not bad...

Now let's see what actually gets sent during each message transfer and understand what goes on throughout the

network.

Messages sent throughout the network are called telegrams. The main unit sends as many telegrams as there are

connected and active sub devices on the network. So, if we have 25 devices connected the main unit will send 25

telegrams.


11/23

Each sub unit will be sequentially polled by the telegrams from the main unit. The sub unit with the lowest address

gets polled first and then the next higher, etc. If a sub unit becomes disconnected the main unit will notice within 1

cycle time (a maximum of 5 ms).

An AS-Interface telegram sends/receives a message in both directions with the sub units. First the main unit sends a

request to the subs (a write command) and then the subs reply (a read command) all within a single telegram.

So, we have a main call, then a main unit pause, then a sub unit reply and a sub unit pause.

A telegram will actually look like the below if we break it down into digestible pieces:

St Cb A4 A3 A2 A1 A0 I4 I3 I2 I1 I0 Pb Eb

St= Start Bit. This is always a 0. It's a 1 when not transmitting...

Cb= Control bit. This controls if we're working with 'data/parameter access' or 'command access'. It is set to 0 for

data/parameter access and 1 for command access.

A4-A0= Address bits. This is the address of the sub unit we are talking with. There are 5 bits here because 11111 in

binary is 31. So we can talk to any of the sub units just by setting it's address here.

I3-I0= Information bits. This is the actual information that we are sending to the sub unit... depending upon the

command.

Pb= Parity bit. this is used for error checking. If there are an even number of 1's in the message this is a 0. if there

are an odd number of 1's in the message this is a 1.

Eb= End bit. This terminates the message and is always a 1.

Now, let's put together a telegram where we are talking with only one sub unit. It will look like the below string of data:

main unit call

St Cb A4 A3 A2 A1 A0 I4 I3 I2 I1 I0 Pb Eb

main unit pause

3 to 10 bit timessub unit response

St I3 I2 I1 I0 Pb Eb

sub unit pause

1 bit time

Remember that the above communication happens in 1 telegram. If there were 25 sub units connected to the main

unit it would still all be sent in only 1 telegram.

Well, hopefully we can see how easy this network is to understand. Not much to it when we break it down into pieces

and analyze the results.

===================================================

****** FINS... Something's fishy here

===================================================

FINS(Factory Intelligent Network Services) is a protocol used by Omron plcs. This protocol allows the plc to

communicate with other plcs, external devices, and PCs.

Most commonly, this protocol is used to communicate over Ethernet. In that case, we can use FINS/UDP or

FINS/TCP. Basically, if we're using Ethernet to talk directly to other plcs on the same segment we'd want to use

FINS/UDP. Otherwise, FINS/TCP offers better communications quality and should be used. (That's a generalized

view...)


12/23

The protocol can also be used over their HostLink protocol. When used in this way, however, we are usually directly

connected via our pc.

When FINS is used over Ethernet we can have up to 254 devices and our message length is limited to 2012 bytes...

although that can be a large message.

When using FINS via HostLink we can have up to 1 device connected via rs-232 or up to 32 devices via rs-422. Inthis case our maximum message size is held back to 542 bytes.

FINS works by using a command/response type system. In other words, we send a command and wait for a

response. Simple theory... right? Well we can also send commands such that a reply is not needed. Or we can send

a broadcast message to all devices connected. So, it's flexible.

How do we know which device should get the message when a bunch are connected? Simple, we give each one an

address. Then we send the command to that address and the other devices will ignore it. (If we send to the address

FF we are broadcasting a message to all connected devices)

So, how do we talk to the plcs then? Well if we're using Ethernet we simply bury the message into the TCP or UDP

message. And if we're using HostLink we bury the message in there. Confusing? Then look at this:

For FINS/TCP the packet of data flowing would look like-

IP-TCP-FINS/TCP Header-FINS message-FCS

We took a standard TCP packet(ie message) and put the FINS data into

the section that requires data. Simple.

The same would be true for UDP or HostLink. We replace the data section with the FINS data.

What do the actual messages look like? Let's see the Ethernet commands first...

For the commands we use the format: header-command code-message

The header contains: ICF-RSV-GCT-DNA-DA1-DA2-SNA-SA1-SA2-SID

ICF - Information Control Field - This field describes if we are expecting a response, what type of data, and if we're

using a'gateway'.

RSV - Reserved - This is always 00

GCT - Gateway count - This is the maximum number of gateways allowed.

DNA - Destination Network Address

DA1 - Destination device Address

DA2 - Destination unit Address

SNA - Source Network Address

SA1 - Source device Address

SA2 - Source unit Address

SID - Service ID - This is the identity of the process it came from in

a large configuration. Make it any hex number from 00-FF.

When using HostLink the commands look slightly different. Not really different but we need to use certain specificvalues in certain places. The format is the same but... We start the header with FA.

ICF - Always 80

RSV - Always 00

GCT - Always 02

DNA - 00-7F hexadecimal number which corresponds to address from 0-127

DA1 - 01-3E hexadecimal node number

DA2 - 00 would indicate it's the CPU

SNA - Always 00


13/23

SA1 - Always 00

SA2 - Always set to FC

SID - Used as a counter when data is resent. Usually should be set to 00 initially.

Well that's a very rough (and I do mean rough) overview of what happens with FINS. It is most commonly used over

Ethernet to help the plcs communicate across the network. If you're using Ethernet and Omron devices you should

really know the basics of the above to further understand what's going on 'under the surface'.

===================================================

****** Host Link... Yes it still works.

===================================================

This time we'll discuss one of the oldest communications protocols defined by Omron... Host Link. Host Link allows a

single computer to talk with one or more PLCs. It can also allow more than one computer to talk with several PLCs,

depending on the mode it is in.

One point that should be mentioned is that just because you are using the Omron protocol doesn't mean you have to

be using an Omron PLC. On the contrary... it is an open protocol so many vendors actually support it. This means,

even more, that so we should know about it!

So, how do we use it? Let's see. First we need to figure out our setup. If we are using a single PLC connected to a

single computer we will use what's called a 'single-link' system. This is the most common setup. We are using the

computer to log data or just make simple changes to the PLC.

If we are using a single computer but are connected to multiple PLCs we will use what's called a 'multiple-link'

system. Gee... the naming makes sense, doesn't it?? And by the way, as we noted, we can also connect multiple

computers and multiple PLCs together to really have some good communications going on... but this is far less

common.

So, how do we connect everything together so they can freely talk with each other? Well, we use the same 'stuff' as

we would when using RS-232 or RS-422. Actually, we commonly talk over those communications lines.

If we are using RS-232 then we are going to be limited to a maximum distance of ~45ft (15m) between the computer

and the PLC... plenty of distance for most applications.

If we are using RS-422 then we have a much longer cable allowance... we can use up to ~1500ft (500m). If you need

to be farther than that distance from the PLC then a different technology is probably better for your application.

Why use RS-232 or RS-422? Simple, if talking with more than one PLC at the same time then use RS-422. If you're

only talking with one PLC then use RS-232. The only exception is when you need to talk with one PLC but must be

more than ~45ft (15m) away from the PLC. In that case RS-422 is also the best choice for your application.

So, what can we do with Host Link? Answer, what do you want to do? We can read memory out of the PLC. We can

write data to the memory of the PLC. We can force some inputs/outputs to be on/off.

Probably the most common use of Host Link protocol though is in using an HMI (Human Machine Interface). In case

you don't know, an HMI is basically the operator interface panel on a machine that gives/takes instructions form the

operator and translates those human understandable instructions into something the PLC can interpret. It is

sometimes also called an MMI... as in Man Machine Interface.

When using an HMI, we need to often get data from the PLC and display it. Perhaps we want to see a product count

or a temperature/pressure or maybe we just want to see an alarm condition. Instead of just seeing 'error 64' or

whatever, we can program the HMI to display 'over temperature alarm on cookie oven', for example.


14/23

The HMI would communicate with the PLC to get this type of data. The language that it will talk (in this example) will

be Host Link. remember, however, that the PLC and the HMI must both have built-in Host Link capability...

otherwise they won't be able to understand each other.

Well, that's a really brief overview of what Host Link is and what it can do. Next time we'll see the actual language

itself and follow a conversation between a PLC and a computer to really get an understanding of the process. You'll

see things on a byte level and realize that it isn't all 'black magic'... we can understand it.

===================================================

****** Host Link... Yes it still works... Part 2

===================================================

So, we know how to wire the system. We can also understand if it's the best system for our application. But how

does it work and how can we best utilize it? Let's see...

Assume we're doing something simple... like having our factory computer acting as an HMI (Human Machine

Interface) and constantly gathering data from our PLC. In this case, our computer is just polling the PLC for

information. In other words, it's asking a question and getting an answer.

The computer will send a command and wait for a response. If no response after a certain amount of time we can

resend the command. If we still don't get a response we can trigger an alarm which says 'hey, we have a problem

here'.

But what do the commands and responses look like?

Well, they all have the same format. We send a bunch of characters in what's called a frame. If we have more than

131 characters to send in our command we split it into two frames. The first frame gets a maximum of 131

characters and the second gets the number of characters left over. If that happens to be more than a large number

too, then we use another frame.

The point is that a frame cannot have more than 131 characters.

What do the frames look like? They all have this format:@ - unit number - header - message - fcs - terminator

Let's examine each piece of the frame.

@ is just a symbol that goes before the address of the PLC that weare sending the command to. We only use the @

symbol when we are connected to more than one PLC.

Unit number is the address of the PLC we are talking to. When there is more than one PLC connected to our system

we need to assign each of them a unique address. This is done so that we know exactly which PLC we are talking

to. If we only have one PLC connected it is not necessary to send the @ or the unit number.

The header is the actual command we are sending. It is a special abbreviation that is assigned to each command.

Check the PLC manual to find a list of commands that will work for your model. The header takes up 2 bytes.

The message is of course the contents of what you are sending. For example, if we want to add some data to a

memory location we would put that data here and then put the 'write data' command in the header.

The FCS is a way to check for errors. It is a 'Frame Check Sequence'.

We'll see later how to calculate it. It contains 2 bytes.

Lastly, the terminator uses the * character followed by a CR (carriage return) character. The * is only included in the

very last frame... in the case where we are sending more than 131 characters.


15/23

So, in the case of an HMI talking to more than one PLC the conversation may look like this:

@01 RH 0032 0001 64 Cr

This would mean:

Hey, PLC 01, what data do you have in memory 32?

The PLC would then reply

@01 RH 00 9876 76 Cr

Hi, I'm PLC 01, and I understood your request. 9876 is the data you asked for.

It's important to note that the 00 used above is the response code which means that the command was completed

normally. Any other response code would indicate an error of some kind and we'd have to refer to the manual to find

out what the error was.

Just for reference, the FCS is calculated by taking each character in it's ascii format and XORing it with the next

character. The answer is a two byte value. We won't go into the details since the PLC does this calculation

automatically for us... but it's simple if you understand digital XOR logic. If you don't, don't worry about it. It's an

automated calculation.

The FCS value is re-calculated by the receiving PLC and compared to the one sent. If they match we know we have

received the message without any communication caused errors. If they don't match, then we simply ask for the

message to be sent again.

That's really all there is to communicating with HostLink. It's quite simple... wouldn't you agree? See you next issue!

Learn, enjoy and PLEASE tell a friend or 2 or ... about the site and updates. They will appreciate you for it!

===================================================

****** Real Time Clock/Calendar... Don't be Late

===================================================

Have you come across a need for using a 'real time' clock/calendar function?

Perhaps you have a maintenance operation that must be performed every 30 days. Or maybe you want to log the

exact time/date when a particular event happens for later review. Or maybe every day at 12pm you just want to

sound a buzzer indicating it's lunch time...

If any of those needs seem familiar to your world, the Real Time Clock/Calendar is the perfect feature for you.

Although it's not always included as a standard PLC feature most modern PLC makers include it. Double check with

the brand/model you are thinking of using if it will be needed for your application.

So, now that we have figured out if we actually can use the feature, and we have checked to verify our PLC actually

includes the feature, we need to understand how to use it. Let the fun begin...!

Just like a regular clock with a time and date feature, we must initially set the time and date. Most likely the data is

backed up by a battery. More often than not the battery is not installed however. This is done so that the battery is

still fresh when you get around to installing the PLC on your machine.

So, lets go ahead and first install the battery if it's not already installed. It may seem silly to include this, and it maybe common sense, but if it wasn't done and you didn't realize it, it can be the cause of a big headache. Why pull out

what little hair we have left for no reason??

OK, with the battery installed we can now press forward.

The current time/date is stored in a specific memory location within the PLC. This memory location will obviously

vary depending upon the brand/model of the actual PLC that you're using.

For our example, let's say that the date is stored in memory locations


16/23

M1000 and 1001. The time is stored in memory location M1002 and 1003.

The 'date data' (that's a tongue twister...) that we generally have access to consists of the year, month, date, and day

of the week. Most often each is stored in its own memory location (ie. register) but occasionally we find two of the

values stored in a single location.

The data format is generally:

Year = 00-99 (seems like a y2k potential bug issue... or if you're

lucky(?) enough to be around it could be a y3k issue...)

Month= 01-12 where 01 is January and 12 is December

Date= 01-31 which is hopefully self-explanatory...

Day of Week= 00-06 where 00 is sunday and progresses in order from

there.

So, if we read memory locations M1000 and M1001 (in our example) and see the data 0611 in M1000 and 0103 in

M1001 we would know that it's 2006, November, the first of the month, and Wednesday.

To act on the data we would compare it to another memory location with our preset and if they're equal we would do

the function we needed done.

The 'time data' we have access to is generally hours, minutes, seconds and 10 millisecond-ths (ie. 1/100 of a

second). Just like the date data this is stored in 2 separate locations.

The data format is generally:

Hours: 00-23 (military hour format where 00 equals 12am and 23 equals 11pm)

Minutes: 00-59 which is hopefully self-explanatory...

Seconds: 00-59 which is also hopefully self-explanatory...

10 millisecondths: 00-99 which is 00/100 seconds through 99/100 seconds.

So, if we read memory locations M1002 and M1003 (in our example) and see the data 2211 in M1002 and 0103 in

M1203 we would know that it's 12.03 seconds past 10:11pm.

To act on the data we would compare it to another memory location with our preset and if they're equal we would do

the function we needed done... just like with our date function.

Just for reference, although it varies by manufacturer you can generally get an accurate time +/- about 30 seconds

per month. So, it will need to be reset after a while depending how accurate you need the time to be.

Well, there you have it. That's all there really is to know about how a RTCC (Real Time Clock Calendar) function

works. Now let's debate what 'real time' actually means...

===================================================

****** Analog or Not?

===================================================

Why all the concern lately about analog i/o? What's all the fuss about anyway? Good question. The word seems

high-tech and complicated to understand. So, let's de-mystify the concept together.When discussing inputs to our plc we talk of two types. Either digital or analog. That's it. No more choices. End of

story.

Digital inputs simply have two states. Either they are ON or they are OFF. That's it. Simple. Analog on the other

hand, has an almost infinite(i.e. unlimited) number of states. It is a varying input. No ON state or OFF state. Just all

points in between.

The speedometer in your car is an analog device. It shows speed as it varies. If it were a 'digital' device it would just

say either moving or not moving. Two choices both extreme. That's digital.


17/23

For our plc, digital inputs are just the simple input relays we've worked with together for quite a few issues. Analog

inputs however, usually are an optional module we can add onto our plc base unit(cpu).

This analog module is either going to come with voltage or current input configurations(sometimes both, selectable

by a dip switch on the module itself). Voltage is typically more common and used generally for short distances

between the analog module itself and the device that's sending the analog signal to the module. Current is typically

used when the module and device are far from each other.

Example input devices are pressure sensors(they measure air pressure for example), displacement sensors(they

measure distance), as well as other devices that give us measurements.

How the analog module functions is actually quite interesting. Let's understand it together.

We connect ourpressure sensorto the analog module. Initially the pressure is zero(0-PSI) so the voltage is zero

volts (0v). We increase the pressure and our sensor says the pressure is now 5-PSI(PSI means Pounds per Square

Inch and is a unit of measure) so 5 volts(5v) comes out of the sensor.

If we connect a volt meter to the pressure sensor output we can know what the pressure is. Understand so far? (if

the meter reads 5v then we know the pressure is 5PSI in our example above)

Well, an analog input module is just like a voltmeter. We simply connect the pressure sensor output to the analog

input module. Then the module automatically (it's magic...) takes the voltage reading and puts the result into a

special memory location. Once the reading is in the plc memory it's just a matter of taking it out, performing anynecessary math and working with the result. That's it!

An analog output module works in reverse. In other words, we put a value into a special memory location and the

plc takes that value, converts it into a voltage, and sends it out the plc output terminals. Simple, right! When you

specify the analog module you'll also come across the term 'resolution'. Be careful with this word because it's long

and only used by people 'in the know'. It means --- "the smallest change we can see". OK, now you're 'in the know'

too.

This resolution is typically measured in 'bits'. Bits are just a measure of how many pieces we can divide the number

into. The more pieces we can divide it into, the smaller the change we can see, and hence the better the resolution

of the module. Wow. I bet I lost you there.

Consider this example. You set the water temperature to take your shower. Ideally you like the water temperature tobe 110F. You turn on the hot water and ouchhhhh, it's too hot. So you turn it down and add some cold water to the

mix. Perfect... 110F.

What if the water were 111F? Would that feel too hot? Could you even tell the difference between 110F and 111F?

Perhaps you can't tell the difference between 110F and 113F. But 114F feels too hot. In this case yourbody

temperature resolution is 4F (114F-110F=4F)because that's the "smallest change" your body could see.

An analog modules resolution is measured in 'bits'. Each bit is

1 over (2^x). (2 to the x power) So 2 bit resolution is 1/(2^2) or 1/4. (2x2=4)

4 bit resolution is 1 /(2^4) or 1/16. (2x2x2x2=16).

Most common is 8bit, 12bit, 14bit or the highly accurate 16bit.

8bit resolution means each bit represents a piece of the voltage that is 1/(2^8) (2x2x2x2x2x2x2x2=256) or 1/256th the

size of the max piece.(12bit is 1/4096, 14bit is 1/16384, and 16bit is 1/65536)

Say we have an analog module that will measure from 0 to 5v.

So, the maximum it can see is 5v. An 8bit module means we can measure as small a change as (5v/256= 0.02v =

20 millivolts). A 12bit module means we can see a change as small as 0.00122v (= 1.2mv). 14bit resolution means

we can see a 0.00030517 (=0.3mv)change. 16bit resolution means we can see a change of 0.00007629 (=0.07mv)

or REAL SMALL... (i.e. 5v/65536=0.00007629v = 0.07mv)


18/23

The modules also may have a range where they can measure positive as well as negative voltages. For example,

we may use a +/-10v module. To figure its resolution we calculate based on 20v. (20 because we have -10 to +10)

So, 8bit resolution means we can see a change on this module as small as 20/256=0.78v = 780mv.

Well, that's the basics of using an analog module for your plc. In a future issue I'll show you how to create the ladder

logic for the program. Quite easy, as you may already see. Just get the value from the special memory location and

treat it like you would any other number you've worked with. See it is easy!

===================================================

****** Got docs?

===================================================

When going through the design of a plc system it's always, repeat always important to have proper documentation of

the system itself. There is no way you're going to remember everything in a year or two from now. Forget it. No

way.

Worse yet, how about if someone else needs to figure out the system. There is no chance unless they have some

documentation to go through. So, what's the best way to prepare documentation? I suppose there is no 'best way'

outside of what works best for you... but here are some ideas for you to consider. I know they work well :)

1- Summary of the system

This is absolutely critical, in my opinion. Take the time to summarize what exactly the plc system is going to be

doing. Use a flowchart to easily illustrate what's going on. First this happens, then this, if that happens then we do

this or if it doesn't we do that... as the name implies a flowchart shows the flow of the system in a step by step

manner. Critical...

2- Draw a system diagram

Create a diagram of the machine configuration. It's easier to envision what the system is going to be doing if you can

see it in picture form. You know the old saying... a picture says 1000 words(or something like that). It's true.

3- Determine what will be inputs and outputs (i.e. I/O)

Create a simple chart showing what parts will be used and if they are used as an input or an output. 3 columns are

fine. Put an x in the correct column to show if it's an input or output and describe the part in the last column.

INPUTS OUTPUTS DESCRIPTION

x tank level sensor

x flow sensor

x conveyor motor

x shutoff valve

4- Allocate the I/O and assign addresses. This will help us determine how many I/O modules and what kinds we'll

need for the sytem.

ADDRESS TYPE DESCRIPTIONI/000 NPN tank level sensor

I/001 0-5v flow sensor

O/000 relay conveyor motor

O/001 relay shutoff valve

5- Select the needed I/O modules based on step 4 above and lay them out as needed.

power supply - cpu - input - analog input - relay out


19/23

6- Set up charts to document your internal memory allocation, timers, counters, internal bits, misc.

ADDRESS TYPE DESCRIPTION

T/000 timer mixer timer

T/001 timer flow timer

C/000 counter batch count

7- Printout the actual ladder diagram you have written. Make sure you comment EVERYTHING, yes everything. That

goes for rung comments as well as device comments. More is better...

8- Make a nice wiring diagram of the entire plc system. Take some time and do it right so you can find any errors that

might pop up down the road or when you need to add something... that should have been there form the start.

9- Make a cd copy of all the files you used. Yes, all the files. If you password protected the program on the plc you

might include the password in a text file on the cd. At least keep it documented somewhere...

10- Keep it all in a single, safe place. There's nothing worse than forgetting where you put everything or a single

piece... I've been there sadly.

Well if you follow the above I'm confident you'll have some good documentation when the day comes to fix or modify

something on the plcsystem. Remember, there is no substitute for GOOD documentation!

===================================================

****** Motion Control Part 1

===================================================

An optical encoder is used with a motor to tell us distance traveled and the speed the motor is rotating. There are 2

common types of optical encoders... incremental and absolute.

Absolute encoders give us the actual position we're at in addition to the speed. Incremental encoders won't tell us

the actual position we're at but rather just the fact that we moved a certain distance and the speed of the motor.

This time we'll talk about the incremental type of encoder. Next time we'll dive into the absolute type.

An incremental encoderis actually a very simple device. Yes, a simple device that does so much, go figure...

Although there are many kinds, most of our applications will use a quadrature version. Essentially, what we have is a

circular disc with many equally spaced slits cut into it. The slits go around the circumference of the disc.

There are two rows of slits stacked on top of each other, but shifted over the width of a slit. It this way, the bottom row

of slits is 90 degrees 'out of phase' with the top row.

An LED shoots a focused beam of light at the top row of slits and when the light hits a slit it passes through to a

receiver. When it doesn't hit a slit no light hits the receiver. So, imagine the disc spinning and the light shining at the

disc. It passes through a slit, then gets blocked, then passes through the next slit, then blocked again, etc.

In the end we get a 'pulse train' of light, no light, light, no light, etc. Every transition from light to no light means we

rotated x degrees and so we can calculate how far we moved. The time it takes to go from light to no light and back to

light again helps us calculate the speed we're rotating at.

Remember we have 2 rows of slits on a quadrature encoder, a top and a bottom row that are 90 degrees out of

phase with each other. The bottom row has it's own focused light LED and receiver as well. So, if the top row receiver

sees light then the bottom row receiver must not since the slits are 90 degrees out of phase. If we look at the

light received/not received points(i.e. rising edge and falling edge) of both rows we can determine the direction the


20/23

encoder is rotating as well.

Incremental encoders have no idea regarding what position they are currently at. On the other hand, absolute

encoders so know their position, but more on that next time. Because an incremental encoder has no idea of its

position the motor controllermust move the motor until a limit switch is tripped. This position is then used as a

zero point reference.

So, how do you go about selecting an incremental optical encoder? It's not complicated actually. Aside from the

electrical characteristics we only need to know how many pulses it generates every revolution it does. This is called

the resolution.

For example, a 360 pulse per revolution encoder generates 360 pulses every revolution... or 1 pulse per degree it

rotates(360 pulses / 360 degrees = 1 pulse per degree). If we use the rising and falling edges we get 4 pulses (rising

and falling edges of top row + rising and falling edges of bottom row = 4 edges = 4 pulses)per every degree or

one pulse every 1/4 degree (i.e. 1 degree / 4 pulses).

So, the 360 pulse per revolution encoder can generate 1440 pulses per revolution (360 pulses x 4 edges = 1440).

Can the plc process the data? How can you tell?

Well, first we have to figure out if we need to use a high-speed counter or a regular counter. A regular counter canonly count safely at a rate of 1/2 to 1/4 of the scan time. Any faster and we need to step up to a high speed counter

module or even a special encoder module.

So, even with a 1 millisecond scan time we can't go too fast... but that might be ok for your application. (2 scans =

speed = 1ms * 2 = 0.002s = 500hz) To put it into perspective, 500hz is 500 pulses per second. If we use a 360 pulse

encoder that a little faster than 1 revolution per second. If we use it in quadrature mode that's about 1

revolution every 3 seconds... slowwwwwww.

So, most often we use a special encoder module or a high speed counter. Both are hardware (not software) counters

and are independent of the scan time. They will work with the fastest of encoders... but how fast is fast? Let's see...

Pulse frequency(in Hz) = (RPM / 60) * Pulses per revolution

Assume the RPM is large, like 10,000 and the encoder is the one from above with 360 pulses per revolution and we

have:

Pulse frequency(in Hz) = (10,000 /60) * 360 = 60,000 or 60kHz

If we use this in the quadrature mode we're still going to be ok as the formula would become:

Pulse frequency(in Hz) = (RPM / 60) * Pulses per revolution *4 = (10,000 /60) *360 *4 = 240,000 = 240kHz

Which encoder you choose is going to depend upon your application and the system you're using. Check the specs

of the encoder module and 'do the math' as shown above to make sure it will work for you.

In the example above an encoder with more pulses per revolution would be too close to the encoder module limit

(assuming a 250kHz limit). Less pulses per revolution would cause the speed to be measured with less resolution.Maybe that's ok, maybe not.

===================================================


===================================================

Let's look at the more complex (i.e. more expensive) member of the encoder family. In many applications the

absolute encoder is an 'absolute' must... pun intended. What types of applications you ask?


21/23

Applications where the position data must be retained after a power loss. An incremental encoderis basically a pulse

counter. It needs to be referenced to a certain point. Lose the power and you you need to re-reference it. Absolute

encoders, however, give out position data as their purpose so there is no need to reference it after a power loss.

How do they do that? Simple, they provide a unique output code forevery postion. So, no matter what point it is at it

will always tell us what that exact position is. But... how do they do that?

Basically, an absolute encoder has a glass disc inside of it. A shaft is 'stuck through' the center of it. The shaft

translates the motion of the device being monitored to the disc. The disc itself has rows of slits on it. Depending on

the resolution of the encoder (i.e. the smallest rotational change it can see) will determine how many rows

of slits it has.

Most of these are digital encoders so they work in binary. Therefore, each row gives us 2^x / 360 degrees resolution.

So, an encoder with 3 rows would give us 2^3 degrees of resolution or 2x2x2= 8 / 360 = 45 degrees. An encoder with

8 rows would give us: 2x2x2x2x2x2x2x2 = 256 / 360 = 0.71 degrees resolution.

In the 8 row example, we could see the shaft rotate every 0.71 degrees. There are encoders that are far more

'resolute' than that.

For example, a 12 bit (i.e. 12 row) encoder would see rotational changes of:

2x2x2x2x2x2x2x2x2x2x2x2 = 4096 / 360 = 0.087 degrees

As you can see from the above, each row adds a lot more resolution. When we get into the higher number of rows

we can certainly see smaller and smaller changes. But how do we use those changes?

Each row has its own output wire. That wire is typically input into the PLC via an encoder card. The encoder card

takes that data and does whatever it is your program tells it to. It needs a special card because inputs are flying in

and that data needs to be seperate from the scan or all kinds of encoder pulses would be missed...

Something else to note is that absolute encoders use 'Gray code' to output the positional data. Gray code differs

from regularbinary code in that for every change there can only be 1 bit change its state. Huh?

Consider an absolute encoder with 3 rows ( 2x2x2 = 8 /360 = 45 degrees of resolution... not too usable for most

applications but useful to help understand...). If the disc was binary encoded we would have these outputs for each

change:

0 000

1 001

2 010


22/23

Notice the arrows in the above... there are none. That's because in this coding there is never a time when more than

1 bit changes it's state(i.e. goes from on/off or off/on) at each position. If more than one bit changes between

positions the system is smart enough to know there is an error and can act accordingly.

Bottom line is that although the absolute encoders cost more than incremental ones they have a few benefits... and

those benefits can certainly justify the cost in many applications. And don't worry about needing to learn Gray

code... your encoder module will be able to work with it so you don't have to. Most PLCs will also have a Gray-

binary conversion instruction as well so you can work with the data elsewhere in your program as a position.

Make sense? Hopefully everything is a little clearer now.

===================================================


===================================================

A stepper motor is a motor that does just what its name implies... it moves by 'stepping', just like we do... well kinda

like we do anyway. We don't walk (i.e. step) in a single fluid motion. Rather we move in a start/stop type of motion

whereby we move a leg and then stop it and then move another leg and stop it. By repeating that process we move

a certain distance.

A stepper motor does something similar to our walking. It moves a few degrees and stops. Moves a few degrees

again and stops. As you can now understand, it is not continuous movement. Instead, it is start/stop movement.

Move, stop, move, stop, move, stop, etc.

On the other hand, a 'typical' motor does not work that way. A typical motor (is there really such a thing as a 'typical'

anything??) does not work that way. Nope, we just give it a voltage and it spins away as long as the voltage is there.

Nice and fluid motion as opposed to our start/stop motion in the stepper motor.

So, we can think of a 'typical' motor as an analog motor and a stepper motor as a digital motor. The analog motor

can vary position at any point in its movement. The digital motor can't vary its motion to any point but rather can vary

within predetermined distances.

How does it know where to move to? That's a good question. It needs to have a driver. The driver controls its

movement. It gets movement data (i.e. pulses)from a device capable of generating pulses. More often than not the

pulses come from a plc, of course. The plc often has single axis capability built into it but in recent times there are

also extension modules that plug in to the plc base unit and give it the capability to control more than one axis. Thepulses coming out of the plc are received by the stepper motor driver. The driver converts each pulse it receives from

the plc into 'motor motion'. If the motor moves 1 degree for every step and the plc sends 5 pulses the motor will of

course move 5 degrees. How about speed? Well that will depend upon how fast we can generate the pulses out of

the plc. Trouble is, we can generate the pulses real quick out the plc... many times too quickly. Too quickly because

we need to remember that the stepper motor moves like we do. Why does that matter? Let's see...

We can't just go from standing still to an all out sprint speed. Even the fastest runners in the world can't start from a

standing still position and be instantly at sprinting speed. The reality is that they need to gradually move faster and

faster until they get to their all out sprinting speed. Once the runner is at full speed they will continue at that speed

before stopping.

The same thing will apply to stopping. The runner can't just go from a full all out sprinting speed to a full stop. (unless

he runs into a brick wall... ) The stepper motor has the same issue. It can't just go from a 'cruising speed' to a deadstop. It needs to slow down gradually.

So, to get around this 'fact of life' we start running slowly while gradually building up our speed until we get to our

maximum cruising speed. Before coming to a complete stop we also slow down gradually.

Same thing for the stepper motor. We send out pulses at a slow speed and then gradually increase the speed of the

pulses until we get to the maximum speed we need to cruise at. Then we send out slower pulses until we safely

bring the stepper motor to a complete stop.


23/23

This starting slow and finishing slow type of motion is called ramping the motor. We slowly ramp up to speed and

then we slowly ramp down to speed. This is a 'must' when using stepper motors. If you don't do this your motor may

stall instead of move. That would be bad...

How do we create this ramping functionality? No worries, the plc will take care of creating 'the ramp' for you.

Generally you just need to give the system some basic parameters such as the number of pulses to generate and

the maximum speed.

So, if the system needs to be complex enough to have a special plc module or programming functionality why do we

need it? Why not just use a 'typical motor'?

The answer is simple. Precision. When you need to move a semi-precise distance you need something like a

stepper motor. A 'typical' motor will not give you the same or even close to the same precision as a

stepper motor will give you. On the other hand, if you need speed or ultra-high precision movement a stepper motor

might not be the best choice for you.

So, what qualifies as semi-precision? Generally, a stepper motor with high precision would be capable of moving

about 500 steps per revolution. That equates to about 0.72 degrees for every step. (i.e. 360degrees / 500steps =

0.72 degrees per step) We can also do what's called micro-stepping whereby we can get approximately double that

precision. To do that we move in half-steps with a more capable motor driver. But if you need high-precision

movement there are some better motor options. More on that next time...

Plc Notes 2009 Plc Docx

Documents