Advice Needed - Siemens from Rockwell move

Hello gents,

I've started with Siemens PLC's about 10 years ago and worked with Step7, TIA Portal and am now involved with PCS7. The PLC's I used were the 300 and 400 range in complex machinery that was networked to achieve a goal. The language I'm most comfortable with is STL, although I use SCL and have learned to use PLC's with Ladder.

I had a contact with a company recently and am in a position to get a job with them... my problem is that apart from a couple of packing machines, the plant runs on Allen Bradley.

Now I'm wondering, realistically, how easy would it be to pick up on Allen Bradley PLC's coming from a Siemens world. Any of you have any tips or pointers to get started? What would be the biggest differences? What will be cool in AB compared with Siemens?

I'm always interested in learning and using something different will definitely not look bad in my CV either.

Please, let's not discuss on which platform or language is best. They both have strong points and it's not down to my personal preference.

Thanks in advance.

Once you'd mastered Siemens I believe you will do just fine with AB.

Siemens' STL is a close cousin of Rockwell's ST; LAD is quite similar, however instructions might differ as defined or functionally; Siemens's FB/FCs could be related to Rockwell's AOIs.

Data access and communications are handled quite differently on RA platforms and the I/O scan vs. program scan asynchronous approach will be the tallest obstacle you will have to conquer.

There is a S7 to Logix5000 migration solution you might want to study; it will give you some insight about functional differences and/or similarities between the two platforms.

http://literature.rockwellautomation.com/idc/groups/literature/documents/ap/logix-ap008_-en-p.pdf

I did the very same thing about 10 months ago. I wish I did it years earlier!

AB just works, I don't have any comms issues or FW issues like I used to with Siemens. We do the odd job with Siemens and TIA just seems so slow now compared to Studio 5000.

The support is much better and the supply chain is so much more useful (Compare Routico to Parmley G is no contest)

I used to use SCL but it is so bad in AB that I have reverted back to ladder. That said, the ladder editor in Studio is much better than Siemens though.

I much prefer AB now and I never thought I would say that. I collected my new loaded up work laptop about 2 weeks before I started and just had a play, it didn't take long to figure it out. After all, it is made by Americans for Americans, no offence intended.

It certainly is no cause for stress to make the change. I would be interested to know how you get on.

Thanks for the info.

I read a bit on the IO scan but didn't quite understood if this is something we can control or if it's just done a different way and which way it is.
Either way, on Siemens I'm used to buffer IO into DB's for portability so that shouldn't be an issue.

I do admit that the comms in Siemens are a bit clunky...

From what I know the company has plenty of small processes and not one large process, so ladder will most likely be the better choice (as normally is to avoid getting out of bed), however I stress a little bit if I need to do something requiring an array or complex calculations...

They should call me up on Monday to let me know if they want another interview or not.

Does Rockwell have a demo version of their software to get my bearings?

cardosocea said:

Thanks for the info.

I read a bit on the IO scan but didn't quite understood if this is something we can control or if it's just done a different way and which way it is.
Either way, on Siemens I'm used to buffer IO into DB's for portability so that shouldn't be an issue.

I do admit that the comms in Siemens are a bit clunky...

From what I know the company has plenty of small processes and not one large process, so ladder will most likely be the better choice (as normally is to avoid getting out of bed), however I stress a little bit if I need to do something requiring an array or complex calculations...

They should call me up on Monday to let me know if they want another interview or not.

Does Rockwell have a demo version of their software to get my bearings?

Click to expand...

Well, Rockwell Logix Class CPUs are not PLCs but multi-threaded automation controllers.

Any other existing PLC within any other existing platform (including all Siemens CPUs) are single-thread, colloquially described as "circle runners": Read Inputs -> Scan Program -> Set Outputs.

Rockwell controllers have a separate tier for I/O processing (including any I/O Class communications); it is independent of the application "layer" and the data exchange rate (RPI=Requested Packet Interval) is a user defined constant.

If not accounted for within the user application, the variable timing program scan might miss an Input change-of-state or fail to promptly set an Output at the end of the scan resulting it.

There are several techniques for avoiding I/O scan issues and they are described within the above posted document link.

I see...
Is this RPI a single value or is this configurable per IO block?

Siemens has an interesting particularity about this that I only dug in when picking up on PCS7. PCS7 philosophy dictactes that the user application should be inside the cyclic OB's to simulate threaded behavior (although there is only one processor).

Depending on the program, this can cause issues with the IO if one doesn't configure when the IO is to be updated. If left by default, the IO is updated at the end of each OB1 cycle.
But OB1 has less priority than any other cyclic OB, meaning that there is potential to miss the Process image update.
For this reason, one can define IO blocks to be updated at the beginning of each cyclic OB for updating the IO table.

Not the same, but interesting to know about this... and definitely explains why the buffering I've seen in some programs.

cardosocea said:

I see...
Is this RPI a single value or is this configurable per IO block?

Siemens has an interesting particularity about this that I only dug in when picking up on PCS7. PCS7 philosophy dictactes that the user application should be inside the cyclic OB's to simulate threaded behavior (although there is only one processor).

Depending on the program, this can cause issues with the IO if one doesn't configure when the IO is to be updated. If left by default, the IO is updated at the end of each OB1 cycle.
But OB1 has less priority than any other cyclic OB, meaning that there is potential to miss the Process image update.
For this reason, one can define IO blocks to be updated at the beginning of each cyclic OB for updating the IO table.

Not the same, but interesting to know about this... and definitely explains why the buffering I've seen in some programs.

Click to expand...

The RPI is set when the modules are added to a application and yes, it is unique for each configured module; for example, a user might want to RPI an Input Module every 5ms while an Analog Module might be RPIed every 250ms. There is a default value at the add-on time which usually suffices most applications, however, again, it is constant and it does not get "snap-shot" prior to the program scan (or set at the end of it for Outputs); Logix I/O updates at the set RPI no matter how long the tasks where they are being called take to complete.

In order to avoid PLC like programming Logix I/O issues some use "buffering" (I/O Mapping in Rockwell world) and some use Periodic Tasks, tasks which's periods are "synchronized" with the relevant I/O RPI setting; you could even call an entire Event Task depending of the state of an Input.

Having only had minor intrusions into Siemens and working in a plant that has 90% Allen Bradley/Rockwell PLCs, Rockwell are easier to deal with.

The thing to think about is the different generations of Rockwell/AB PLCs and their I/O. They have their quirks...RIO/ControlNet/DeviceNet/Ethernet...
PLC5/SLC/Micrologix/CompactLogix/ControlLogix....and the software is different...PLC5/SLC/Micro are ladder and use Address files (binary/float/integer/timer etc etc ) and you create them in advance, but you can edit logic rungs online whilst running the PLC, whereas the Compact/ControlLogix are tag based and you can create/modify these tags and your ladder logic on the run...

or you can program offline and download the modified code (the entire project) to the PLC.