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