OT: Can someone explain Rockwell versioning system

cardosocea said:

As for reliability, I haven't see an S7 CPU just throw in the towel and stop the entire installation. But I do have a CLX that decides to do this every six months.

Click to expand...

Wow. Elaborate? If I ever see something like that, in any brand I'll raise hell.

harryting said:

Wow. Elaborate? If I ever see something like that, in any brand I'll raise hell.

Click to expand...

ControlNet card over coax just decides to throw the towel and gives me a message saying there is an error in main.c at line 1453.

Called Rockwell support which is quite expensive and had a virtual shrug over email from them. I'm not a Rockwell shareholder, I don't raise hell or shout... I let them know I have a problem and expect them to provide value for the money paid.

When time comes to decide, that will be (and in my case was) part of the consideration.



For Rockwell, stuff like this ended up in a loss of about 2.5MUSD as we decided to go with Siemens instead.

V0N_hydro said:

dang I must be doing something wrong!

Click to expand...

Unless there's been changes and new revisions I haven't seen, going backwards for certain versions will require uninstalling Linx at least. And IIRC, I've hit other landmines. Better to start at the bottom IMHO.

V0N_hydro said:

dang I must be doing something wrong!

Click to expand...

Installing on VirtualBox takes me a couple of hours just one of them V30. My laptop got Intel 7, 32GB ram.

Yeah definitely both got their strengths and weaknesses. Biggest issue is the versions for me, is turning into like Adobe and their cloud licensing. Must be a better way to handle that kind of sad Tia is going the same way with their new version releases. Step7 worked for what nearly 20+ years with a few updates. Talk about over engineering just to make more money.

All they had to do is pricing for big companies and another for small businesses. Ain't nobody got time to install 30+ versions on one computer talk about wasting space. I haven't checked the folders but I wonder if it uses some stuff from previous installations.

harryting said:

Wow. Elaborate? If I ever see something like that, in any brand I'll raise hell.

Click to expand...

I've actually seen one contrologix stop due to someone calling an wrong array index, and the fault on the led display said just that.

On step7 the diagnostic buffer is more robust since programmers have control with OBs.

fredz0003 said:

Installing on VirtualBox takes me a couple of hours just one of them V30. My laptop got Intel 7, 32GB ram.

Yeah definitely both got their strengths and weaknesses. Biggest issue is the versions for me, is turning into like Adobe and their cloud licensing. Must be a better way to handle that kind of sad Tia is going the same way with their new version releases. Step7 worked for what nearly 20+ years with a few updates. Talk about over engineering just to make more money.

All they had to do is pricing for big companies and another for small businesses. Ain't nobody got time to install 30+ versions on one computer talk about wasting space. I haven't checked the folders but I wonder if it uses some stuff from previous installations.

Click to expand...

Virtualbox works just fine in general, but I've found it to be lacking as far as graphical capability and under heavier loads at times. Not having a dedicated GPU can really contribute to this. It also *seems* VMWare can perform much better when it comes down to it. There are lots of reasons your laptop could be faltering. It is likely a storage issue. Having solid-state storage makes a difference. Running your VM on a separate drive also makes a huge difference. It could also be that your i7 is only one of the dual-core low power mobile versions.


Those are pretty much the main reasons. As it comes down to it, I've always considered installing rockwell software to be an all-day job, but I don't constantly monitor it either.

cardosocea said:

RSLynx and the fact that you need to use. Siemens doesn't require you to hand hold the PC all the way to the CPU. It uses that little known thing called an IP address.

Click to expand...

