ML1400 Series B change to series A in RSLogix500

Hi Guys,
I have a pretty old version of RSLogix500 v8.2. This version only has Micrlogix1400 Series A controllers, but the problem is now we can only get Micrologix1400 Series B Controllers FW11, so is it possible to program these as a Series A controller selected in RSLogix or would it give some kind of major/minor error code. I noticed in the help file that a major error occurs when a Series A controller is configured as Series B, but I'm not sure what happens vice-versa.
BTW RS-Linx is v2.54
Thanks in advance
BR
Anas
www.pakplc.com

Hi, I'm assuming by your post that you haven't purchased a Series B yet and would like to know before you do.


Just in case you don't know the minimum you should have:




For MicroLogix 1400 Series A:

• RSLogix 500 version 8.1 or later
• RSLinx Classic version 2.54

For MicroLogix 1400 Series B:

• RSLogix 500 version 8.3 or later
• RSLinx Classic version 2.54

There is no ControlFlash FRN update available to flash a Series A ML1400 to a Series B. Series A firmware can only be flashed up as far as FRN 7. A Series B ML1400 controller cannot be back flashed to a Series A revision.


From memory, when we had RSLogix500 v8.2, and the 1400 Series B controllers became available, we configured them as Series A for a period until we updated RSLogix500 to v8.3. It should work, except that the Series B hardware and firmware enhancements won't be available.
I'll try set a Series B controller project to A later in work to check, but I'm pretty sure that this is the case.
If you don't require any of the following you should be ok.


MicroLogix 1400 Series B Functionality

• Modbus TCP (Client/Server)
• DNP3 over IP (Refer online for device profile)
• Level 2 Compliance
• DNP3 Secure Authentication V.2.0
• Data Set
• File Transfer

Other Ethernet Enhancements

• Disable EtherNet/IP Incoming Connections
• Disable Duplicate IP Address Detection
• Unconnected EtherNet/IP Messaging

Other Series B Enhancements

• String (ST) file support in the CPW command.
• Indexed addressing support for ASCII (A) file elements.
• Ladder logic access to the first word in Control (R) file elements.
• Ladder logic access to SMTP configuration parameters, including destination email addresses.
• Optional Recipe (RCP) file protection from downloads and memory module transfers

Configuring Series B for a Series A will indeed major fault the controller. Also, if the correct Series is selected, but the wrong Base type is selected, such as BWA instead of BXB, it will also major fault.



Is upgrading your RSLogix500 to v8.4 (latest) not an option?

I programmed many MicroLogix 1400 Series B as Series A in the past. And I think one of my coworkers still may be doing so. There is no downside unless you really need one of the minor updates done to the firmware.

The only problem I ever had was an older version of RSLinx not recognizing the ML1400 Series B when communicating over Ethernet. But I just updated RSLinx for that. The older RSLinx still worked fine when using serial DF1 comms.

Also, I did not believe you could tell RSLogix what "base" the ML1400 was. There is no selection for BXB/BWA, etc. There is just "MicroLogix 1400 Series A" and "MicroLogix Series B". In all my experience, even with the 1200s, RSLogix500 didn't care what base 1200/1400 you had.

Ok, in work now. In a 1400 Series B project I'm working on at the moment, under "Controller Properties", I've changed the Processor Type to "MicroLogix 1400 Series A", saved and downloaded to test PLC. It downloaded ok, as I thought, but warned me of a change to the communication configuration with "Apply", "Don't Apply" message etc.
This is an example of losing Series B features when configuring a Series B as a Series A. Have a look at one of your Series A projects. Go to "Channel Configuration", then "Channel 1" Ethernet tab. Specifically the bottom half "Protocol Control". Series A has "BOOTP","DHCP","SNMP","HTTP" & "SMTP" Enable check boxes. When you configure for Series B, four more check boxes are added in the space beneath "SMTP Client Enable". They are:

"DNP3 over IP Enable"
"Modbus TCP Enable"
"Disable Ethernet/IP Incoming Connections"
"Disable Duplicate IP Address Detection"

So when I changed down to Series A and tried to download, RSLogix500 realised this difference in the communications configuration and warned me about it.

So answer is definitely yes, if you don't require DNP3 over IP or Modbus TCP.

Tharon said:

....I did not believe you could tell RSLogix what "base" the ML1400 was. There is no selection for BXB/BWA, etc. There is just "MicroLogix 1400 Series A" and "MicroLogix Series B". In all my experience, even with the 1200s, RSLogix500 didn't care what base 1200/1400 you had.

Click to expand...

