PDA

View Full Version : A new System


Tim R
March 22nd, 2005, 09:39 AM
Good morning Class.

Todays topic of discusstion shall be the forming of a totally new control system. The system will have the following:

1) 13 control stations filling parts into boxes
2) Centralized control of all Stations
3) Data collection for all stations
4) RFID read/write heads at all stations
5) Alarm Handeler
6) Bar Code printers/readers at one station
7) Automation to be spread out over three rooms

Sounds like fun right! Well it will be (eventually) Oh, before I forget, the control stations are mobile and interchangeable. If I move one or take it offline, I cannot loose the rest of the network. Ethernet IP - TCP/IP looks good but not all the equipment has that capability.

Oh I know what you were thinking Remote I/0, Profibus, Devicenet and the likes. All of which are unsuitable comm protocols for this venture. If you loose one drop, the network will fault.

I'm in contact with AB, Moeller and GE. I'm (sort of) getting the "deer-in-the-headlights" look from them with "I'll have to make some phone calls and get back with you."

Any Ideas?

Tim R

RMA
March 22nd, 2005, 10:27 AM
Oh I know what you were thinking Remote I/0, Profibus, Devicenet and the likes. All of which are unsuitable comm protocols for this venture. If you loose one drop, the network will fault.






It might not be the most elegant way, but depending on how far apart your stations are, you can solve the problem of faulting the network when you remove a station by using an optical fibre backbone (as a Siemens user, I would automatically use Profibus) and then use an OBT to drop the connection via RS485 to each station. That way you only disconnect the individual Stations from the OBT and the Backbone stays intact and the network stays up.

JesperMP
March 22nd, 2005, 10:41 AM
Tim R.
You write "centralised control" and "control stations are mobile and interchangeable".
It looks like a case for either ProfiNet or Ethernet/IP over WLAN.
I have seen WLAN modules for ProfiNet. They look good but are expensive.
I know that for ProfiNet and ET200S you can get small CP cards that accept serial protocols like Modbus and ASCII. That may be the way to connect your RFID readers. (What does a RFID writer do ? Arent the RFID codes fixed ?).
Something similar may be possible with Ethernet/IP.

RMA
March 22nd, 2005, 11:50 AM
(What does a RFID writer do ? Arent the RFID codes fixed ?).




I was involved in the development of 1st generation RFID systems in the early '90s (actually, they weren't RF, the communication was optical, but the principle was the same). The actual project was to automate the commissioning lines in the stores of a major Swedish wholesaler in Malmö supplying local drugstores. Basically the local drugstore would send in his order either directly online, or per Fax and a secretary keyed the data into the system. This data was then programmed into the RFID chip (as it would be nowadays) along with the stations where the items were stored. These chips were mounted on the hanger assembly of basket carriers on an overhead conveyor system, which were loaded with an empty basket and sent on their way. At each junction the chip would be read and the basket shunted in the appropriate direction until it had visited each (necessary) Station to get loaded with the appropriate goods by the station operators. The required goods were read out of the chip and displayed on a screen for the operators. If for some reason certain items were not available, the operator noted that on the screen and that was written back to the chip.

