Output transfer failure

Hi there,

We have modules generating 'Outputs transfer failure'. We are trying to understand the source of
the error and if possible to fix it.

One theory has its origin from a BOL article "Special Items Palette" (excerpt copy/paste
below).

An example of the module coding is:

Internal write parameter (config as type 'internal reference') references an output parameter
(config as type 'external reference'). Output parameter is one level up at the top level of module.

PHV event file logs the 'internal reference' as the source of 'Outputs transfer failure'

(For info: the 'external reference' is to another module with internal read parameter (config as
type 'Boolean with status')

A picture to help is attached.

Has anyone experience of the the 'problems' the BOL refers to? And, does this 'problem'
generate 'Output transfer error'

In this case, is the final destination of type 'boolean with status' the issue and PHV event log
shows this by referencing the initial data point that cannot make the destination?

DeltaV version 10.3

++++++

BOL copy/paste from article title "Special Items Palette"

 ....

Internal Write Parameter

An Internal Write Parameter provides a connector to which you can wire on a function block
diagram so that you can write a particular parameter. The parameter connector is not seen outside
of the block or module by default. You can use the Show Parameter function to make an Internal
Read parameter appear as an output connector on a module block or composite. Note Make sure
this parameter does not reference an external reference parameter from within this same
Module. (You can configure this, but it will cause problems at run time.)

MichaelP

• 22 Oct 2014 5:07 PM

• All Responses
• Answers Only

• Matt Stoner

o 22 Oct 2014 5:27 PM

Michael,

If you look in the Event Chronicle, it will show you where the problem resides (as long as the
area that the module having the issue is assigned to the Event Chronicle).

Here is an example of an Input Transfer Error and the Red box shows the parameter where the
problem is occuring.

Once you find out where you will need to determine why (Not Permitted, wrong value, etc).

Regards,

Matt

• MichaelP

o 23 Oct 2014 1:07 PM

In reply to Matt Stoner:

Hello Matt

Thanks, I have the loction of the error in the Event Chronicle.

 I remain with the query:
Anybody have experience of the problems in run time the BOL article mentions?
(Output transfer failure ?)

• amodbobade

o 27 Oct 2014 4:15 AM

Hi,

Sometimes, when you are trying to write the "Status" to a parameter where it is not supposed to
be written externally (i.e.: PV parameter of a block), then the "output ttansfer error" is shown.
As the XFR block output is with status & the same is with your landing module parameter (I
guess the ZVBAMS111-7-LZO is landing module), it might be generating error due to the
parameter being "with Status" Try making it only Boolean. Also, make sure the output of XFR
block is Boolean type only.

General engineering practice would be:

Try to reverse the connections: In the landing module make the boolean parameter as external
reference, refeing to BF_LEUCHT_RT.
Make BF_LEUCHT_RT an internal reference parameter to RED_LIGHT.

Best Regards,
Amod.

• Glenn Faber

o 13 Nov 2020 2:23 PM

In reply to Matt Stoner:

Matt, I have a module that will occasionally go to modbad then clear within one scan. Event
Chronicle shows Inputs Transfer Failure. I have several modules that reference that landing
module and none of them go to modbad. Looking at the configuration of the read input of the
 landing module it is configured as floating point with status. Is it likely that it briefly has a bad
status and then clears? How do I go about trying to locate where the issue is?

• Matt Stoner

o 13 Nov 2020 6:12 PM

In reply to Glenn Faber:

If you have narrowed it down to that parameter, I would probably historically trend the
value/status so you can see what the value is during the MODBAD situation. Maybe it is set to a
value that isn't supported by whatever is setting the parameter or the downstream block can't
accept that value.

• Andre Dicaire

o 13 Nov 2020 10:51 PM

 In reply to Matt Stoner:

Input Transfer error typically involves a wired connection where the value being passed is of a
different type and cannot necessarily be coerced into an equivalent value. BOL indicates this is
reported when the wire is to an Input connector of a function block. When a transfer fails to an
"output" parameter, that typically shows an Output Transfer Error. I've confirmed that whether
the output parameter is an external reference or a local data type, if the wired value cannot be
coerced, we get an Output transfer, not an Input transfer.

On a second module with various types of parameters, I've set the External reference of my first
module to each type in turn. The destination module never shows an error when I try to write a
value that does not fit. I get the Output Transfer Error in the first module and the write to the
destination simply doesn't happen. The destination parameter remains at its last value and status.

I also tried an expression with the CALC block writing a float value to 16 bit integer Input
parameter. When the float value was out of range of the integer, the module gave an IO
OUTPUT error.

The only way I've created an Input Transfer Error is on a wired connection to a Function Block,
which is what is described in BOL for this type of abnormal condition. I wired an FP to the
exposed SP parameter and set to 150 for -0-100% scale and that creates an INPUT Transfer
Error. Interestingly, if I do the same to the CAS_IN, I get an IO INput Transfer. So it depends on
the type of parameter. CAS_IN, FF_VAL, IN are IO related signals to the block, so that makes
sense. SP is an operator parameter, not assignable to an IO signal so it gives Input transfer Error.
Other examples have been wiring to a BFO with a 32 bit integer that exceeds 16 bit limit.

My thought is the Input Transfer Error is related to a Function Block Input parameter that gets a
value it can't handle.

Note, wiring a string parameter to a numeric is not permitted in control studio. If you wired a
dynamic reference and set that path to a string , I'm not sure what that would report, but could
likely cause an Input Transfer Error. Haven't tried that.

Why it would be transient I don't know.

Andre Dicaire

• John Rezabek
o 16 Nov 2020 3:46 PM

I'm not sure what you're writing to - directly to IO?

Our original configuration used an abundance of "cascade masters" where the secondary loop
was depicted in the primary loop's module as a composite block. CAS_IN was "exposed" as an
"internal read" and wired to the primary (master) PID's output, and likewise BKCAL_OUT of
the secondary PID was wired to an "internal write" - like your red light and green light. We saw
numerous "output transfer failure" events. We surmised the secondary loops - running execution
times 5x - 10x faster than the primary - were trying to write to the module that wasn't executing.
So we deleted all the "composite " blocks and used "internal read" parameters only, in two
independent modules. The secondary PID's BKCAL_OUT wasn't wired to anything, but an
"internal read" in the primary pulled in the value only when the slower primary was executing.

The transfer errors went away.

This phenomenon may have been addressed in later versions, but the effort to "write" to an
object that was latent / not executing might be a factor.

• Andre Dicaire

o 16 Nov 2020 6:31 PM

In reply to John Rezabek:

John. That is interesting. By design, the module block syntax is interpreted by DeltaV in the
download script as parameter Reads. Although we wire the Outer/PID/OUT to the
Inner/CAS_IN, and the Inner/BKCAL_OUT to the Outer/PID/BKCAL_IN, the download script
replaces these wires with external reads, such that the INNER/CAS_IN reads the
OUTER/PID/OUT and similarly for the BKCAL signal.

A look at the Power up module script shows that the data transfer is done via Reads. I think this
requires that the INNER loop be made private to the OUTER loop, i.e. it is under the Outer loop
in the Explorer Tree.
 If another module attempted to write to the CAS_IN of the Inner loop, that would cause an issue
because at run time, that parameter is an External reference to the PID/OUT parameter. It is not a
Floating Point with Status. There may be something else going.

For a Cascade pair of loops, using the embedded module block is recommended.

Andre Dicaire

• John Rezabek

o 16 Nov 2020 8:02 PM

In reply to Andre Dicaire:

Andre - I'm thinking back to like v4 or so (no later than 5) so maybe it's conceivable this was
"fixed" in later versions? Certainly having the embedded composite block is more revealing &
intuitive to the casual observer / successor / troubleshooter.