Module Good LED on T1H-EBC

[Adam13]

I have a setup with a T1K-01AC power supply, T1H-EBC ethernet base controller, 2 x T1K-16ND3, and 1 x T1K-16TD2-1. I used the Ethernet SDK to develop a C++ application to control the I/O directly (read no OPC server).
I am experiencing an intermittent problem where 1 or more modules stop reporting and the MODULE GOOD led on the base controller starts to fast blink. I can cycle the power on the controller and everything starts working again. I don't even have to restart the control program on the PC.

Is there any way to reset an error like this on the fly w/o cycling power? This I/O is controlling a piece of automated leak testing equipment in a manufacturing environment and I'd rather not tell the operator to pull the plug every time it stops working. Also, is there any way to determine what the original fault was on the modules?

Additional information - the DC input modules are jumpered for internal power. Could the loss of modules be related to an overload on the DC supply from the T1K-01AC? I have used Terminator modules on 2 other projects, 1 small assembly machine, and 1 robotic assembly cell. I had this problem on the robot assembly cell using the relay output modules. I eventually switched to DC output modules and external 24Vdc relays and the problem went away so I never figured out how to fix it.

Any help greatly appreciated.

[MikeS]

The API you're looking for is HEIRescanBase. This API is used to manage the Hot-Swap feature of Terminator I/O. This API causes each I/O module to essentially go through the power-on-reset process. During this process, each module gets assigned a slot number, thereby, getting logged into the system. Since this API has the ability to assign/reassign slot numbers, it could have potentially harmful effects on the system.

USE THIS API CALL WITH EXTREME CAUTION

The fast blinking Module Good indicates that one of the I/O modules that was preset at power up has gone missing. Since there is no unimportant I/O, you should always check the return code of the HEIReadIO and HEIWriteIO calls, and if there are errors, you should call HEIReadModuleStatus to determine which slot(s) are reporting the error(s). If you'd like to talk about the specifics of how to do this, email me at SDKSupport@hosteng.com. This won't tell you what the original fault was, only which module is reporting an error - or in this case, which module has gone missing. I'm not sure about the power issue being the problem either. Once we know which module is complaining, we should be able to make an better decision about what the problem is.

The return buffer contains the same data as a call to HEIReadBaseDef(), if you want to parse the data, you can. If you had previously stored the base configuration, this would allow you to compare the before and after versions and see if the same type module that was removed was replaced or if a different module was put back in the base.

As part of initializing the base, you can optionally clear the EBC's internal copy of the discrete output data. The discrete outputs are NOT forced off during a reinitialization, so for most applications you'll want to leave the image register alone so that after the reinitialization the image register's contents will match the actual discrete outputs.

   tFlags = RESCAN_LEAVE_IMAGE_RAM
   tFlags = RESCAN_CLEAR_IMAGE_RAM
   
Depending on how many I/O modules you have, this API call takes a comparatively long time to complete, so to avoid getting a timeout error (32774), you might need to temporarily increase the device timeout value to something like 250ms. There's a built-in 200ms wait, and you'll need to allow about 2 ms per module for the reinitialization to complete, so we recommend that add 200ms to your standard timeout value.