Micrologix 1400....

Brijm

Lifetime Supporting Member
Join Date
May 2006
Location
St. Marys, PA
Posts
645
Micrologix 1400....

I wanted to see, if anyone has used the Micrologix 1400 and what was your opinion of them. I have a small project, that will involve 3 PID loops from thermocouples, that I will be using for On-Off temp. control... I will also need to use 1 or 2 HSC's, for encoder feedback. There is a little bit of other I/O and display on a G308 HMI, but no other major logic functions.

The 1400 with analog, and a thermocouple module seems perfect, but not using them, I'm a little concerned about bogging down the processor. We us Micrologix 1000's and 1500's a lot, but have never done this type or processing with the smaller AB's.

Any Opinions?

-MUR
 
Used them for 4 or 5 projects now. It's just a ML1100 with more I/O, and you program it just like you would with ML1200. You shouldn't be worried at all. I havn't had any problems with them.

Edit: This is actually what my desk looks like atm:
(Thats two ML1400 on the right)

DSC00084.jpg
 
Last edited:
I use 1100's and 1400's daily, combined with Red Lion G303 and G308. The 1400 should be great for your application: I use an encoder on most of them and use Ethernet network hooking six of them together using messaging in our system. Works great and have dozens in the field.

Sorry for stating the obvious, but do be careful to purchase an encoder that does not exceed the frequency specs. And I'm ultra-paranoid about using short encoder cable lengths since the 1100/1400 only supports single ended signals from your encoder.

The 1100's have not been as reliable as the 1000's and 1500's - have had a handful of them die in the last year. Usually with the error that indicates it cannot recognize the input card in slot 1.

Also, the 1100's seem to just occasionally completely lose their program (an ASIC reset fault).
That may be a susceptibility to vibration unique to the 1100 so we have started to mount all our PLC's on rubber vibration mounts in our panels.
Hoping that fixes the problems and that's how we're mounting our 1400's now too.

The 1400's are too new to reach any conclusions about their reliability.

I especially like the RS485 port on the 1100 and 1400 - we use it to talk to Powerflex 4 drives. But the PLC messaging code to talk to the RS485 on the Powerflex 4 VFD's is ugly and a memory pig: it can suck up all your memory in a hurry depending on how many VFD's you're trying to talk to. And the modbus RS485 is S.L.O.W. (figure 100mS per VFD for just one read/write) so we don't use it for anything but capturing errors and automatically clearing faults.

Since the 1400 has two DF1 ports (one RS-232 and one RS232/RS485), I especially like that I can have the RS485 hooked to the PLC/VFD's, the Ethernet hooked to the Red Lion and can still do online updates to the DF1 port. Very nice.

The Ethernet on the 1100 and 1400 seems to be rock solid. Even with six of them networked together in our machines (total of 31 480V motors = 31 Powerflex 4 drives), we don't see the Ethernet hiccup at all. We use shielded VFD cord for all the motor wiring and keep wide separation of 480VAC and 24VDC - the Ethernet is fabulous. And this is even with daisychaining Ethernet switches through all the machines which is supposedly a bad thing, but it just works and works.

Even in intensive applications, we're seeing scan times of the 1100 and 1400 that rival the CompactLogix. I think the worst I've seen is 11mS on an 1100 and that's when I'm not being careful and have the memory 100% crammed with program. When I'm careful I've been able to keep every application under 7mS. I have completely quit worrying about performance with the 1100/1400: I've consistently run out of memory before performance was a problem. The 1400 fixes the memory problem (I don't have any scan times for a full program yet on a 1400 - I haven't filled one yet) . What a sweet brick!

We've quit using 1500's now and use the 1400's exclusively. They're less expensive, can handle 7 IO cards, have blazingly fast Ethernet, built-in support for encoders, and talk directly to our VFD's. Whats not to like?
 
Last edited:
Thanks for the input.... We use a lot of 1500's on our smaller controls. Haven't had much experience with the 1100's.

I'm thinking about using a 1400 in an upcoming control. Can you give me an idea, of what kind of scan times, I can expect? Similar to the 1500's (10-20 mSec)?
-MUR
 
