df1 half duplex slave

I am trying to design a system to replace an OEM 1980's control for auto setup order recall with 30 axis. I will reuse existing encoders 25ppr 10-30vdc. I did one before with 543c and a lot of HSCE's but would like to change to units on each section to eliminate running all encoder cables back to one location. My problem is I have always used RIO in alot of my projects and the ASB does not suport HSCE, I am looking at 1764BXB and HMI on each section communicating to 543c, not sure how to send messages. I have been reading up on MSG. Any thoughts or options I appreciate any input. I was figuring on
6 micro logix each with HMI and the 543c with bigger HMI not sure if I should use LRP and have HMI direct to Micrologix or as a seperate node. Thanks

Take a deep breath, step back a little.

How much I/O and how many encoders do you need at each station ?

How much local, fast control do you need at each station ?

How fast do the remote stations need to communicate back to the main controller ?

Is SLC-500 your only controller family choice ?

If this is an application that calls for small distributed controllers, I would look at the MicroLogix 1000/1100/1200 before I'd go to the 1500. And if you can use distributed I/O, I'd start looking at encoder input modules on POINT or FLEX I/O.

If all you want is a discussion of DF1 Half Duplex, I can do that too; I am very familiar with how that works both in polled and report-by-exception modes.

7 Encoders max on one station each encoder requires 2 isolated relay outputsto simulate a forward and reverse push buttom. The Master holds the order entrey data for set up weather it is a new order or one already saved. when "set up" button is pressed at master it sends integer for each axis to move to for the next run. Ifigured each slave would do its oun calculatin and control,each slave can also move each axis manualy through its own HMI. I would like the slaves to update thier possition on Master HMI. I am open to any sugestions but would like to do in AB since I have all the software and cables and am more familliar witth it. I can send the program I did with SLC and HSCE if I can find how to attach.There is a small amount of other I/O associated with program such as a permissive to do setup, a rate meter for machine speed, a total box count,and number of boxes in a bundle that get kicked out. Thanks for any help always appreciate.

If you want to stick with Allen Bradley, don't forget about the MicroLogix 1400 for a distributed control system with built-in encoder support. It supports up to six 100kHz high speed counters for your encoders and comes with Ethernet. Is available in a BXB (24VDC) version. Its less expensive to use multiple 1400's than one 1500 with a bunch of 1769 HSC modules and with the 1500 your comms are very slow due to the lack of Ethernet. So I'm suggesting using multiple 1400's at one station (if you need more than six encoder inputs) is likely a better choice due to the built-in Ethernet. Be careful to read the 1400 specs to verify you can really get six HS inputs for your type of encoder.

The Siemens s7-1200 is also a very cost effective alternative. Three 100KHz HS inputs + three more 30KHz HS inputs. Less than $400 for the brick with built-in Ethernet. Has optional 4 port Ethernet unmanaged switch for < $100. IO modules (up to 32 channels each) around $200 each, roughly. Nice software. Sweet.

You can do your high speed local processing with the 1400 (or S7-1200) and use the Ethernet for high speed MSG blocks to communicate between each other. I treat one of the 1400's as a 'master' that every other 1400 (all 'slaves') pushes its data changes up to the master using MSG - no polling this way. Its the job of the master to make the overall control decisions for the system and communicate (MSG) your home-grown application commands back down to the appropriate slaves. Its reasonable to end up with scan times in the low tens of milliseconds with the 1400 and Ethernet comms in the low hundreds of milliseconds: with the 1500, your comms are going to be notably slower than that. If you go the S7-1200 route, it has more options than just the raw messaging: for example, you can set up a shared block of memory to be automatically updated.

In this scenario you can safely use low cost unmanaged industrial Ethernet switches to interconnect the Ethernet as long as you are careful not to hook this control network into another plant network or you business information network. Using Ethernet, your HMI's can all view every PLC so you have the opportunity to allow the HMI's to control or view more than just the local station.

I have been reading the literature on ml1400 at AB.COM it looks impresive and I've never heard of it. Only 2 of my stations have 7
encoders so I guese I would set them up as single channel.With the addition of the 6 issolated relay module and the ones on the base I could cover my 14 max output. My question is how do I set up the MSG
block to pass info back and forth. I have heard it is better to read from than write to is this the same with ethernet.

There are MANY good MSG examples available from Allen Bradley. Here's one:

http://au.rockwellautomation.com/applications/gs/ap/gsau.nsf/pages/Messaging_in_a_MicroLogix_1100

As far as reading vs. writing, neither one is 'better': there is no difference in speed or reliability with the Ethernet. I would recommend you consider an architecture where the slaves communicate (write) to the master every time they have a change. Define a block of memory in your slave with all the data to be sent to the master and any time a change occurs for an item within the block, blast the whole block up to the master. There is no point in sending small chunks because the Ethernet has a minimum block size of around 1K anyhow.

Your other alternative is to have the master poll each slave in an infinite loop (a suck approach, vs the above blow approach). Its deterministic (good) but I prefer the 'blow' approach above because you get updates as soon as they occur and it scales great: add 100 slaves and you don't get killed by polling time.

Don't sweat the MSG: its amazingly easy. As in the above example, you just point to the block of registers you want to read or write from (and their length), give it the IP address of the other PLC to read or write to, and it works (sends/receives to/from the block of memory on the other PLC). If you do the 'blow' approach above, be sure to write a timer to keep from constantly sending new data each scan: send a maximum of once per second for example. That way you send immediately on the first change, but if you get another change, you wait another second to tell the master. So it keeps that one slave from hogging all the comms if you have a shared monitored input that goes nuts and oscillates.

I also set up a heartbeat register on every slave to force it to communicate at least once per second (just a bit in your shared block of memory that toggles once per second). Then, over on the master, I verify I get a comm from each slave once every five seconds or produce an error to the HMI that we lost comms to a slave: I use five seconds to avoid any nuisance complaints. That's way cool because you can basically tell the operator which Ethernet cable you're having a problem with. If you are putting an HMI at each station, I also send heartbeats once a second from the master to every slave: that will allow the HMI at each slave to complain if it loses comms from the master and it makes troubleshooting the Ethernet really easy by just looking at all the HMI's.

Sounds like the approch I will take. Got to pick up some hardware to set up a test. Been reading 1766-um001 from AB literature. Once I have a test unit communicating I'll be good to go, Thanks for the input.