FF design

[B.Anant]

Hi,

Some questions on FF segment design -

1. Whenever the FF device revision is changed, does it impact the IS certification? i.e. the new rev of device – is it still compliant with the certification that the earlier revision had?

2. For cable capacitance, we have seen different terminologies like Nominal capacitance, Nominal mutual capacitance and Max. Capacitance unbalance for Belden cables (3076F). What exactly do these mean and which one is relevant for capacitance to be used for calculations?

3. Are there any recommended FNICO parameters ( like Pi ) for power supplies and FF devices ? The MTL9111 and 9112 specs show only voltage and current.

Any idea on these?

B.Anant

[Mike ONeill]

1. If the FF revision is purely to upgrade or debug software, there is unlikely to be any affect on the I.S. approvals, which are purely physical. Where physical changes have been made to devices, the I.S. approvals would have to be assessed if those changes impacted on energy storage capability or changed safety-related components.

Manufacturers can design product and submit 'certification drawings' which incorporate quite wide component descriptions (TIP: keep 'certification drawings' separate, but linked to, 'manufacturing drawings') and thus avoid re-certification for trivial manufacturing changes. PCB layout changes almost always require re-assessment.

2. Cable faults which might cause explosive sparks can be core/core or core/shield, so use whichever capacitance figure is the larger, since for I.S. purposes, it is the maximum available external energy which is important. Unbalance is the difference between asociated cores (really a sort of manufacturing tolerance), will be much smaller than the core/shield capacitance or core/core capacitance, and not relevant for I.S. calculations.

3. MTL seem to be the only people to understand/promote FNICO, even though it was 'invented' by P+F. To me, it looks like a technology in search of an application; the high power trunk technique favored by everyone else seems to allow so much more flexibility in fieldbus segment design at far lower cost.