Cross References from Infi 90 / Composer

Please , could you support to us in the following question ?
I have realized that in configuration there are two cross references which they are not configured , we have verified through properties - Cross References , they are blank , I understand that we can add to Defined and Valid References to populate reference Name and create the link to connet from one CLD to another or page.
Those two tags are connected to an RNG( OR) , and some of the logic is located in another CLD/page and through the link they connect to RNG block to do some actions. 4980 ( FB) - 42 (FC) , 4981( FB) -42( FC)
The question , if we would analyze the situation , the RNG ( OR ) connections related to both tags mentioned above are not changing and their values are 0 and they would keep in 0 until we configure the link to both tags and compile , That I mean in this moment those two tags are not influenced nothing until we fix the cross reference issue , Is that correct?
Please see the attachment

Thanks for your support

Regards

CROSS REFERENCE.jpg

Comments (0) New comment

ricardo.marrero.a Rank: 159

Asked 1 year ago

Answer this question Follow

Answers

Hi Ricardo,
With inter-module communications the the cross reference text is used to automatically fill in the specs on the block (FC42 in this case) but the block can be used if no cross reference text is entered and the specs are manually edited. From the screen shot...
Block 4980 is connected to 21-5-5613??. It has no iref text.
Block 4981 is connected to 5-5-5760. It does have text-BB4410-STD-SC but there is no matching oref text.

To answer your question, the logic is potentially active and you will need to analyse the source logic because as they say in financial circles... "Past Performance Is Not Indicative Of Future Results". Just because the DI/Ls have not changed state yet does not mean that they wont.

If the source block numbers are correct just add cross reference text and orefs in the source modules, compile and verify, no download is required to any module. If the source block specifications are incorrect you will still need to add cross reference text and orefs but the changes will require a download to the destination module.

BR,
Alan

Comments (8) New comment

by ricardo.marrero.a Rank: 159 on 2/23/2020 3:19:27 PM | Like (0) | Report

Hi Alan , Thanks for your response I understand that we should link to the proper reference to fix them and to know the proper source to fix properly.
But the question , if this configuration is in this way , could it be working properly eventhough the references have problem like I have showed , that I mean , both are connected to a RNG ( OR) , but if they are not linked , Could not they be refreshed and and in these connections would be 0 . I mention it because the values come from another module and DI/Ls allow to get the values and connect to RNG ( OR ) ,but if the link is not done properly or blank then it does not get any value or 0 and part of the logic would not work properly , Is that correct?
When I have tried to open cross reference, it is blank in the population area and we should populate with the proper source as you have mentioned
But Is it possible to system has lost the reference? or customer did it in this way and do test in future , or it may be , at the beginnig they did it and then they decided to disable them in this way . I should ask to the customer about it , but my concern in this moment is , part of logic is not refreshing the values coming from the references mentioned above , and it would put 0 only for the two

Thanks for your support

Regards

What do you think about it

Alan Rank: 13 on 2/23/2020 4:06:07 PM | Like (0) | Report

Hi Ricardo,
For communication between modules the specs in the import blocks define the links not the cross reference text. Normally the cross reference text is used to automatically set these specs but in the absence of matching cross reference text the specs can be edited manually.

Blocks 4980 and 4981 are configured to import data at the addresses defined by the specs on each FC42. One of two things is happening right now.
1.) The source blocks are valid. I.e. Digital type exception reports(FC45, 62 etc). In this case the logic will operate whether or not you have added cross reference text.

2.) The source blocks are not valid. I.e. Do not exist or not digital exception reports. In this case the FC42 will indicate BadQ and could be 0 or 1 depending how the signals came to be BadQ in the first place.

You need to determine if the FC42 spec configuration you have now is correct.
If yes, simply add orefs to the source blocks, compile and verify the destination module and this will solve your problem. There will be no change to any module configuration.

If no, you will need to wait until you can do an online change to the destination module and then add orefs to the source blocks, compile, verify and download to the destination module.

It is possible that someone may have deleted an oref and less so that the system may lost an oref. If you think that an oref may have been lost you could go back through the system backups.
Cheers,
Alan

by ricardo.marrero.a Rank: 159 on 2/23/2020 5:21:45 PM | Like (0) | Report

Hi Alan , thanks for your response , the source blocks for both are DO/Ls ( FC 45 ) , it means they are valid , Then we need to add orefs to the source blocks , compile and verify

Thank for your support

Regards

by Geoff Michaels Rank: 373 on 2/24/2020 10:06:43 AM | Like (0) | Report

It is worth knowing that DBDOC provides the following additional checks to the configuration that are not part of Composer:
1. Missing references
2. References to blocks that do not exist
3. References to blocks that are of the wrong type
4. References to blocks that are nto exception reported
5. A simple text dump so you can compare what is compiled into the loadable .CFG file with what the CLDs say
6. Detection of the very awkward situation where an exception report is imported twice into the module - only one import block works
7. Online report of the actual specifications in the block, to remove all doubt.
There are numerous experts that either have DBDOC for their system, or as contractors, use it to make their client systems safer.

by ricardo.marrero.a Rank: 159 on 2/24/2020 10:07:36 AM | Like (0) | Report

Hi Alan , I have fixed one of them BPC-4410-STD-ES , another BPC4410-STD-SC we have the source, it is DO/L ( FC45) its tag name BB-4410-STD-SC located at PCU 21 , DI/L is located at PCU 2 ,
The question is , we know that the oref is not configured at the source , if IO Connector name in destination ( DI/L) the Status is N/C , do you think this DI/L is updated from source?

The new comment feature does not have to attach a picture of that but I think I have explained properly
Thanks for your support

Regards

by ricardo.marrero.a Rank: 159 on 2/24/2020 10:20:19 AM | Like (0) | Report

Or I can send a snapshot which it could be more detailed

Best Regards

Alan Rank: 13 on 2/24/2020 2:24:06 PM | Like (0) | Report

Hi Ricardo,
The FC42 will always update from the source according to the FC42 address specifications even if there is no oref attached at the source.

One way to check your connection is to monitor the CLD with the FC42 and look at the output of the FC42. If it is good quality, it is connected to a block at the address defined by the specs. If it is bad quality there is no connection to a source or possibly a problem with the configuration. Causes of BadQ include BadQ being propagated through the source module to the source block, which may not be a problem as such, attempting to connect to a non-exception report source block, incorrect source exception report block type, and as Geoff mentioned previously, multiple imports of the same source block into a module.

Cheers,
Alan

by ricardo.marrero.a Rank: 159 on 2/24/2020 5:45:46 PM | Like (0) | Report

Thank you Alan and Geof for your response

Best Regards

Add new comment

Alan Rank: 13

Answered 1 year ago

Question details

Cross References from Infi 90 / Composer

Answers

Other questions needing answers

Related topics

AKS experts