Maintaining a dual standard for both A-B and Siemens

[SysIntegrator]

Hello Everyone,

I just wanted to get some opinions on how to best approach a long-term project I'm going to embark on. I'm taking on a project where I'll be utilizing a Siemens S7-1518-4 PN/DP. I haven't worked with TIA portal much but I've used Simatic Manager extensively. The project will be a precedent and will likely be used for reference for many future projects so I wish to do it right the first time and establish a good standard. For reference, I'll be looking at and converting code from past projects, most of which will have been MBII or VME, written in either C, CFC, or something else non IEC-61131-3.

Additionally, in the very near future, I'll be replicating this on an Allen-Bradley ControlLogix PLC (1756-L85E or something similar). So what I'd like to do is write the code in such a way it can easily be converted to RSLogix5000 and both standards dually maintained in a reasonable way (sounds easy, right?).

The automation itself is fairly complicated and previously hasn't been done in standard PLC's due to performance requirements (Motion control with lots of advanced math), handling all the code in just Ladder/STL/FB isn't feasible. So I'm thinking my challenges are:
1) Converting existing C code and CFC libraries to TIA Portal/RSLogix
2) Choosing languages that work in both TIA Portal/RSLogix
3) Maintaining this code in the future

Honestly, I don't think there's a ton of options, I think I'll have to rely heavily on SCL/Structured Text for the advanced math and Ladder for all the boolean logic. I don't think Siemens has a package for CFC in TIA Portal, otherwise that'd have been the easiest conversion (but wouldn't port well to A-B anyways). I've also seen Siemens's S7-1518-4 PN/DP ODK allows development in C, which makes the conversion easier, however I don't think anything equivalently exists for A-B? Are there any better options I haven't considered?

 

[AutoMax]

If your application includes motion, forget commonality between Siemens and Rockwell. If you used a separate motion controller as a slave to an S7 or ControlLogix you could keep the PLC code similar between the two.

 

[SysIntegrator]

Yeah, the motion implementation is still in consideration, we're talking to Siemens applications. Possibly the addition of one of the motion controllers (S7-1517T??) might also be implemented, but even still there's a huge amount of software that will still exist in a standard PLC.

 

[Peter Nachtwey]

If your application includes motion, forget commonality between Siemens and Rockwell. If you used a separate motion controller as a slave to an S7 or ControlLogix you could keep the PLC code similar between the two.

Yes, the interface to our RMC motion controllers is the same for Siemens Profinet and Rockwell Ethernet/ip. There is just a block of registers that is mapped as I/O. The code is common but most code should be on the RMC itself. This simplifies the PLC code for both controller brands.

 

[mk42]

What I've seen is that when you're going for a dual standard, there's a spectrum:

At one end, you follow best practices in both/all brands, and re-implement the program for each new system. This usually seems like more work, but it often ends up being quicker. It typically results in more complicated user documentation (or at least the management of it) but cleaner code.

At the other end, you use lowest common denominator features shared among all brands. This typically means that you're stuck in LAD, and often have limited ability to use modular code like you'd expect from PC programming. This involves a lot of work up front, to define the spec and ensure all needed capabilities are available on all platforms.

In reality you'll end up somewhere in they grey area in the middle, but you need to figure out what you need to do, what you can do in each system, and what makes sense

As others have said, Motion is definitely one of the places where there is little overlap. The more processing you can offload from the PLC the better, assuming that you can keep the rest of the components the same and just swap out the PLC. I usually see situations where customers with a "firm brand spec" are very firm on the PLC, but were quite flexible on everything else. I'm sure your Siemens guy has told you that a lot of the Siemens HW (HMI, Drive, Networking) support EIP in addition to Profinet, and the same is true of most major players (except AB of course).

 

[SysIntegrator]

What I've seen is that when you're going for a dual standard, there's a spectrum:

