SLC or CLogix500

Alan Case

Lifetime Supporting Member
Join Date
Apr 2002
Location
Wagga Wagga
Posts
1,268
Hi, I have a machine that I am designing a control system for and would appreciate any input on the methodology I will be using.
A description of the machine is:
A conveyor belt with 30 diverter flaps spaced along the length of the belt.
At each diverter is an identical packing machine, which receives the product and stacks it into rows and layers, and then delivers it to another conveyor system for wrapping.

I intend to use a micrologix 1200 at each packing machine (approx 30 IO and also 1 high speed counter required)
I also intend to run a device net network using net-dni modules to connect all the 1200s back to a control logix system. (or maybe an SLC505)
The control logix main PLC will take care of the diverters on the main belt(tracking items by an encoder count), messaging to the 1200s the size of the packs required(ie layers and rows), keeping track of the status of each packing machine so that items can be dynamically re-assigned to another packer if the packer is in state where it cannot receive product(this status will also be used further up the food chain for inventory status) and running the outload conveyors and outload wrapping system.

I will paste in some info that Allen Bradley supplied me with on the advantages of a 1756DNB over a 1747SDN. The bit between the stars.
***************************************************************
Both the 1747-SDN and 1756-DNB are comparable as far as
their communication and behavior on DeviceNet. However, the
1756-DNB has more I/O data space available to get the slave
data back into the controller.

For example, the maximum amount of I/O data each direction
in a 1747-SDN is 360 bytes. If you divide this data by your number
of NETDNI modules which is 30, then that means you have a
maximum of 360/30=12 bytes of information that can be transfered
each direction to a NETDNI. The 1756-DNB has 492 bytes of I/O
data which would allow 492/30 = 16 bytes each direction per
NETDNI.

The next major advantage of a 1756-DNB is that the entire 492
bytes of I/O space is brought back as one large discrete I/O
datatable, each direction, every 5 ms. The 1747-SDN has
60 bytes of available discrete I/O data, but the last 300 bytes
of data are M0/M1 data and must be transfered to/from the
1747-SDN using file copy instructions in the user program.

Finally, explicit messaging is much easier to do in the
ControlLogix platform and 1756-DNB, using the built in
message instructions.
*****************************************************************

Can any one there see any problems with the general idea of how this will function. I already have a prototype packer working off an AB ML1200, no problems so far it is just the method of tying it all together and trying to justify the additional cost of a control logix system over an SLC.

Regards Alan Case
 
Usually in such systems, I have seen a request by the plant later on, to use a barcoding system to track the product. I don't know the availablitiy of RB modules for the slick or control logix. - just a thought.

Does the slick have a dedicated processor for communication? It looks as if there will be quite a lot of communication traffic going on. The control logix platform seems to have been designed with mass communication in mind.

Another thought - You may have already thought of this, but you could use photo-eyes with your encoder pulses at each transfer point to ease transfer. I.E. start measuring package size on leading edge of photo-eye and stop measuring on trailing edge in order to transfer the package when it is in the dead center of the transfer point.

Each photo-eye could be initialized to represent a position in the PLC tracking registers that would relate to the photo-eyes actual location. For example, on leading edge of the package blocking the photo-eye the photo-eye number could be used as a pointer into your tracking table to look up the sequence number of the package that actually arrived at the transfer point. The sequence number would point to a barcode look up table etc. Then a decision could be made as to the product type and wether or not it needs to be transfered.

I have done similar programming for sort systems. We used a PLC 5/40E because of memory requirments and availability of the RB module and the ease of ethernet communication. Slicks didn't have enough memory at the time. This was before the 5/05 came out, so I don't know if that processor would have worked or not.
 
Thanks for the input Gatentuator. There will be photo eyes at the transfer points to confirm that a package is correctly positioned. There will be considerable comms not between the micrologix's themselves but between the master controller and each micrologix. The packages will be barcoded but the barcoding will not be used for ID purposes in this setup. I am hoping that Ken Roach would have a say on this thread as I don't want to head down a certain path that has a glaring hole that I have not seen. Comms wise I mean. ie is devicenet to DNI modules to micrologix 1200s with a Clogix over the top a viable method. Regards Alan Case

Sorry if this is a bit dis-jointed, but I am just finishing a 56 hr day
 
You do too much. You aren't Superman, you know.

Fifty-six hours ? I can't do that with rattlesnake tequila and a river dory, let alone at the office. Go home and we'll see you in a couple of days.

As far as this system goes, I think the jump to the ControlLogix is probably unnecessary.

Here's why:

1. Commonality of programming. I think you'll be better off using RSLogix 500 for both your MicroLogix and SLC programming. It's a pain to use two editors in one project.

2. Small or no Remote I/O. The SLC doesn't do far-flung I/O networks nearly as well as the ControlLogix, but you aren't doing racks and racks of networked I/O.

3. Program Size. You aren't handling barcode data or doing significant datalogging, so I think the SLC-5/05 has plenty of memory for this conveyor application.

The only thing I'd be leery of is the encoder tracking; see if the number of counts you'll need to track is less than 32767 so you don't have the SLC's limited ability to handle large integers jump out and get you.

Yes, I think that sorting and tracking are easier in ControlLogix because of it's tag-based memory and array handling, but it sounds like you don't have Logix experience and are comfortable with the programming it would take in a SLC to do this application.

As far as the data mapped through the DeviceNet scanner, because you don't need lightning-fast data transfer it's no big deal to do M0/M1 file copies every few hundred milliseconds. You'll have only a few Words of data available both ways; 150 Words in each M-file, divided by 30 slave nodes, and not counting one Word for handshaking.... 5 words In and 5 words Out per slave will fill the 1747-SDN.