When the basket eventually arrived at the loading bay, the chip was now read out and an invoice created which reflected only those items which were actually supplied (can't remember now how the other items were handled). After unloading the the baskets continued back round to the starting stations, where the chip would be erased in preparation for the next order.

By the way, the overhead conveyor system was supplied by a Danish company. Can't remember the name now, but it's academic anway, because three months before the end of the project, they went bust!

akreel
March 22nd, 2005, 02:30 PM
Oh, before I forget, the control stations are mobile and interchangeable.

Ooooh! I like this part!
Two things occur to me: wireless and multitaps.

Can you use wireless data radios in this area/application?


If radio is out, how would this work? There are devices available which will allow you to tee-off from an RS232/485 or other serial data network (Westermo makes one of these: the LD-01, I think). If the PLC on the tee fails, the device switches to a pass-through mode.

If your equipment is going to be in roughly the same area when you're done moving it: put the "tee boxes" on the wall nearby. Use twisted-pair "hoses" with Amphenol/Cannon connecters on the end to attach to the machines. VIOLA!

AK

Tim R
March 22nd, 2005, 03:25 PM
Ok guys, you both have vaild ideas. Both of which I have considered.

To say Profinet is expensive it a touch of an understatement. Their quote was well over 100K. And I'm pretty sure they missed some stuff.

The stations are going to be about 10 feet apart from one another. However, I can't run anything overhead as there will be an overhead craine in the way. So the actual cable runs will probably be closer to 50 feet each. Not to mention the other two rooms which are probably about 100-150ft away. Both distances are within specs for such a system, but there are too many "if's" in writing that type of code.

The two options I'm taking a solid look at are Contrologix and Moellers XL200 series. The two platforms have their pros and cons. Contrologix wiould put everything on the same network (TCP-IP) which will try to send a hell of a lot of data over one network. Which makes me nervous.

Moeller has the RFID on a separate network with the control stations having their own processors. Data collection would be accomplished with CanOpen. That in itself make me nervous as I don't consider CanOpen to be that stable.

Any other ideas?

Tim R

Tim R
March 22nd, 2005, 03:56 PM
Ooooh! I like this part!
Two things occur to me: wireless and multitaps.

Can you use wireless data radios in this area/application?


If radio is out, how would this work? There are devices available which will allow you to tee-off from an RS232/485 or other serial data network (Westermo makes one of these: the LD-01, I think). If the PLC on the tee fails, the device switches to a pass-through mode.

If your equipment is going to be in roughly the same area when you're done moving it: put the "tee boxes" on the wall nearby. Use twisted-pair "hoses" with Amphenol/Cannon connecters on the end to attach to the machines. VIOLA!

AK

Wireless is out of the question. That was the first thing I thought of. The problem is that the RFID will not operate that way. At least not yet. Your RS-232 idea is not a bad one. (On a totally irrelevet line of thought, does anyone know what the RS stands for? I know, I'm just curious to see who else knows.) As I was saying, I think the ditances will be too far to keep the comm stable.

Tim R

PhilipW
March 22nd, 2005, 04:11 PM
Contrologix wiould put everything on the same network (TCP-IP) which will try to send a hell of a lot of data over one network. Which makes me nervous.
Yes and no. The key element of all TCP/IP networks is the specification and configuration of the switches. Without going into a whole tutorial on the subject, which I am not qualified to attempt, what I do know is that you will need a "Layer 2" switch that supports ICMP Snooping. Because control networks over Ethernet typically use UDP broadcasting, these packets can easily flood a network UNLESS your switch knows how to constrain the traffic to the correct ports.

There really is no need to be nervous about large and busy Ehternets; it is the switches that do all the work.

Tim R
March 22nd, 2005, 04:16 PM
Yes and no. The key element of all TCP/IP networks is the specification and configuration of the switches. Without going into a whole tutorial on the subject, which I am not qualified to attempt, what I do know is that you will need a "Layer 2" switch that supports ICMP Snooping. Because control networks over Ethernet typically use UDP broadcasting, these packets can easily flood a network UNLESS your switch knows how to constrain the traffic to the correct ports.

There really is no need to be nervous about large and busy Ehternets; it is the switches that do all the work.

An interesting point. I forgot about that. Something to consider.

Tim R

rsdoran
March 22nd, 2005, 04:37 PM
I think Ethernet would be the choice. As mentioned traffic can be controlled, high speed, and shutting down or moving a station wont crash the system.

Recommended Standard, I probably have 20 or more posts on that.

DonsDaMan
March 22nd, 2005, 04:38 PM
On a totally irrelevet line of thought, does anyone know what the RS stands for? I know, I'm just curious to see who else knows

I was going to guess "Receive/Send" but looked it up.

I'll just say, "Receive/Send" is NOT the right answer.

Ken Roach
March 22nd, 2005, 04:40 PM
It wouldn't bother me at all to put such a system onto a DeviceNet network. DNet doesn't "fail the network" when you unplug one node unless you daisy-chain the wiring and undo the trunk. In fact, hot plug-in is an absolute requirement for ODVA certification.

DeviceNet makes RS232 ASCII interfaces almost trivial, and I have done several RFID/DeviceNet direct interface projects.

You can get around the DeviceNet droplength restriction with copper or fiber repeaters.

The last-inch interface requirements of your RFID and barcode equipment are going to dictate the I/O or network requirements. If the RFID equipment has EtherNet/IP or DeviceNet or Profibus or CANOpen, then that's where you start looking.

You said "the RFID doesn't work that way" with regard to wireless Ethernet, so you must already have one or two vendors and models in mind.

ndzied1
March 22nd, 2005, 04:55 PM
does anyone know what the RS stands for

Recommended Standard Number 232 was the original title.

I think the formal name now is: Interface Between Data Terminal Equipment and Data Communication Equipment Employing Serial Binary Data Interchange.

For short you can call it EIA/TAI RS-232-E.

Ken Roach
March 22nd, 2005, 04:59 PM
When I was a kid, I thought that the "RS" in "RS-232" stood for "Radio Shack".

Tim R
March 22nd, 2005, 05:04 PM
It wouldn't bother me at all to put such a system onto a DeviceNet network. DNet doesn't "fail the network" when you unplug one node unless you daisy-chain the wiring and undo the trunk. In fact, hot plug-in is an absolute requirement for ODVA certification.

DeviceNet makes RS232 ASCII interfaces almost trivial, and I have done several RFID/DeviceNet direct interface projects.

You can get around the DeviceNet droplength restriction with copper or fiber repeaters.

The last-inch interface requirements of your RFID and barcode equipment are going to dictate the I/O or network requirements. If the RFID equipment has EtherNet/IP or DeviceNet or Profibus or CANOpen, then that's where you start looking.

You said "the RFID doesn't work that way" with regard to wireless Ethernet, so you must already have one or two vendors and models in mind.

DeviceNet was another consideration but running that cable in a clean room enviornment would be a pain. Not to mention I've had to fight my way around all kinds of devicenet problems in the past. Also keep in mind that these stations are to be interchangeable. That would require the operator to change the DeviceNet address. Seeing as I had to explain what a PLC was when I talked with them, I don't think that will be such a good idea. It does have profibus but as previously stated, it is VERY expensive. I have the specs for the RFID but I'm pretty sure it will change before it is all over.

Wireless ethernet is something I've considered. Problem is that it is in a very noisy (electrical) area. All kinds of interference to deal with. I have seen others try to use wireless in this type of application and had all kinds of problems.

The RFID I'm looking at is the Balluff system. According to my salesman, they've had pretty good success with it on a DH-485 setup. He wasn't specific in regards to who he sold it to or how many heads it needed or how far apart it was. And I'm pretty sure it wasn't mobile.

Pretty good ideas so far people, keep it up.

TJR

Steve Meisel
March 22nd, 2005, 05:05 PM
does anyone know what the RS stands for?
Tim R

Recommended Standard

Wow! A question on something that I actually learned in class last semester.

dash
March 22nd, 2005, 05:39 PM
"That would require the operator to change the DeviceNet address"

Why?

I would think that if you went with DeviceNet you could put a small input module in the unit & use a BCD dial to set the "station" number so that your main processor would know that the station has been relocated.

That way the DeviceNet node number would allways be the same, but would report it's point of use back to the system.

Just a thought,

Darren

dash
March 22nd, 2005, 05:46 PM
Or in some of the stuff we do we use an "intelligent" node (a Wago PFC). That way you can add RS-485 or RS-232 ports (up to 64 per node) and crunch your string data in the Wago (the structured text also gives you very good control over the serial ports). You can also drive an inexpensive serial display from the Wago to provide basic enunciation to the operator of failed reads/writes, assembly problems, display a parts list & decement the list as the operator scans items with a barcode or enters/exits pick bins. Also I have typically found the the serial interface for all the RFID units I have worked with is usually more flexible than the field bus units. So with the structured text in the Wago you are able to create a very efficent process specific "engine" for driving the RFID data in/out of the tags. If the tags are large enough we have even stored the data in an XML format so that if you add/remove data or rearange the data you do not have to go into overload mode to be able to adjust your ERP/MRP (accounting software) interface since the data will be treated more like fields and the length/location of the data becomes independent.

The barcode reader could be used to set the point of use number in the PFC by the operator scanning the new location code on the conveyor system when he plugs the unit in. You could set it up to automatically prompt him/her when they plug the unit in.

Darren

Alan Case
March 22nd, 2005, 05:55 PM
I would be a bit dubious of any claim that the system would work at the speed you require on DH485. I would be exploring the devicenet option. Regards Alan Case

akreel
March 22nd, 2005, 06:49 PM
Recommended Standard

Wow! A question on something that I actually learned in class last semester.

Norm and Steve,

My research uncovered something different.

Buried somewhere in the Texas-Instruments archive, there's a document that explains "Recommended Standard" is a commonly accepted misnomer. The answer, according to TI, is "Radio Sector." There is some history of the RS set of electrical standards developing out of HAM radio or something...

Personally, I think "Radio Shack" is a better answer, anyway.

AK

EDIT: Found it. See page 4.
http://focus.ti.com/lit/an/slla070c/slla070c.pdf

Terry Woods
March 22nd, 2005, 07:09 PM
Hmmm... Interesting challange...

Worst case, it sounds like telling 13 people to scatter themselves about in the three rooms and then having each of them do something. ("Cycle-on-Station" comes to mind, an old Navy reference, as in... "Look what I can do!" - MAD TV).

OK... the units can be moved anywhere among the three rooms. Is it the case that the particular locations within the rooms are absolutely random? Are there any kind of reference points at all?

I get the feeling that these stations are receiving parts from a conveyor system of some kind... is that the case? If so, is the delivery system located in a fixed location? Again, if so, are the transfer points fixed?

Or... are there locally loaded supply bins at each station?

I have an idea... but, I'm done guessing about what the situation really is... more details about the potential layouts would help a lot.

And please... please, please don't say that all operating locations are completely random... that would make things... a bit (a bunch) more difficult.

ndzied1
March 22nd, 2005, 07:39 PM
I had read the Recommended Standard in "The C Programmers Guide to Serial Communications". I guess they got it wrong... or maybe not all the way right.

akreel
March 22nd, 2005, 08:12 PM
I had read the Recommended Standard in "The C Programmers Guide to Serial Communications". I guess they got it wrong... or maybe not all the way right.

Who knows? I figure TI's been building the IC chips since day one... Who better to believe?

Maybe RS stands for "Random Speculation."

rsdoran
March 22nd, 2005, 09:08 PM
As I stated in my earlier post I have provided this info several times. RS is short for Recommended Standard developed by EIA.
http://www.webopedia.com/TERM/R/RS_232C.html

In the early 1960s, a standards committee, today known as the Electronic Industries Association, developed a common interface standard for data communications equipment. At that time, data communications was thought to mean digital data exchange between a centrally located mainframe computer and a remote computer terminal, or possibly between two terminals without a computer involved. These devices were linked by telephone voice lines, and consequently required a modem at each end for signal translation. While simple in concept, the many opportunities for data error that occur when transmitting data through an analog channel require a relatively complex design. It was thought that a standard was needed first to ensure reliable communication, and second to enable the interconnection of equipment produced by different manufacturers, thereby fostering the benefits of mass production and competition. From these ideas, the RS232 standard was born. It specified signal voltages, signal timing, signal function, a protocol for information exchange, and mechanical connectors.

As you can see Radio was not involved in creating this standard.

CaseyK
March 22nd, 2005, 10:06 PM
Maybe RS stands for "Random Speculation."
I thought we should ask the expert. But he just replied.

I thought the R stood for RON. (rsdoran)

regards.....casey

CaseyK
March 22nd, 2005, 10:16 PM
I would LOVE to do this project with a GE Fanuc 9030 rack with wireless and VersaMAX micro's at each station.

I can do this project for.....

Oh rats, this isn't a bidding war.

I did something similar with 9030's and MultLin (GE) Relays several years ago, with a combination hardwired and wireless system. The MultiLin's did have an address assigned to them, so location or daisy-chaining was not a problem. we were partially wireless, as some of the facility was over 800 feet out, and another group of equipment was over 4000 feet out.

Worked quite well. Didn't have to make a road trip to sunny Cal. Though, on this cold wet windy March night in Illins, I would consider a trip to the land of Fruits and Nuts.

regards.....casey

akreel
March 23rd, 2005, 12:53 AM
As you can see Radio was not involved in creating this standard.

Food for thought, Ron:

Here's part of the answer I was looking for.
http://www.tiaonline.org/about/overview.cfm

If you check out the history portion of the page, you'll see EIA/TIA used to be "The Radio Manufacturers Association." So, my comment on HAM radio was off base. Interestingly enough, the organization is still broken up into "SECTORS". The TIA sector is currently responsible for the 232 standard. Interesting, no?

This doesn't prove anything conclusively, not even to me. But, having visited the site, I'm actually more convinced that "Radio Sector" might be right.

Do we have any EIA/TIA members who want to pipe in? Or, does someone want to buy the datasheet to see if it settles the debate?

AK

akreel
March 23rd, 2005, 01:01 AM
OOPS!!! I must've had a brain-****!

RS stands for "Rockwell Software." ;)

JesperMP
March 23rd, 2005, 02:09 AM
Lets have a look at those Balluff RFID recievers/transmitters.
Exactly which one(s) are you having in mind.
The ones I took a look at had RS232 (ASCII ?), RS485 (ASCII ?), InterBus, Profibus or DeviceNet capability.

Fine, that means you dont need a special interface card if you pick InterBus, Profius or DeviceNet.

You rule out wireless completely - OK.
There has to be detachable tabs with a length of up to 50 m - OK.

Then I suggest that you pick ProfiBus or DeviceNet, and then let a "station" (i/o modules, RFID module, HMI ? etc..) connect via one and same "drop" cable connection via a repeater.
There should then be a bunch of repeaters to suit the number of possible locations.

http://www.plctalk.net/qanda/uploads/NetWork.GIF
Purple = Profibus or Devicenet network.
Green = Ethernet network
R = Repeater

Its simple and inexpensive and it will work.

JesperMP
March 23rd, 2005, 03:45 AM
Tim R.

Is this by any chance a high-speed application ?
How many parts does the system have to handle per minute ?
How many steps are there in the sequence for each part ?

If it IS a high-speed application, then it will affect how the system must be implemented.

Tim R
March 23rd, 2005, 04:13 PM
Hey everyone,

Ok, your ideas are all pretty good. A couple of things here that I may have been vauge on.

1)The machines feeding the Fill Stations are fixed. The part made on each machine changes. Each Fill Station can be used at any machine.