With all due respect to your experience Tharon, you can change it and RSLogix500 cares very much what base the controller is. This is how it defines the correct I/O for the base. The "MicroLogix 1400 Series B" selection is the "Processor Type", not Base type. Most users never know about it because they only ever use "Read IO Config." to define their base/chassis or drag/drop into the chassis slot list.
If you start a new project and select your "Processor Type" as say, "MicroLogix 1400 Series B", then go to "I/O configuration" and highlight slot zero, which represents the 1400's embedded I/O (Base). The "Adv Config" button is now available. This, by the way, is where you configure any advanced parameters of speciality I/O modules, such as analog, Thermocouple or RTD. A quicker way to bring up the "Adv Config" window is to double-click a slot. I just explained the slow way first to draw your attention to the "Adv Config" button. In here under the "Embedded General Configuration" tab, you will see "Base/Type" drop down box. The default is "Any Discrete Base". The "Read I/O Config." pulls in the base type from the controller and changes this default to the correct base type. The default is fine if you're only using discrete I/O on the base. You may be building a project without any hardware infront of you and want to select the exact base type you will be using the project with. Also change the "Size" from "Any" to "32pt".

This bit is important: The "Series/Rev/Functionality Type" is at "A". This is the Revision, not the Series of the controller. The 1400 in question is a 1766-L32BWA Series B Revision A. Lots of people get this mixed up, assuming its the Series...Including Rockwell! If you set this to B on a Ser B Rev A controller, it will fault. Major Error S:6=52h "The base minimum series selected in the user program configuration was greater than the series on the actual base." This Error Description should state revision, not series. If you change the B back to A the fault is gone. Also, if you look up the Tech Connect solution for error 52h, which is not free, so I wont elaborate too much, they tell you to do an auto read. This should solve it, but the correct solution is to find your controllers revision from the label on the side for this setting. But this is mentioned in the solution for 51h! Which is the error for wrong base type selected (BWA,AWAA etc). I think what happened is the original error and its message was assumed to be a Series mismatch, when in fact its a Revision mismatch. This was fine when we only had Series A controllers. After Series B controllers arrived the confusion arose. People started setting this to B, to match controllers Series, which is then higher than revision A, triggering the error, which states the series is mismatched, loop the loop stuff.

It's like they couldn't decide what to call that setting when developing RSLogix500, so they called it "Series/Rev/Functionality Type Yokeemaathingybob" until someone figures out which it actually is? That's my two cents on it anyway.

If you have to create a project for a base/chassis that doesn't exist yet, or is somewhere else and you will be using say, an analog 1400 (BWAA), which requires specific input filtering in the advanced parameters. You can have all this done in advance in the offline project by selecting the correct base type. Once the base type is selected the relevant advanced parameters are available under the next tab "Embedded IO Configuration". You could be sending a project to someone with basic knowledge, who wouldn't know how to read or configure the chassis configuration correctly on-site, but can do downloads/uploads. It's there for a reason. It's just most don't need it, or know about it, as they will be online to the base/chassis themselves at some stage to configure it automatically.

Just be careful when predefining a base/chassis configuration to develop a project before you have the hardware. It has to match the finished hardware config exactly or all your addresses will be offset.

Also, in the "Adv config" window for the base slot 0, the third tab "Generic Extra Data Config" is used to configure the advanced parameters of a generic analog module that is not in the catalog list. If you are using an analog module from the list, the same parameters display here in Decimal/Hex/BCD. The base configuration is also displayed here likewise. I won't expand any further.

Tip of the day:
Normally, ladder logic cannot exist for I/O addresses that are not present in the defined chassis. So you cannot write the full program, verify, download and test until you have the full complement of hardware for the project.
If you want to define the chassis configuration with modules you don't yet have, you can still download the project to the base for testing without faulting on I/O configuration mismatch.
In "IO Configuration", drag over the module you want to the required slot, then double-click the module to get "Expansion General Configuration". Select "Ignore Configuration Error" at bottom.
Once all "virtual" modules are set for this, you can fill the chassis if need be, complete the projects logic and download with no fault. You can even test I/O from the ladder logic for the "virtual" modules and the I/O Data Files will reflect the changes. You can also use the Force Files. Don't forget to set them back when the hardware IS present"

p.s. I always try to write replies in a manner that can help the OP and any others along the way. So all above is not assuming you didn't know any of it. Its for the benefit of others that may seek out similar assistance.

G.

Thank you guys for the very helpful posts.
@Tharon: we can change the base address in RSLogix500 as Geospark pointed out.

@Geospark: thank you very much for going out of the way and experimenting it for me.
We do not require series B functionality Enhancements, so I think I will proceed with ordering ML1400 controllers.
We have to make four of these units and I wanted to be sure before buying.
Really appreciate the help.
Thank you once again.

Your very welome.
Have you worked with any ML1400's before then?
Important considerations for now and future...