Definitely add an extra 1761-NET-DNI to hook up a laptop computer to for going online with the thirty MicroLogix. Although it's technically possible to use 1747-SDNPT Passthrough, in practice it's far too slow for online monitoring.

If you need to infrequently send or receive large numbers of words from MicroLogix to SLC, you could even connect a 1761-NET-DNI to Channel 0 of the SLC-5/05. That will let it message to the MicroLogix just as though they were on a local DH485 network.
 
Thanks for the answers Ken. It was a hard few days, covering a night shifts for a mate at a local timber mill, and then having a fault develop in another clients silo complex. (dead processor. Fugi not AB). One of those jobs you cant say no to.
Any way the project in hand.
1) RSLogix. Yes it would be nice to use the one editor, RSLogix.
2)50-50% Yes, even though it is a devicenet network, there will be no remote activation of outputs or reading of inputs directly over the network. Everything will be combined into blocks and sent as words between the master and slave. So Mo M1 files could handle it but messaging with control logix would be a neater implementation????
3) RSLogix.SLC505 can handle the memory quite easy.
4) Clogix. The counts will definitely be above 31267 which makes it a lot easier and tidy to use a Clogix.
5) SLC programming for this is well within my capabilities, but I have purchased a full Control Logix system to learn on and I find it reasonably intuitive.

Also a lot of industry is heading down the CLogix path and where a lot of these machines will be installed will have an existing Clogix system, so I guess it is still a difficult decision to make.
Regards Alan Case
 
If you really want commonality of programming, and would like to use contrologix, you could try compactlogix instead of the micro's. I have never used it and have no idea of the cost, but it might be worth investigating.
 
If the 32767 max count limit of the 'standard' AB encode module is a problem, use the Stepper Controller Module p/n 1746-HSTP1. This has a quadrature encoder input channel that can count up to +/-8,388,607 counts. The count value is formatted into two consecutive words which can be combined into a single float register with a little math and logic. You can ignore the stepper output section.
 
Why not go Clogix5000 all the way

Another alternative is to use a Control Logix to control the conveyors and the packing machines.
To do this you could put 3 DNET scanners in the Control logix Chassis and run 10 packers on each DNET network using block I/O and specialty high speed counters. Check these out http://www.wrcakron.com/pdffiles/catalogadd3.pdf

Put Two processors in the CLogix one to handle the packers and the other to handle the rest of the conveyor belt with 30 diverter flaps and encoders.

Its possibly cheaper and would take less effort to commission.
Locate the CLogix in the centre of the conveyor so the devicenet runs are shorter and run it at its maximum speed depending on your cable lengths.
Put the Clogix on Ethernet and install wireless. It makes fault finding a breese (no laptop cable hassles).

I haven't done the numbers on update rates etc, but it would be worth the effort as I see it being cheaper, easier to support, and quicker to program.

We did a similar project and that combines 50 nodes on two DNET trunks, with Barcode scanners, message displays, operator interfaces, variable speed drives and block i/o using only one processor.

Regards Mark S
 
Ganutanator. Looks like barcoding will be incorporated into the design now.
Rick. I was originally looking at a compact logix system for each packing station, but the ML1200 has 1 HSC, 24 inputs and 16 outputs (high speed outputs if needed) all in one very cheap package. I dont think AB make the equivalent package yet with CLogix as the programming language. (request to AB to start making the micrologix range in CLogix format).
Greg. Good idea with the stepper module. Rollover at 32767 would be a real pain otherwise.
Mark. I did look at a full control logix system but there is a fair bit of a price premium for the IO. A micrologix 1200 is approx $900 dollars here which is cheaper than just a HSC card alone, which does not have enough high speed outputs for what I need.

We have now pretty well decided on control logix as the master due to the better comms ability.
Regards Alan
 
I had an opportunity to do all of the new conveyor sort systems for a Goodyear plant in Union City Tnn.

I would get one encoder pulse for each inch of conveyor travel. Every three pulses I would shift my tracking data. Each tire that started down the conveyor system was given a sequence/tracking number. I.E. each false-true trans. of the photo-eye. Each shift (3 pulses/inches) I would copy the tracking array onto to itself one register later. If the tire was blocking the photo-eye the tracking number for that tire would appear to grow until the photo-eye became clear in which case the tire would cease to be measured. The end result would be the size of the tire moving down the conveyor which would be represented in the tracking array. clear as mud?


N200 data table

000888880000000000000777777000000000000006666660000000000055555500000

For example, tire number 7 would be a 18" tire.

When a transfer photo-eye was blocked, it would know where to look do to a previous intialization. ie. X-fer #1 would know to expect a tire at N200:[N202:1] or N200:34 (N202:1 would equal 34).

So when the PE (photo-eye) was blocked, it would see that the tire that arrived was #7. it would use the #7 as a pointer to look up the barcode. The barcode would be used to look up a sort schedule. A determination would then be made as to wether the tire should be transfered.

Let me know if you want me to send you the code.
 

Similar Topics

I'm trying to read/write to an SLC5 with a ControlLogix L71 V35 plc that fails. The exact same code works on an L82S with V32. Is there a known...
Replies
9
Views
86
I'm ashamed to admit this but I've never had to replace a battery in a SLC. Some how been able to skip that task in all my years. So yesterday...
Replies
8
Views
211
I have a program that I've used 100 times. SQO settings: File N7:0, Mask 0FFFFh, Dest B3:1, Control R6:0, Length 8, Pos 2. Length & Position...
Replies
48
Views
793
Hello PLC friends. I've been going through a saga of diagnosing and fixing an old PLC setup that I inherited. I am learning as I go. Initial...
Replies
14
Views
298
I had a 5/01 CPU give a CPU Fault. It lost the program and I was not able to establish communication with it. I replaced it with a 5/03 we had in...
Replies
3
Views
111
Back
Top Bottom