2)The function of each Fill Station is the same for each machine. The data written to the RFID is a variable.

3)When a box is filled, I will receive a done bit from the machine and send the box onto a trunkline conveyor.

4)The HMI Station will need to create and send the data to the RFID. (I will make a form on the HMI to create work orders).

5)The boxes will terminate at a common location where the tags will be read and displayed on the HMI. The SCADA system will log and save the data.

Jesper, by looking at your layout, you have the HMI talking directly to the PLC. Ok, that's no trick. Are you suggesting then that the PLC will translate the RFID info and direct it to the right write head? Or am I missing something here? There is no local HMI. No need for one.

I haven't ruled out wireless. Lets just say it's impractical.

Terry, I guess it would depend on your definition of high speed is. I could (theroretically) have 13 boxes waiting for data to be written to their tags and transfer onto the trunkline.

The system I am proposing would need to be able to understand that when I move one fill station to another machine, it's RFID address and PLC address stay consistant with the information being sent from the HMI. Now if I give every Fill station a unique address, then the operator will need to know that fill station #5 is now on machine #12 so he can make sure the RFID info is valid. This is what I'm trying to avoid. The less the operator needs to think about what is where, the easier it will be to set up the system.

Now Profibus and devicenet, in a trunkline type setup will work as described. But I think so will Canbus. (If distance isn't a factor). And Canbus would be a lot less expensive. I'll be going over hardware with my vendors next week. I'll tell you where I end up and let you guys shot holes in it.

Hey Norm, I just talked with Chris. We'll be in touch after you get back. Have fun.

Tim R

Tim R
March 23rd, 2005, 04:18 PM
One other thing. As far as the question "what does the RS Stand for. recommended Standard is correct.

But I would also accept Rockwell Software, Radio Shack and Really Sucks.

Random Solution is really funny as well.

Anyone Know what OPC stands for?
Tim R

RMA
March 23rd, 2005, 05:15 PM
Anyone Know what OPC stands for?

OPC stands for OLE for Process Control. This is a further development of the Microsoft OLE standard (Object Linking and Embedding) for Data Exchange under Windows, addapted for the specific requirements of Process Control.

ndzied1
March 23rd, 2005, 06:21 PM
Thanks Tim,

I'll try to have fun. Half of my absence shold be fun but the rest will be made up for it in spades.

Terry Woods
March 23rd, 2005, 06:47 PM
OPC stands for "Other People's Cigarettes".

BTW Tim, that wasn't me asking about speed... that was Jesper.

I was asking about the nature of the layout.

akreel
March 23rd, 2005, 08:54 PM
OPC stands for "Other People's Cigarettes".

I like that!

I found my "final answer" on the TIA website. They WROTE the standard, people. I'm sticking with it. It makes for better cocktail party conversation, anyway.
http://www.tiaonline.org/resources/acronym_results.cfm?keyword=r

RS Radiocommunication Sector (of the ITU. Replaces CCIR)

Terry Woods
March 23rd, 2005, 09:24 PM
So... if you have been a good boy and things are easier than they usually are...

You could roll your station up to any of the valid locations and simply "plug-in" to a connector (one located at each valid work place) and then turn on the machine. The boot process would include a "Hello, I'm here!" to the central processor... a little hand-shaking between the station and the central processor, and then the station would get the "OK to Go" sign.

At any time, you should be able to send a "Log-Off Request" to the central processor... the central processor would ask for any remaining data that might need to be transferred (a little house cleaning before log-off), and then send an "OK to Disconnect" signal.

I use a TI-WAY Network with my TI Systems... all of the above can happen without breaking the network and actually, I can disconnect any local station without requesting the log-off. I can disconnect any time I want and the network remains.

Some networks won't tolerate that kind of behavior at all... "Everyone has to be in or no one is in!"

The network manager is always checking to see that the network is intact... if someone doesn't answer-up then there is hell to pay!

Some networks don't mind too much if a local station "fails" (disconnected or otherwise). In some cases, the local station can reconnect and all is forgiven... in others, the local station is not allowed back onto the network unless the manager goes down and reboots to re-establishes the network.

The (B)itch is that the manager is watching everything from a very narrow perspective.

Seems like there ought to be a way to fool that old man(ager)...

Hmmm... each station has a unique ID on the network...
That unique ID has to be present and there can't be two stations with the same ID... or can there?

How about a "Dummy Station"... This station exists in software only... it's not real. When a station requests a log-off, maybe the dummy station can be assigned the ID of the station going off-line...

Hmmm... this sounds like a situation where that special Network Code Language comes into play...

We all have seen that network operation seems to pretty damned closed to outside intervention... however, as I recall, each network has a variety of special function codes that can be exercised to manipulate the operation of the network...

Essentially, the network is maintained with a full complement of stations... real or otherwise (dummies). This means that the network can continue operating with as many a full complement of real stations to a full complement of dummy stations.

Just a thought... I haven't done this but it seems it ought to be do-able.

In the absolute worst-case... you could communicate over 8 digital lines from each potential station using ASCII code.

dandrade
March 25th, 2005, 01:39 PM
Network chart definitions http://www.synergetic.com/slidechart.htm

It project involves multiples "sincro" operations. Interesting, if expose a picture graphic it help will be better.

:thumb: CanBus aproval, similar project.

JesperMP
March 29th, 2005, 03:20 AM
Jesper, by looking at your layout, you have the HMI talking directly to the PLC. Ok, that's no trick. ... There is no local HMI. No need for one.
OK, because I know so little about your application I just "filled in" a local HMI because it could be useful and because it is possible.

..Are you suggesting then that the PLC will translate the RFID info and direct it to the right write head? Or am I missing something here?.. Yes, with the RFID units on Profibus or DeviceNet the PLC would access these units directly.