Re: [foxboro] Problem of Integration of I/A with Trident PLC through Integrator 30

Dear All,
 
Just wanted to share how the problem resolved.
 
Actually the Foxboro MDSCAN block writes to TRIDENT addresses in multiple of 16 
continuous in range. Out of these 16 addresses, only two were defined in the 
TRIDENT program as Read/Write alias. 14 addresses were not defined as any tag. 
So when the Foxboro tries to write on the addresses which are multiple of 16, 
TRIDENT rejects the whole word (even the bits that are defined) and the 
TRIEDENT (device) goes offline in "System Management".
 
This can be corrected by stacking the alias addresses in continuous range so 
that no address accessed by MDSCAN block is undefined in TRIDENT.
 
Triconex TAC was instrumental in solving this problem.
 
Regards,
 
Kashif Ijaz
Senior Design & Application Engineer
INTECH Process Automation> From: kashifijaz93@xxxxxxxxxxx> To: 
foxboro@xxxxxxxxxxxxx> Subject: [foxboro] Problem of Integration of I/A with 
Trident PLC through Integrator 30> Date: Sun, 24 Jun 2007 19:19:14 +0400> > 
Dear All=20> > Please help me on this> > I am trying to integrate Foxboro I/A 
(version 4.3) with Trident => PLC(through> it's communication module) through 
Integrator 30 (P0961BD). Actually => there> are two devices which are connected 
to Foxboro through RS232-RS485 and> RS485-232 converters. First device is 
behaving all right. The second => device> (Trident) is the one giving me this 
problem.> > I am having three compounds with MDSCAN blocks one each for Digital 
=> input,> Digital output and analog input in the Integrator30 Station.> > The 
Trident PLC has come online in the System Management. Analog inputs => are> 
reading OK in the I/A. But the digital outputs from I/A are not going to => 
the> Trident and when I try to toggle these outputs from the I/A, the => 
connections> between the Trident and I/A breaks and Trident goes offline in the 
=> System> Management. The Modbus addresses have been checked and they are => 
correctly> written in the COUT, CIN, AIN blocks.> > Then the only way to 
recover the communication is to turn off the three> compounds and then bring 
the device online through SMDH. Even when I => turn on> these compounds, it is 
causing problem as the Trident goes offline in => SMDH.> I have checked the 
period and phase of all blocks and they are exactly => same.> > The Integrator 
30 loading pattern is also very unusual with I/O scan> sometimes going over 
100% and idle time also is over 100%. The loading => of> Integrator is showing 
around 75%.> > Also is there some setting in Trident which is rejecting the 
digital => output> writes from the I/A. The option "Disable remote changes" is 
unchecked in => the> main processor settings of Trident.> > Can you suggest 
corrective measure on this issue!> > Regards,> > Kashif Ijaz> Senior Design & 
Application Engineer> INTECH Process Automation> > > > 
_______________________________________________________________________> This 
mailing list is neither sponsored nor endorsed by Invensys Process> Systems 
(formerly The Foxboro Company). Use the info you obtain here at> your own 
risks. Read http://www.thecassandraproject.org/disclaimer.html> > foxboro 
mailing list: http://www.freelists.org/list/foxboro> to subscribe: 
mailto:foxboro-request@xxxxxxxxxxxxx?subject=join> to unsubscribe: 
mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave> 
_________________________________________________________________
Play free games, earn tickets, get cool prizes! Join Live Search Club. 
http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink
 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: