bevanwi
Joined on 11-19-2007
Posts 1
G4 I/O paired with Factory Floor
I work in a lab that has ~26 individual OPTO22 control systems. The systems control bench scale refinery units. All of the I/O is the “old” G4 bricks. We use the latest version of Factory Floor and have a mix of Classic Controllers and Snap LCM4s. As of late, we have had a problem with loss of communication between the controllers and the I/O (no transmit or receive light flashing on the analog or digital boards). After talking to the OPTO22 troubleshooting guys we began checking out the G4REGs in the systems. I’ve gotten a couple of opinions concerning the acceptable voltage for these modules (from 4.96 to 5.02 VDC) and the expected lifespan of the same. I’m interested in anybody else’s experience concerning this issue. While checking the racks with communications problems I’ve caught some of the G4REGs dropping voltage to nothing then coming back to operating voltage, has any one else seen this? I would really appreciate any info that anybody can provide. We are considering a control system upgrade, does anybody have an opinions concerning the latest offerings from OPTO22?
Report
11-28-2007, 11:20 AM
gmitchell
Joined on 12-01-2003
Optomation Systems, Madrid, Spain
Posts 153
Re: G4 I/O paired with Factory Floor
You are quite right about the output voltage of the G4REG, its more or less the same for all of the Opto22 I/O families. G4REGs are not user adjustable. But as well as checking the output voltage maybe you should be monitoring your supply input voltage input should be 24VDC +/.0,1V. I would be surprised if the problem in within the G4REG’s
Here are a few questions that you might not have considered.
How regulated is the 24V supplying the G4 Mistic Bricks. The specification is 24VDC +/- 0,1V. Could it be that the G4REG output voltage is unstable simply because the input supply is unstable?
Is the 24VDC supply to your G4 Mistic Bricks in series (i,e daisy chained like the comms) or in star (individual cables to all bricks form the power supply)?: Mistic bricks should always use “star†connection
How close are your 24VDC power supply’s running to maximum wattage. Each G4A8R analog brick consumes 4.32W, G4RAX consumes 1.56W and each G4D16R consumes 6W. To this you still have to add the consumption of the I/O modules (Check Specsheets for details) and also any transmitters or valves being powered by the analog mistic bricks. (see point 5)
Are you using 24VDC G4IDC5 and G4ODC5 Optos. Its always better to use two separate isolated power supplies, one for the mistic bricks and another separate general purpose supply for the field circuits. Otherwise spikes and earth problems in the field can easily end up at the G4REG input.
How are you supplying analog field devices from G4AD3 and G4DA3. If you are powering from the brick (System Powered Option) and have impedance devices, this can cause damage to the G4REG or exceed their capacity. Its recommendable to use separate supplies (see point 4) to avoid field problems bypassing the normal G4 module isolation through the “backdoor†of the G4REG which is transformer isolated.
Make sure the mistic bricks are properly mounted in a suitable cabinet and that the comms cable is shielded and run separately from mains voltage cabling. Make sure they are a safe distance from AC power transformers, 3 phase equipment and variable speed drive units all of which generate uncontrolled levels of RFI.
With what frequency is this problem occuring and what does it coincide with? Could it be a software problem after all, (illegal function call, command not correctly sopported in latest level of controller firmware etc)
With respect to the TX/RX LEDS on the brick. Normally a controller will retry any unanswered transmission a number of times (I think its 16, maybe somebody could confirm it) and then mark the mistic brick as incommunicable. Unless your program application has some logic to reenable comms, the controller will not transmit further request messages, and therefore the brain will not answer. Maybe there is a clue there somewhere. If you have multiple brains on a single comms line you should still be receiving a RX light on the brain as it continues to receive transmissions for other brains.
When talking through this problem you will need to supply an system architecture diagram. It may need the attention of a system specialist to visit and fully understand whats really happening in real time. That’s what your local Opto22 distributor is there for. Some things you just can’t see on the phone!
In general terms Mistic I/O is probably the most rugged I/O system ever produced by Opto22. The more filthy the conditions, the worse the temperature extremes, the better it works. One customer told me the only time he had problems with his Mistic I/O was when he tried to clean the accumulated layer of dirt and dust on top. Many of our customer have Mistic I/O running 24/7 for over 15 years in extreme conditions. I certainly wouldn’t recommend changing it out, although you should consider upgrading your controllers to SNAP-PAC-S1/S2 controllers to use the latest software and benefits of Ethernet integration. Its been a good 5 years since IOProject/PACProject took over from FactoryFloor ! You will be surprised at what Opto22 have added since then, while still maintaining support for previous generation hardware and software.