That's a valid point, but the other side of the coin is that RSlinx allows you an enormous amount of flexibility in connecting to the PLC that you simply don't get with Siemens. With a Siemens PLC, if all you've got is the IP address, then that can make life a real headache if you're not connected directly into the same subnet or physical network as the PLC. Whereas, with RSLinx, you can get online with a PLC via 15 different networks and network mediums if that's your only route to the processor. A factory I worked at had a remote PLC (Machine A) that was nowhere near an ethernet network. It had its own self-contained ethernet network, on which where several VSD's, but this network was not connected to the plant network. Machine A needed to communicate with one other machine (Machine B), which it did via a ControlNet interface. Machine B has an ethernet card, but it's on a different subnet to the engineering workstation in the workshop. Now, one day I needed to do some manipulation of a VSD on machine A. If this were a Siemens installation, I'd have to dust off the laptop and get in the van, and drive to the remote PLC. Then I'd spend all day on the phone making small changes and having someone on the other end of the phone describe the results to me, until we got the results we were after. But it was AB, so using RSLinx, I could create an Ethernet driver, add the ENBT module of Machine B, bridge from there to the ControlNet module, go across the ControlNet network to Machine A, bridge from there to Machine A's ethernet network, get online with the PLC and tweak parameters in the drive without ever leaving the workshop.

That's just one example, but there are plenty of other ways where the flexibility and capacity of RSLinx has solved problems for me where a Siemens system has no such ability. That's not to say one is "better" than the other - as always, it depends on the application. Certainly, when it comes to getting online, Siemens is easier for a novice or intermediate user to figure out. But there's always a flip side.

As to PLC's crashing and stopping processes: blaming programmer errors like invalid array addressing, or physical faults on networks, is like blaming Ford because you drove your car into a wall while texting and driving, or because your mechanic messed up a service and you blew a head gasket. A PLC is only as smart as the person programming it.

ASF said:

That's just one example, but there are plenty of other ways where the flexibility and capacity of RSLinx has solved problems for me where a Siemens system has no such ability.

Click to expand...

Are you sure about that? Ever tried S7 Routing? You can even access drives or cpus on Profibus from the office Ethernet using S7 routing.

fredz0003 said:

Yeah definitely both got their strengths and weaknesses. Biggest issue is the versions for me, is turning into like Adobe and their cloud licensing. Must be a better way to handle that kind of sad Tia is going the same way with their new version releases. Step7 worked for what nearly 20+ years with a few updates. Talk about over engineering just to make more money.

Click to expand...

I agree. I don't like it either... however, the 300£/year isn't really bank breaking like Rockwell stuff usually is.

ASF said:

That's a valid point, but the other side of the coin is that RSlinx allows you an enormous amount of flexibility in connecting to the PLC that you simply don't get with Siemens. With a Siemens PLC, if all you've got is the IP address, then that can make life a real headache if you're not connected directly into the same subnet or physical network as the PLC. Whereas, with RSLinx, you can get online with a PLC via 15 different networks and network mediums if that's your only route to the processor. A factory I worked at had a remote PLC (Machine A) that was nowhere near an ethernet network. It had its own self-contained ethernet network, on which where several VSD's, but this network was not connected to the plant network. Machine A needed to communicate with one other machine (Machine B), which it did via a ControlNet interface. Machine B has an ethernet card, but it's on a different subnet to the engineering workstation in the workshop. Now, one day I needed to do some manipulation of a VSD on machine A. If this were a Siemens installation, I'd have to dust off the laptop and get in the van, and drive to the remote PLC. Then I'd spend all day on the phone making small changes and having someone on the other end of the phone describe the results to me, until we got the results we were after. But it was AB, so using RSLinx, I could create an Ethernet driver, add the ENBT module of Machine B, bridge from there to the ControlNet module, go across the ControlNet network to Machine A, bridge from there to Machine A's ethernet network, get online with the PLC and tweak parameters in the drive without ever leaving the workshop.

Click to expand...

Perhaps you haven't been exposed to all the strengths of Siemens... I've programmed a CPU that had a single Profibus connection to a larger CPU with the Ethernet card via Ethernet. It is doable, just that there isn't a dedicated piece of software for it (as Bratt pointed out in his post).
I don't mind RSLynx in itself, I just get ****ed off at how stupid it is that can't take an IP address and connect directly.
Also, your description of bridging networks sounds like a nightmare and one thing I wouldn't allow to happen. There's a reason why they're or should be separate.

ASF said:

As to PLC's crashing and stopping processes: blaming programmer errors like invalid array addressing, or physical faults on networks, is like blaming Ford because you drove your car into a wall while texting and driving, or because your mechanic messed up a service and you blew a head gasket. A PLC is only as smart as the person programming it.

