Will S+ Engineering 2.1 Detect Duplicated Exception Report Imports?

Our clients would like to know if S+ Engineering 2.1 (the POSTGRES SQL form) will protect them from potentially significant oversights with respect to importing exception report blocks more than once into the same module / controller.

In INFI 90, an exception report can only be validly imported into a module once. It must be distributed from that loop or superloop input block. If it is imported more than once, there are two dire results:

1. Only one of the import blocks works at any time.

2. An online configuration will result in another import block beginning to work, with the one that was working freezing.

This phenomenon even applies to blocks that are "spared out". Even if unwired, they can steal the active value. Rest assured this happens.

In a scan of 345 systems, this error was found for 123 projects, with 862 instances, each involving two or more blocks. In every instance, correct operation is simply a gamble, and if the import block is working, it will freeze on an online configuration operation.

DBDOC detects this situation in a useful way to protect client systems. Composer does not detect this. What about S+ Engineering 2.1?

https://gmcl.com/Help/build_error_93....

Comments (2) New comment

Geoff Michaels Rank: 554

Asked 2 years ago

Answer this question Follow

Voted best answer

No information can be given as SPE 2.1 is not yet officially released.

Comments (1) New comment

Govindaraj AKS expert

Rank: 10

Answered 2 years ago

Answers

Hi Geoff,

A relatively little known / poorly communicated perhaps, feature of Composer is that as long as import blocks (AIB, DIB, AIL/B, DIL/B, AI/L, DI/L, AI/I and DI/I) have a resolved cross reference attached, warnings are generated at compile time for duplicated imports ("input already accessed" or similar). If decommissioned / unused import blocks are also explicitly updated with a suitable unresolvable unique cross reference string eg "UNUSED.LLLPPPMM.BlockNum" the original import specs will be set to default values when the cross reference text is changed, also avoiding the possibility of duplicates.

Ensuring that all data import blocks are cross referenced or if unused, contain an unresolvable cross reference and reviewing the compile log seems to catch these configuration errors before they are downloaded to the controller.

The only time this function doesn't work is, from memory, when import blocks have a source in another project as the cross project binder utility does not create a persistent record in any of the project databases for inter-project signals.

Cheers,

Alan

Comments (1) New comment