I have not used the ML1400, but I have used the ML1100 with analog input and output cards. Be aware on the 1100 that the input resolution for the built-in analog inputs is lower than that of the analog cards. The built-in analog inputs have a resolution of 1024 counts - suitable for some applications and unsutable for others.

Another consideration to look at is the conversion speed of the analog cards.

BTW, I have had a G303 communicating with a ML1100 for over a year and have not had a single hiccup - I would definetely use that combo again if the situation arises.
 
Anyone have try out using ML1400 with Ultra1500 using PTO? I test on mine ML1400 it do not seem to be working, not sure if it the wiring or setting issue, but when I change mine controller to ML1500 it able to work with the same wiring just change of the ratio for the Ultra1500.
 
The 1400 has far more instructional capabilities than the 1100 so no point going back. Anything the SLC505 can do, 1400 can also do.
We are thinking about specifying all 1400 instead of SLC505 on future projects.
 
I use 1100's and 1400's daily, combined with Red Lion G303 and G308. The 1400 should be great for your application: I use an encoder on most of them and use Ethernet network hooking six of them together using messaging in our system. Works great and have dozens in the field.

Sorry for stating the obvious, but do be careful to purchase an encoder that does not exceed the frequency specs. And I'm ultra-paranoid about using short encoder cable lengths since the 1100/1400 only supports single ended signals from your encoder.

The 1100's have not been as reliable as the 1000's and 1500's - have had a handful of them die in the last year. Usually with the error that indicates it cannot recognize the input card in slot 1.

Also, the 1100's seem to just occasionally completely lose their program (an ASIC reset fault).
That may be a susceptibility to vibration unique to the 1100 so we have started to mount all our PLC's on rubber vibration mounts in our panels.
Hoping that fixes the problems and that's how we're mounting our 1400's now too.

The 1400's are too new to reach any conclusions about their reliability.

I especially like the RS485 port on the 1100 and 1400 - we use it to talk to Powerflex 4 drives. But the PLC messaging code to talk to the RS485 on the Powerflex 4 VFD's is ugly and a memory pig: it can suck up all your memory in a hurry depending on how many VFD's you're trying to talk to. And the modbus RS485 is S.L.O.W. (figure 100mS per VFD for just one read/write) so we don't use it for anything but capturing errors and automatically clearing faults.

Since the 1400 has two DF1 ports (one RS-232 and one RS232/RS485), I especially like that I can have the RS485 hooked to the PLC/VFD's, the Ethernet hooked to the Red Lion and can still do online updates to the DF1 port. Very nice.

The Ethernet on the 1100 and 1400 seems to be rock solid. Even with six of them networked together in our machines (total of 31 480V motors = 31 Powerflex 4 drives), we don't see the Ethernet hiccup at all. We use shielded VFD cord for all the motor wiring and keep wide separation of 480VAC and 24VDC - the Ethernet is fabulous. And this is even with daisychaining Ethernet switches through all the machines which is supposedly a bad thing, but it just works and works.

Even in intensive applications, we're seeing scan times of the 1100 and 1400 that rival the CompactLogix. I think the worst I've seen is 11mS on an 1100 and that's when I'm not being careful and have the memory 100% crammed with program. When I'm careful I've been able to keep every application under 7mS. I have completely quit worrying about performance with the 1100/1400: I've consistently run out of memory before performance was a problem. The 1400 fixes the memory problem (I don't have any scan times for a full program yet on a 1400 - I haven't filled one yet) . What a sweet brick!

We've quit using 1500's now and use the 1400's exclusively. They're less expensive, can handle 7 IO cards, have blazingly fast Ethernet, built-in support for encoders, and talk directly to our VFD's. Whats not to like?


If you could post some of your sample code, it could be a great reference, learning piece of information. I have only used a couple of the 1200's. Have a encoder connected that is used as a master reference and then using that to send a 0-10v signal to 3 drives to control the speed. 31 powerflex drives is pretty impressive. Are they networked together?
 
Example Code Micrologix 1100/1400 Modbus Powerflex 4

