Hi everyone.

First of all, I'd like to thank all the Wago experts I have PMed regarding this subject and am now opening this to everyone. Hopefully I can get a solution.

I am quite new to PLC programming, my background is embbeded devices MMI modification. I have been tasked to program a Wago 750-841 ethernet controller connected to several I/O cards.

After 1 month of programming, something occured to me and my superior. When a Wago IO card fails, all the I/Os connected to the entire PLC go dead. This is not a very desireable outcome as the PLC controls Marine equipment, and reliability is a key concern.

Is there a way to allow the remaining IO cards to continue to function or is this norm for Wago PLCs?

Wago was selected for is modularity, compact size and marine certification.

If there is no workaround I may need to change PLCs. I do not wish to waste all the man hours invested so far.

Thanks a lot for the advice.

 

This is not a peculiarity of the Wago 750 series. This is true of ANY i/o or PLC. If the i/o controller (or PLC) dies, then the i/o dies. Period. When using any Fieldbus i/o, when the controller dies the i/o dies. Period. If you want to drop low enough then if a relay fails then the i/o on that relay fails. I have used the Wago Modbus TCP stuff in a number of projects and been very satisfied with it.

What happens when the controller (or any i/o) dies is your responsibility as the programmer. You should include in your error checking routine a confirmation that the i/o is working. If it is not, then you issue a fault and respond to that in whatever manner is suitable for your machine.

Davis Gentry Senior Applications Engineer Delta Tau Data Systems

 

I have to disagree with Davis Gentry:
"If the i/o controller (or PLC) dies, then the i/o dies. Period."

Yes, that's accurate, but it wasn't the question:

"When a Wago IO card fails, all the I/Os connected to the entire PLC go dead."

So it's not the CONTROLLER that dies, it's just one I/O card. The problem here is the Wago connection style. Each card connects to the next, without an independent backplane. So when a card goes out it takes the whole system with it. Compare this to a "traditional" PLC chasis, e.g. PLC/5, Quantum, ControlLogix, etc. Logix and other modern backplane / chasis based PLCs can handle a card dying and being hot-swapped out.

Incidentally, this problem is true of most chasis-less I/O types out there. This is a trade-off the big, expensive "classic" PLC design versus the modern "big PLC power in a tiny little box" design.

I would call Wago directly to ask them about this. If you want to take this off-line I can give you the contact info of a good technical resource at Wago. But I think you're out of luck.

-James Ingraham
Sage Automation, Inc.
www.sagerobot.com

 

I have yet to see any single point fieldbus i/o out there. So every one with which I have worked has had some kind of controller (transceiver) which, if it dies, takes out all of the i/o attached to that transceiver. This includes:

Wago
Phoenix Contact
Turck
GE

The same thing happens if you lose the controller in any PLC rack as well. If the original poster is saying that he has multiple
Wago controllers acting as slaves, and that when one of the controllers dies all of the i/o dies then that would definitely be a problem. That is not, however, what I understand him to be saying. I believe that he is saying that when the Wago controller on a rack dies then all of the i/o on that rack is now dead. In which case I stand by my original response.

Can the original poster clarify?

Davis Gentry

 

Hi Davis and James,

Thanks for replying.
I was taking Davis's advice and doing a I/O checking FB for my DO and AI. so I didnt really check in for a couple of days, sorry.

Hi Davis, To clarify, the system is a single fieldbus controller with several IO cards attached (we are looking into splitting the config by using bus extension modules for power reasons). I am talking about the IO Card failing, not the fieldbus controller. I think there maybe no way to save a configuration if the controller dies. Unless there is a way to set "defaulted states" in a PLC card when it detects no controller. Sounds too advanced for a PLC to me, please correct me if I am wrong. (We are not looking at redundant controller configs just yet.)

Hi James, thanks for the enlightenment, I wondered why some of the "traditional" PLCs have backplanes. So a backplane not only serves to provide power and physical mounting, it also acts as the communications bus. But what about addressing? How do the more robust PLCs deal with addressing if a card fails? Since "hotswapping" can be performed, there must be some catering for addressing right?

The Wago staff I have PMed recommended using a DI or DO Offset FB. I do not understand the purpose of using the Offset block. I was able to replicate the demonstration provided by the staff but after removing the cards so that the configuration is different from the program, the PLC IO did not funtion. (This was performed from a DLed Bootable PLC program so there was no IO failure that occurs when a card is removed online.) In fact the IO is still dead now. I am unable to revive it. There seems to be nothing wrong in the offset and a simple 1 card config and 1 rung ladder diagram is unable to trigger the Output card.

Sorry for the Long Post. As I am quite new to this, any information is very welcome.
I can be reached by Andy_Lim_T_L @ Yahoo. com. sg

 

Hi guys,

Sorry, I think I'm supposed to start another thread regarding this but...

Due to a erronous program I was forced to "format the file system" using the Wago ethernet settings program. After doing this the "configuration webpage" that can usually be accessed by typing the PLC's IP in a web browser is missing.

Is there a way to reinstate this web page? Are there any sources of info regarding this? I believe in embedded systems we call this an embedded server page and it can be easily restored by "DLing" a precompiled web server that is configured to run on boot of the Embedded system. I am a fish out of water here, sorry if the terms used are wrong.

Thanks for the advice.

 

> So a backplane not only serves to provide power and physical mounting, it also acts as the communications bus. <

Yep!

> But what about addressing? ...Since hotswapping' can be performed, there must be some catering for addressing right? <

