Micrologix 1000: AIC required?

Hi all. I'm setting up a new application using an AB Micrologix. My customer doesn't permit the 1500 series, and the 500 series is way over the top for this very simple application. However, I do need a little more i/o than the 32 points offered by the 1761L32. So I figured on using a 10 i/o point 1000 series as an expansion unit, programming it with just a couple of MSG functions and some MOV blocks for the i/o. If this method is something that the rest of the world does every day, then the question is: Do I need to use an AIC between the two plcs, given that the recent 1761 models have DH-485 built-in? If the answer is no, then will I still need an AIC to communicate with the customer's existing plant via DH-485?

Thanks, Steve.

Don't think the ML1000 supports MSG instructions.............

It's time to move up to a Micrologix 1200 or 1500.

I would not rely on the control of I/O with MSG instructions, unless the I/O were nothing more than data collection or something of a non-critical nature (not controlling machine/process actions).



If you need the Micrologix to communicate with the rest of the plant's DH-485 network, you will need an AIC+.
If you plan to use the second ML1000 as an I/O rack and have the PLC's on DH-485, it would be best to have 2 AIC+'s so you will have an available port to connect a PC for online monitoring.

It's not "done all the time", but it is technically feasible to hook up a pair of MicroLogix 1000 controllers via DF1 Full Duplex protocol with a single cable, and to treat the second one as though it were an "I/O expander", or simply control the rest of the machine with it.

But when you have an expanable controller like the MicroLogix 1200 or 1500 available, why do it ?

I do not think it is wise to attempt a lot of MicroLogix 1000 <-> MicroLogix 1000 messaging on a DH485 network that you are also trying to use for plantwide integration and online monitoring.

ML1200 is the answer, supports upto 88 I/O, and you don't have the headaches.
One plc, one program, no networking issues etc.....
Time saved in applicaton development should more than offset additional hardware cost.


Just my two cents.

Ken

I agree with use the ML1200. But, if you are out of options, and the machine logic can be broken into 2 major sections without much information transfer between them then----you could break the logic into two major sectons and have a couple of go/no go bits transfered using un-used inputs and outputs for "I'm finshed go ahead etc.. If you need to transfer a lot of data, this won't work. Just an idea I have seen work, don't like it, but it can work if your'e out of options.
mg

Another vote for the ML1200.

regards.....casey

Kidblue said:

Don't think the ML1000 supports MSG instructions.............

Click to expand...

Micrologix 1000 User Manual, page 13-1:

"... series C or later Micrologix 1000 discrete controllers and all Micrologix 1000 analog controllers support the MSG instruction."

ML1200 also offer 2 comm ports.

Well, thanks everyone. I think the customer will go with a 1200 just waiting for confirmation. BTW, 93lt1, what do you regard as the weak point in using the MSG for i/o control? Why should it be any less reliable (if that's what you mean) than any other part of the plc program/hardware?

PLC scan times are in micro/milli seconds to work with I/O as close to real time as possible. Messaging is network dependent, seconds could pass before an update occurs.

Steve Kemp said:

BTW, 93lt1, what do you regard as the weak point in using the MSG for i/o control? Why should it be any less reliable (if that's what you mean) than any other part of the plc program/hardware?

Click to expand...

Well, first off, If you were talking AB's Remote I/O, Devicenet, Controlnet, or Ethernet/IP, I wouldn't worry. DH-485, DH+, etc. are not meant for I/O control.

I've had a couple bad experiences with DH-485. If you are planning to control I/O over the network, you want the update time to be as fast as possible. When DH-485 gets fully loaded with traffic, It starts acting very erratic, sometimes MSG's don't get through, sometimes they get through immediately, sometimes they take near 1 minute to complete, and eventually the whole network can stop communicating.

One of my bad experiences (the worst one) had several SLC's and Panelview's on a DH-485 network, which tied several "zones" of a conveyor system together. I was using the DH-485 for PLC<>Panelview comms, and PLC<>PLC comms for handshaking and non-critical data. All through the start-up, we would concentrate on one or two zones at a time for debug and all was working fine. It wasn't until first day of production that all the SLC's and Panelviews were powered up and communicating at the same time. When they were all powered up at the same time, it worked for about 30 minutes, but usually areas that were using the handshaking were running very slowly, then suddenly the network went down. Simply cycling power to 1 of the SLC's didn't help.

Luckily, we were able to hook-up some spare wires that went between panels to get a hard wired handshake beetween the two. This allowed us to split the DH-485 network into two managable sections and eliminate some of the PLC<>PLC traffic that was there.