I don't know your intended application for the ML1400, but don't rule out other newer options that may suit your needs, or future proof you, better. I whole heartedly stand over the ML1400 as an excellent feature rich PLC controller, for any small to mid sized applications. But certain features are not supported, such as real-time I/O messaging (implicit CIP Ethernet), so no 1734PointI/O support, integrated motion, High Speed Counter (HSC) modules, DLR networks. Again if your application is mainly discrete, only needs some HSC and analog, the ML1400 will do. But you never know what's around the corner. "That machine runs great now, but can we do this, add that?"..."Err no, I'll have to change the PLC I just bought 6months ago boss". MicroLogix', SLC's, actually PLC's are old. RSLogix500 is old and being phased out, not at the software level, but at the hardware level. Hardware is no longer being designed for this platform. Another few years 500 will be the software you have to crank open and try remember what's what? Even RSLogix5000 has been replaced. PLC's are being replaced with PAC's (Programmable Automation Controllers). They require RSLogix5000 v20 minimum, but yet a newer software has been released along side these PAC's to rebrand RSLogix5000, namely Logix Designer. This is part of a new Studio 5000 package which is the new software platform for all Logix5000 controllers. The older software/hardware will still be around for some years yet and supported. This is just the direction AB/Rockwell are heading.
The newer PAC range, 5370 controllers (L1,L2,L3) are the closest and latest offering to replace the above mentioned PLC's. They offer large expansion options using 1734PointI/O(L1) or 1769CompactLogix(L2,L3) expansion modules. Integrated multi-axis motion control, dual Ethernet ports, Device Level Ring networking, no batteries, USB, SD Flash cards, larger user memory, easier connection to devices like printers, barcode readers, etc. Lots to like.
They are a little bit more expensive compared to MicroLogix. I can get 1400's for <€500 this side of the pond, and L1's for €800+. I haven't got my hands on one yet, but I have seen them at an automation fair last year. I'm seriously considering them from now on instead of ML1400's. I'm hoping to get one soon to play with. The biggest jump for users is from RSLogix500 to RSLogix5000, if your not used to programming with 5000, but that's where they're pushing users.

G.

No, actually this is the first time I am working on ML1400, although I have worked on ML1100,1200, slc5/03, 5/05 and compactlogix 1769 L33, before.
My current application is controlling a MOSFET based power module, that controls power flow from a battery. This is Lab Testing equipment for a battery manufacturer. So application requires: PWM output, data-logging feature, modbus slave compatibility and a couple of discrete functions.
And yes I am aware of the compact logix 5370 processors, they have some pretty neat features. But they are almost 150% the price of ML series, and add to that software cost of RSLogix5000, I dont think we can change platform in the next year or so for our standard applications, unless we get stuck.
Although I really like the tag based addressing in RSLogix5000, saves a lot of hassle.
Anas
www.pakplc.com

The 1400 will do you fine. Cost restraints are the main reason we use so many MicroLogix. We even have them controlling full production lines, but its mainly discrete I/O. We use 1769-L32 Compacts on more complex applications & some SLCs knocking around. My company is US owned & stipulates AB for all our controllers.

Thanks Geospark for all your input!! I just replaced a 1747-L40A with a ML-1400 B... I ended up using RS500 V.9 ... V8.10 scared me. I've used 8.10 before on simple systems and let it assume it was an A series.

The only problem I have, each time, is remembering the addressing differences. The BRICK has 0 thru 23 inputs and 0 thru 15 outputs. The ML-1400 has 0 thru 19 inputs and 0 thru 11 outputs. So, we had to add a 1762-IA8 input module, and a 1762-OW8 output module. The addressing differences had me going for a bit... (no pun intended) because the address display on the input and output tables for the BRICK program was I:0.0/0 and O:0.0/0 etc. BUT the ML1400 defaulted to I:0/0 thru I:0/127 for the MAIN RACK. The input module ended up with: I:1/0 thru I:1/7. The ML1400 outputs ended up with: O:0/0 thru O:0/95 for the MAIN RACK. The output module ended up as: O:2/0 thru O:2/7. At first I thought I had bad cards because I initially assigned my new addressing for the Input module as I:0.1/0 and onward, and my output module as O:0.1/0. BOY WAS I WAY OFF. I figured it out by forcing I-O and was shocked to see the new output module at the bottom of the I-O table on the row : 0:2.0 and the first one was : O:2/0

I work with a lot of brands rescuing down systems and the like so sometimes I have to "relearn" or go back and look at my notes for something I did in prior years. That's what I LOVE ABOUT THIS FORUM... they don't delete the old posts. Sometimes I work on DOS and MEGABASIC and such... thankfully there are lots of notes on these old systems.

In this case, to me, it is cutting edge stuff (I know not really, but for me it is) so again, Thanks!!!

Is there any other way to enable Modbus TCP? That's only thing I need.
I have rs500 8.10 and ml1400 series B.
There's no Modbus TCP Enable checkbox on channel..

I didn't try, but I suppose that rs500 v9 recognizes series B. My question does not include rs500 v9.

You need RSLogix 500 version 8.3 or higher to support the Series B controller, and therefore to enable Modbus/TCP.

That feature just doesn't exist in the Series A controller, and you should not have a MicroLogix 1400 Series B in your controller selection menu if you only have RSLogix 500 version 8.10.