Created Date: January 12,2005

Created by: hanziou

I am starting up a system using Terminator I/O controlled by a EBC getting commands from a H2-ERM on a 4 base rack and a 250-1 CPU. my discrete outputs are T1K-16TR modules.

Every once and a while (20-30 minutes) I hear the equipment that are supposed to be held do a off-on cycle. The symptoms seem consistant with the Terminator I/O relays opening for a 'second ' and then reclosing.

I have double checked my power budget. I have excess power available. When the equipment was being run manually, there were not noticable drops.

Suggestions on what to check for to not have these hiccups?

Created Date: January 12,2005

Created by: franji1

The EBC slaves, by default, turn OFF outputs if there is a comm failure.

It sounds like you are timing out. Open ERM Workbench and click on each slave number on the main screen and see if you have/had any timeout errors.

If you are, there are two possibilities. First, and most common, is when you are doing runtime edits, which halts the backplane comm between the ERM and the 250-1 long enough, that the EBCs believe that connection to the ERM is gone. You can aleviate this problem by enabling the ERM to pet the slave's watchdog timeout. This allows the ERM, even if it has no data to update, because of the main CPU being tied up, to communicate with a slave to tell it "I'm still here, I just am stuck waiting for the main CPU. Don't timeout, don't turn off your outputs, I'll be back soon ".

The same situation can occur if your PLC has scan times that are quite long. Again, enabling the pet will solve the problem.

You definitely want to set the Pet frequency to as LONG as possible (half the timeout value). You don't want the ERM constantly petting under normal circumstances, which is what would happen if you set it to a small value.

Secondly, it could just be timing out. Are you using a bunch of routers, radio ethernet, lots of traffic with lots of collisions, etc., then you would want to bump up the acutal timeout value and/or retry (I think the default is 25ms). Note that these are "application " layer retries, not Ethernet retries, which is built-in to the Ethernet chip when collisions occur.

Note that all of these settings are configurable PER SLAVE. You must change them on each slave. However, you can go into the View->Options and change the default settings for a slave so that any FUTURE slaves to this ERM or any other ERMs will have this new default settings upon creation. There's even a restore "Factory Default " button in case you get tweak-happy and mess something up (but, this only affects the default on new ones, not existing ones! You would still have to change existing ones by hand, or reconfigure them from scratch with the new default values).

Please let us know if this helps or of any other symptoms, or maybe tell us what your slave configuration parameters looks like.

Created Date: January 12,2005

Created by: franji1

I should have also mentioned that it is HIGHLY RECOMMENDED that the ERM network be an ISOLATED network. If you have it on a business network or sharing it with other ERMs and/or ECOMs, the network can become saturated pretty quickly, causing collisions, with lots of retries, which creates more collisions. Bumping up the timeouts may help a little, but it is quite unstable for an I/O control network.