At one end, you follow best practices in both/all brands, and re-implement the program for each new system. This usually seems like more work, but it often ends up being quicker. It typically results in more complicated user documentation (or at least the management of it) but cleaner code.

At the other end, you use lowest common denominator features shared among all brands. This typically means that you're stuck in LAD, and often have limited ability to use modular code like you'd expect from PC programming. This involves a lot of work up front, to define the spec and ensure all needed capabilities are available on all platforms.

In reality you'll end up somewhere in they grey area in the middle, but you need to figure out what you need to do, what you can do in each system, and what makes sense

As others have said, Motion is definitely one of the places where there is little overlap. The more processing you can offload from the PLC the better, assuming that you can keep the rest of the components the same and just swap out the PLC. I usually see situations where customers with a "firm brand spec" are very firm on the PLC, but were quite flexible on everything else. I'm sure your Siemens guy has told you that a lot of the Siemens HW (HMI, Drive, Networking) support EIP in addition to Profinet, and the same is true of most major players (except AB of course).

I think that's a good breakdown of my options. The route will likely be option #1, however, thinking the most 'common denominator' is SCL, I'll probably implement a lot of blocks in SCL and write them in a way that's transferable. I've never actually messed with RSLogix's Structured text, but copy pasting of text always works better than any type of exporting and importing of ladder/FBD.

 

[mk42]

I think that's a good breakdown of my options. The route will likely be option #1, however, thinking the most 'common denominator' is SCL, I'll probably implement a lot of blocks in SCL and write them in a way that's transferable. I've never actually messed with RSLogix's Structured text, but copy pasting of text always works better than any type of exporting and importing of ladder/FBD.

I haven't explored ST in Logix too much, but from what I've heard the main gotcha in converting is doing find/replace on all the tagnames. Hypothetically, ST is ST across brands, but there are always little implementation differences. The trick I remember was changing controller scope tags into DB tags (obviously they all needed to be created first). It's easy enough with find and replace, but wasn't a simple copy/paste. I recall Program tags into Local tags being simpler.

I don't think Siemens supports breakpoints in ST/SCL in the 1500s, so that might be a troubleshooting gotcha if you're expecting those.

 

[kekrahulik]

+1 for Peter Nachtwey

I've never dealt with RMC controllers, but it really sounds like you are in "dedicated motion controller" territory. I would be concerned that AB and Siemens will fall short of your performance needs.

 

[mk42]

+1 for Peter Nachtwey

I've never dealt with RMC controllers, but it really sounds like you are in "dedicated motion controller" territory. I would be concerned that AB and Siemens will fall short of your performance needs.

OP hasn't said what his motion needs are, but Siemens for sure has multiple dedicated motion controllers in addition to the motion that can be done inside the PLCs. Simotion is used for general coordinated motion (up to 128 axes, I think, depending on model?), and the 840D is used for CNCs. Not sure what AB has.

 

[AutoMax]

I think that's a good breakdown of my options. The route will likely be option #1, however, thinking the most 'common denominator' is SCL, I'll probably implement a lot of blocks in SCL and write them in a way that's transferable. I've never actually messed with RSLogix's Structured text, but copy pasting of text always works better than any type of exporting and importing of ladder/FBD.

The only (kind of) commonality you'll find between SCL and AB ST is basic boolean logic and math. I'm all for doing the math in text, but if you do the boolean in text you're going to have some extremely annoyed maintenance electricians and probably won't get many repeat customers. On the other hand, you might get lots of service calls...

 

[SysIntegrator]

Thanks for the feedback guys. Maybe I oversold the motion control requirements, there won't be that many axes and actually most of the control will be hydraulic with servo valves. However, there is plenty of math which is why I am looking for programming language with the most common ground.

It might come down to me writing some sample code in all three languages then re-writing in A-B to see what ports the easiest. I will make a pretty strong effort to separate boolean logic and mathmatical operations. Maybe the more math-based blocks will stay in SCL and boolean will be reserved for ladder.