The answer is both simple and brilliant; the slot is the address! In the old days, the controller had to be in "slot 0," though some modern systems will let you put it anywere. In either case, the controller / CPU / brain / whatever you want to call it has the configuration stored, i.e. which type of card is in which physical slot number. So you pull out a card, then slap in a replacement, and poof! It just works. Assuming, of course, that the new card matches the type of the old card.

Incidentally, if you use a remote rack with a communications card (e.g. ControlNet or EtherNet/IP to an A-B 1756 ControlLogix chasis), the master node will talk to the cards that ARE configured correctly, and ignore the ones that aren't. This is again thanks to the backplane scheme.

On the other hand, the price and sheer physical size of that solution DWARFS the Wago I/O. Just the communications card is probably more than an entire Wago 750 I/O block, then you still need the power supply, rack, and I/O cards. And it's a pain to wire to the I/O points on that kind of setup, so you'll probably use pre-made cables to breakout terminals. The cables and breakouts are again probably as much money as your entire I/O block.

There's no such thing as a free lunch.

-James Ingraham
Sage Automation, Inc.

 

I haven't had to format any of the Wago systems
I've worked on, and the manual for the 750-342/842
does not mention how to reload the html pages. I
suggest contacting Wago support and getting help from them.

Good luck.

Davis Gentry

 

Ok - I think I better understand your issue now, but still don't have a good answer other than a routine to check the i/o and fault if it goes away (this could be as simple as having an output wired to an input, toggling the output and monitoring status of the input). It makes sense that if one i/o card is totally blown then all of the cards in that rack will die. The bus is serially connected through each card, with a terminating module at the end of the rack.

Which FC are you using to work with your i/o? The only problem I have had with the 750-342 i/o was initial addressing the first time I used it. In general, once I've found the first bit of data at my end I've had no problem extrapolating the location of the rest. An FC23 works well for a rack which is composed of both inputs and outputs. Remember the order of the data in the modbus registers from the Wago -> byte wide inputs (analog data), bit wide inputs, byte wide outputs, bit wide outputs. Remember that your Modbus offset will be zero for the inputs and ((total number of bits of input data) / 8) rounded to the next whole number for the outputs.

You can read back the outputs (not set them) by doing a read FC to an address 0x200 above the actual output address.

Good luck.

Davis Gentry

 

I am just setting up a system using a WAGO 750-342 processor. I can not write to the module from the connected PLC (A/B CLX + MVI56 card). You mention that the Modbus offset for the outputs depends on the input area size? I did not realize that. That is the same as in the devicenet processor 750-306.

When I tested the Wago setup by using the Intellution Scada + MBE driver, I could write to the outputs with an offset of 0. Could you explain that? Unfortunaly I can't try this until next week.

thanks, Eric

 

Hi Davis and James,

Thanks for replying.
Once again sorry for the slow reply.
I had to call in the supplier to fix the Config page issue. Apparently, "formatting the file system" affects more then just the configuration page. After proper restoration steps are followed, it fixed my IO control issues as well as the config page issue. After which more critical "firefighting" had to be performed. "All work and no firefighting makes jack a dull boy it seems". Sorry, a little off topic.

Hi Davis, I am currently using the 750-841 Ethernet FC. Ah I see, thanks for the clearer picture of the addressing modes of the IOs. But what I do not understand is the usage of the offset. Under what circumstances is an offset required? What's the main purpose of an offset?
Is there a way to set defaulted states to the IO when the FC dies? (This could at least provide some level of safety for heavy machinery connected to the IO cards which are after the "Dead card".)

Hi James, Ah I see. Thanks for the info. so the addressing is specific to the slot, in Wago it's set by the arragement of the IO cards. I wonder if there is a way to lock a specific address to a specfic IO card of the Wago? That way, if we remove the "dead card" and reconnect the remaing cards, there will be no need to alter the program. Currently when the above is done, the addressing runs, i.e., card A controls MOTOR, card B controls DOOR, card C controls LIGHT. Card A dies, we remove it and reconnect card B and C to the FC. Card B controls MOTOR, card C controls DOOR and light is uncontrolled.

For safety, card B should still control DOOR and card C should still control LIGHT after the cards are reconnected. Sorry for the long explanation.

Is there a method to ensure that the devices connected to the IO cards after the "dead card" are turned off (so that at least DOOR and LIGHT will not malfunction)?

Sorry but it seems like I am getting a PLC boot camp training from you guys. Thanks a lot for all the advice.

Hi Eric, I can't really help with your first problem, but with the offsets, set to 0 the IO. Addresses will be lined up after each other as said by Davis. (This has been tested.) i.e., AnaInput then DigInput then AnaOutput then DigOutput, so you should be able to write to the outputs, it's just that the addresses may be different.

 

> Hi Davis, I am currently using the 750-841 Ethernet
> FC. Ah I see, thanks for the clearer picture of the
> addressing modes of the IOs. But what I do not
> understand is the usage of the offset. Under what
> circumstances is an offset required? What's the main
> purpose of an offset? <

The Modbus offset is used so that you can grab
individual points rather than just all of the data at once.

> Is there a way to set defaulted states to the IO
> when the FC dies? <

All outputs default to off - I would suggest an
electrical design in which this is a safe state. In general this is a good idea anyway - what happens if your i/o cable is cut?

> I wonder if there
> is a way to lock a specific address to a specfic IO
> card of the Wago? <

I don't believe so - but the way to address this is to have spares around if this is a critical machine. Also to lock out the machine in software if missing I/O is detected. With the Wago stuff you can read back the outputs by reading them at inputs at an address above the outputs - something like 0x100 above if I recall correctly - it is documented. So if your outputs are not in the state you are setting them then shut the machine down and issue an error that tells the maintenance guys what is going on.

Davis Gentry