I know this is a real old thread but I have been meaning to put this example code online. So here it is.

Here is an extremely detailed example of code to read and write modbus registers from an Allen Bradley Micrologix 1100 or 1400 to an Allen Bradley Powerflex 4 drive using Modbus RTU serial explicit messaging.

I covered a number of the 'gotchas' that tend to bite you in the behind:
1) Clear msg data on first pass so you are not reading garbage

2) Oneshot code to clear faults we know are going to happen. In this case I knew that manually reversing the VFD would always cause a fault so here is some code to clear the fault and not bother the operator with that nuisance fault.

3) An example of writing the command word to four VFD's in succession. A DN or ER of the prior write allows the next write to continue (so one bad VFD don't spoil the whole bunch)

4) Follow that by reading the status words of each of the four VFDs, in succession. Note the 'trick' about clearing the status word if the read was unsuccesful (so we don't read stale data).

5)Now read each of the four drive's error code modbus registers.

6)Read the output current register of one of the VFDs.

7)Set a bit that we have finished reading and writing all the modbus registers in this loop so the loop can start over. On this PLC/VFD, it takes a little over 100mS for each modbus command to complete (I think I measured 140mS average for this PLC), so getting through one pass of this loop takes a LONG time. Such is serial modbus...

8) Another nifty 'trick': how to program your VFD directly from the PLC so you can walk up with a bare drive and get all the correct values jammed into the drive (except for the slight chicken and egg problem that you have to setup the drive for the correct modbus comms before you can talk at all). Note the logic around the 'Reached final VFD' boolean bit that properly handles the segway between the reading loop and the programming loop. And the latch that sees the HMI_PROGRAM_VFD command from the HMI, then latches that and cycles along until the programming cycle completes.

Example1100Msg-1.jpg Example1100Msg-2.jpg Example1100Msg-3.jpg Example1100Msg-5.jpg
 

Attachments

  • Example1100CodeForPF4.pdf
    69.6 KB · Views: 1,104
Last edited:
I don't like the micros from AB at all.

I would use a Unitronics V130 or V350

PLC with HMI for around 600 to 1000 dollars.

Oh and the software is free, and every PLC comes with a programing cable.

Now add up your AB investment.

Now look at the data tables in Unitronics and all the interseting things you can do with them. This one feature will change the way you program and even the way you think while programming.

Everything has limits of course, but I had done some pretty interesting things with these.
 
Hudda, This is a three year old thread that deals with a completely different subject. For future reference, you will probably get more responses by starting a new thread.

In the ML you want to write the the real time clock function file instead of writing to the S file registers. The function file has an RTC. prefix. You can reference RTC.YR, RTC.MON, RTC.DAY, RTC.HR, RTC.MIN, RTC.SEC and RTC.DOW. To open the function file from withing RSLogix500 click on Function Files under Controller in the project pane on the left hand side of your computer screen.
 
Last edited:
Hello,
I am planning to use Red Lion G303 with ML1100 for a project. Could anyone tell what cable I would need to connect ML1100 to the Red Lion G303? My setup would have the G303 connected to the internet.

Also, Does the G303 have the capabilities to send out emails (alarms and reports).

Thank You
Karthik
 

Similar Topics

Hi, I am working with a Micrologix 1400 model 1766-L32BXB. With no input wires connected to the “in12” thru “in19”, I am getting 24 volts while...
Replies
4
Views
173
Hi everyone, I hope I don't butcher this up, please feel free to critique me wherever if I do, I have an issue I would equate to "chasing...
Replies
4
Views
242
Hi everyone, I'm working on a project where I need to exchange data between a Siemens S7-1200 PLC and an Allen-Bradley MicroLogix 1400 PLC. The...
Replies
8
Views
485
I'm not super familiar with the Micrologix line of processors, but I am pretty familiar with RSLogix 500. I'm trying to simply copy a string to...
Replies
4
Views
262
I have a project using the Micrologix 1400 L32BXBA. i found in the manual which outputs are the Fast outputs. I know there are a few Fast inputs...
Replies
6
Views
278
Back
Top Bottom