Click to expand...

How do you manage to determine that it was a programming error causing my fault on main.c without looking into the program or the array? Rockwell however, had full access to the error message and software running on that PLC and didn't get to that, or any, conclusion.
Mind that the only thing on that Controlnet is IO that gets used regularly, not just once every six months... but like I said, Siemens at least had the forethought to consider that people make mistakes and has fault recovery built into their CPU's. A bad array index would call OB121 and move on as if nothing happened... and any other myriad of faults calls the appropriate OB and moves on.

fredz0003 said:

I've actually seen one contrologix stop due to someone calling an wrong array index, and the fault on the led display said just that.

On step7 the diagnostic buffer is more robust since programmers have control with OBs.

Click to expand...

I had that too. However, I would say that's a designed feature of the system. It's similar to the math overflow in the old SLC.

V0N_hydro said:

And of course you would have to start at the earliest version and work your way up to the newer versions since some part of it will barf when you try to install an older version of whatever microsoft dependency over a newer one. So good luck if you have version Z installed and discover you need Z-4, you will be uninstalling Z first.

Click to expand...

I've never had to worry about which version was already installed and you don't have to have version "14" to install version "15" (for example). You can install them in any order you need them in and you can install just the one's you need. If you need a lot of versions I could make the argument that you must be working on a lot of different Logix based systems and can justify spending a little bit of time installing the version of software you need. Although many of you won't like this argument but one has to remember that Rockwell, among other things, is a Software company not just a PLC/PAC company. When you buy a new computer you have to buy a new copy of Windows.

cardosocea said:

Perhaps you haven't been exposed to all the strengths of Siemens... I've programmed a CPU that had a single Profibus connection to a larger CPU with the Ethernet card via Ethernet. It is doable, just that there isn't a dedicated piece of software for it (as Bratt pointed out in his post).
I don't mind RSLynx in itself, I just get ****ed off at how stupid it is that can't take an IP address and connect directly.

Click to expand...

I'm definitely not as up-to-speed with Siemens as I am with Rockwell - I'd heard of the routing capability, but as far as I've toyed with it, it's not as flexible as RSLinx. That impression could be inaccurate, but regardless I stand by my opinion that RSLinx is incredibly powerful for something thought of so poorly by many. As to "just taking an IP address and getting online" - I would argue that there's very little difference in the complexity of that function between Siemens and AB, aside from the use of a separate application to do it. Assuming you're on the same subnet as the PLC you want to connect to:
- In Siemens, you bring up your connection window, select Ethernet, select the correct ethernet adaptor, type your IP address (or have it scan automatically, I think?), and away you go.
- In AB, you open up your RSLinx window, add an Ethernet/IP driver select the correct ethernet adaptor, and then your PLC will show up for going directly online. Or, you can use an Ethernet driver which requires you to specify the IP address, but not which network adaptor you're using to get there.
I can't see how one is any easier than the other, really. And because in AB, you can save the connection path as part of the project, once you set it up once it's easy from then on. Even if your path was a convoluted one bouncing across multiple networks, once you've set it up, you save to the project and then next time it's as simple as clicking "go online". Siemens may have that capability too; I'm not sure.

cardosocea said:

Also, your description of bridging networks sounds like a nightmare and one thing I wouldn't allow to happen. There's a reason why they're or should be separate.

Click to expand...

Perhaps its just my wording - the networks are indeed separate and I'm not having to create any type of "bridge" between networks to get there. I don't have to configure anything at all. It's just a matter of pointing from one device or module to the next, and as long as there's a physical/logical connection in place, I can pass through it. Another example: let's say I need to get online with a DeviceNet remote I/O block to change a configuration setting. I don't have a DeviceNet adaptor handy, but I know that somewhere on that DeviceNet network is a 1769 devicenet card in a remote Compact Logix rack. That Compact Logix rack has a 1769-AENTR at the start of it, so if I can get myself patched into the same network as that AENTR, then I can get online with the remote DeviceNet I/O block by directing RSLinx to set up a path to the IP address of the 1769-AENTR, then across the backplane to the 1769 DeviceNet module, then out onto the DeviceNet network and into the required I/O block by its DeviceNet address.

