Re: [foxboro] FBM 233 to Controllogix question

Terry,

With the Controllogix driver you can access controller tags individually 
by native tag name. While convenient it is certainly not efficient. I 
would have preferred to bring in a packed data table similar to what was 
done on the integrater gateway modules, however I did not see an easy 
way to do this.

In any event I wouldn't expect 30 tags to hang the system. I will check 
the default scan rate, and timeout values to make sure these are 
reasonable.

mk



Doucet, Terrence wrote:
> A question to the three members of this list who are having FBM233 problems:
>
> How are you reading data from the PLC?
>
> 1. In the PLC, do you map the Input and Output data to a PLC table, then use 
> the FBM233 to read the PLC table?  A read such as this is the recommended way 
> to read data in a PLC. You want to maximize the number of bytes retrieved 
> with each read from the PLC via an ECB.
>
> 2. In the FBM233 do you have multiple ECB's for each Input or Output card of 
> your PLC?  This is not recommended (even for ethernet) since the overhead of 
> your communication (addresses, CRC, etc.) is now a much greater percentage of 
> your communication between the PLC and the FBM233.  One might consider that 
> you are "lightly loaded" if you are only reading 10 to 15 input modules in 
> the PLC, but I have seen overloaded communication and Out of Service 
> conditions on the IA side with just this "lightly loaded" condition. In fact, 
> we were not lightly loaded, we were overloaded.
>
> Terry Doucet, Eng.
>
>
>
> -----Message d'origine-----
> De?: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] De la 
> part de Jack.Easley@xxxxxxxxxxxx
> Envoy?: January 26, 2009 12:32 PM
> ??: foxboro@xxxxxxxxxxxxx
> Objet?: Re: [foxboro] FBM 233 to Controllogix question
>
> FYI,
>
> We have a similar, if not the same, issue here with our one installation
> of Redundant FBM233s to Controllogix PLCs. It happens several times a
> week and is temporarily fixed by taking the FBM233(s) offline, then
> online. We do get System Monitor indication of failure in all cases.
>
> Sounds like this is a real Foxboro bug, not an installation problem.
> Anybody contacted Foxboro to resolve this as yet?
>
> Jack Easley
> Sr. I&C Technician
> Luminant Power, Martin Lake Plant
> Phone 903.836.6241
> jack.easley@xxxxxxxxxxxx
>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
> On Behalf Of mike kessler
> Sent: Monday, January 26, 2009 11:16 AM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] FBM 233 to Controllogix question
>
> David,
>
> Did you manage to resolve this issue? I am having similar issues with an
>
> installation which has hung 3 times since implemented in September. The 
> system is lightly loaded <30 tags. I'm talking to two controllogix
> PLC's.
>
> Here's the rub. The points don't go cyan, but they stop updating so 
> everything looks OK from an operator's and  System Monitor's point of
> view.
>
> I will implement a watchdog alarm to let the operator know it's time 
> reset the FBM233 from system management to re-start communications.
>
> mk
>
> David Johnson wrote:
>   
>> Hi all,
>>
>> I am working with a customer running a fault tolerant connection 
>> (FBM233) to fault tolerant controllogix processors using Foxboro's 
>> ethernet IP driver.  We started with an older version of the driver, 
>> but quickly had field service upgrade everything to the latest back 
>> in March.  Everything will work for several (many) weeks and then all 
>> of the blocks being passed to and from the gateway will smurf at the 
>> same time.  We are having to re-boot the CP to clear this condition 
>> (it might be enough to re-download the fbms and go off line and back 
>> on-line, but they haven't tried that when the crisis occurs).  We are 
>> not adding or deleting any blocks in the configuration, and to the 
>> best of my knowledge the primary and secondary controllogix modules 
>> are not swapping, neither are the primary and tracker FBMs swapping 
>> (again, as far as I can tell.)  In other words it appears to work 
>> until it quits.  When it is working none of the points appear to be 
>> smurfed and everything going to/from the PLC looks like a valid 
>> controller tag.  The time interval between failures is not constant, 
>> but they have seen this occur 3 times in the last 5 months.
>>
>> The data load is reasonably light, only 262 controller tags.  The ecb 
>> 201 has the timeout set at 5 seconds, which should be plenty of time 
>> if there is a network problem that corrects itself.
>>
>> So I was wondering if anyone else has seen this or knows of issues 
>> that might cause this performance issue on the FBM233 with EthernetIP.
>>
>> Thanks,
>> David
>>
>>
>>  
>>  
>>
>>     
> _______________________________________________________________________
>   
>> 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
>   
>>  
>>
>>   
>>     
>  
>  
> _______________________________________________________________________
> 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
>  
>
> Confidentiality Notice: This email message, including any attachments, 
> contains or may contain confidential information intended only for the 
> addressee. If you are not an intended recipient of this message, be 
> advised that any reading, dissemination, forwarding, printing, copying
> or other use of this message or its attachments is strictly prohibited. If
> you have received this message in error, please notify the sender 
> immediately by reply message and delete this email message and any
> attachments from your system. 
>  
>  
> _______________________________________________________________________
> 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
>  
>  
>  
> _______________________________________________________________________
> 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
>  
>
>
>   
 
 
_______________________________________________________________________
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: