Emerson Exchange 365

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

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 ?)

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?

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.

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

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.

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

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.