No matter what software I'm using (RSLogix, RSNetworx...) and no matter what device or what network medium is in the picture, I'm always using the same software (RSLinx) and the same techniques to get online with it. That's a huge advantage for ease of use in my mind.

cardosocea said:

How do you manage to determine that it was a programming error causing my fault on main.c without looking into the program or the array? Rockwell however, had full access to the error message and software running on that PLC and didn't get to that, or any, conclusion.
Mind that the only thing on that Controlnet is IO that gets used regularly, not just once every six months... but like I said, Siemens at least had the forethought to consider that people make mistakes and has fault recovery built into their CPU's. A bad array index would call OB121 and move on as if nothing happened... and any other myriad of faults calls the appropriate OB and moves on

Click to expand...

Someone else, not you, mentioned calling an invalid array and having a PLC crash. That's just sloppy programming and is 100% the fault of the programmer. It's happened to me at times too, and it's been 100% my own fault. Yes, you can have a Siemens PLC call OB121 and then move on if you wish - you can do the same thing in an AB controller with fault handler routines. By default Siemens and AB may act differently, but the capability is there in both.

I can't speak directly to your specific ControlNet issue, I'm more speaking from broad experience in the field, and of other posts on this forum. I've had hundreds of communication issues in the field. I'd say 20% are down to configuration problems with networking equipment, and 80% are due to physical level problems. It's all well and good to say "I ran Cat 6 cable and it tests out OK", but if you've run it next to VSD cables, or if you've run it 110m, or if you've bent it back on itself with too tight a radius to use up the extra length in a duct, well, you can't blame the AB (or Siemens) hardware for that. Likewise with forum posts for networking issues - most of the ones I read are eventually fixed by re-terminating cables, or using the correct terminating resistors, or the installation of a proper DeviceNet power supply. All communication networks across both Siemens and AB - be it Ethernet/IP or Profinet, DeviceNet or Profibus, ControlNet or DH+ - all are extraordinarily reliable and robust when installed and configured correctly. Sure, sometimes a comms module will fail or have problems. But the platform itself is rock solid.

ASF said:

As to "just taking an IP address and getting online" - I would argue that there's very little difference in the complexity of that function between Siemens and AB, aside from the use of a separate application to do it. Assuming you're on the same subnet as the PLC you want to connect to:
- In Siemens, you bring up your connection window, select Ethernet, select the correct ethernet adaptor, type your IP address (or have it scan automatically, I think?), and away you go.
- In AB, you open up your RSLinx window, add an Ethernet/IP driver select the correct ethernet adaptor, and then your PLC will show up for going directly online. Or, you can use an Ethernet driver which requires you to specify the IP address, but not which network adaptor you're using to get there.
I can't see how one is any easier than the other, really. And because in AB, you can save the connection path as part of the project, once you set it up once it's easy from then on. Even if your path was a convoluted one bouncing across multiple networks, once you've set it up, you save to the project and then next time it's as simple as clicking "go online". Siemens may have that capability too; I'm not sure.

Click to expand...

In Siemens, you configure your network connection once. It remembers that setting afterwards.
You then open your project, click go online and voila, you're online.
You can take your project to another computer with the network setting done, click go online and it works the same.
So I can open the same project from all my engineering stations in the plant and it communicates straight away.

With RSLynx that is not the case... also opening RSLynx is in itself a chore as it scans the network and takes forever.

Interesting the Siemens V AB, but l bet NO ONE is going to say AB is a cheaper alternative than Siemens and when the products are, lets just say to stop arguments equal, then AB isn't the best value out there and everyone knows they are ripping people off (but no one makes you buy it). Other company's give away software and there PLC's are cheap compared to both the major players, but guess what most people buy, S and AB

Just a side note on the RSLINX discession, one of the things I battled with when starting using Siemens PLC's was getting connected to the PLC for the first time and had to get hold of another software from Siemens called "Proneta.

I will not get into the quality of this software or how poorly it is designed or the fact that I need it in the first place