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.
....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.
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.