Composer, Reference connection

Hello,

For Infi90 logics I use Composer 6.0.1.12 ver. After compile Control Logics I have no Warnings and Errors, but there is message that " Reference connection (OREF) is unused in this controller. Then I double click message it opens CLD and there is marked OREF but it has connection. It seems that its related only with INFI-90 LOOP objects AO/L, DO/L. After compile I loaded program to controller and everything works fine.

Is somebody had similar situation?

DSC_0024.JPG

Comments (0) New comment

tomas75 Rank: 443

Asked 6 months ago

Answer this question Follow

Answers

Hi Tomas,
That is normal. During compile, every unconnected OREF generates a message in the log. The message simply indicates that there is an oref configured in the controller configuration but a matching iref has not been found within the scope of the configuration. This could be due to external irefs referencing orefs in the controller being compiled. I.e. bus, loop and infinet communications cross references. As you found when you clicked on the message, the "unconnected" oref has a connection but not within the controller itself.

It could also mean however that changes have not been made correctly. One possible issue is if some copy and pasting of new logic has been done and not all instances of the pasted irefs have been updated correclty. This will leave some orefs with no connection at all and others (often the original oref) with multiple connections. It won't fail the download as such but the logic obviously won't work as expected. Another cause for these messages is incomplete demolition of logic, sparing out or deleting the logic but leaving the now unused orefs behind to confuse those who follow. It does pay to look at these messages at least for sheets you have modified.

Cheers,

Alan

Comments (0) New comment

Alan Rank: 44

Answered 6 months ago

I have the same situation on all controllers, even if there was no changes made. It's very strange, because OREF and associated IREF are filled, I can browse View connected references, I simulated values and the logics works normally. So I don’t really understand there is the problem?

Comments (4) New comment

by Geoff Michaels Rank: 510 on 2/12/2018 9:46:13 AM | Like (0) | Report

Here is a possible cause for what you are seeing, and a remedy.

In Composer, there are three tables of concern:
- XR_Base - details on every XREF
- XR_Oref - details on every OREF
- XR_Iref - details on every IREF

In a robust connection, the following sequence is followed in the innards of the Composer database:
- An OREF is created and installed in tables XR_Oref and XR_Base with a GUID that identifies it
- When any IREF that matches is created, it is installed in table XR_Iref with the above GUID
- All is good!

In a weak connection, the following sequence is followed:
- An IREF is created that does not match any existing OREF, so the entry is put into XR_Iref
- Let's assume an unresolved entry is put into XR_Base with an orphaned GUID, as it is years since I looked at this
- Later, the OREF is created and installed with a different GUID in XR_Oref and XR_Base
- When the IREF module is compiled, the OREF is found and Loop, PCU, Module and Block used for it
- When the OREF module is compiled, links are indicated to the IREFs with the OREF GUID, thus missing the weakly created one

Interestingly, the above also is the explanation for mismatches and problems when logic is cloned, worked on in another sheet or module, then imported back to the destination.

You can solve this problem quite easily using the following steps:
- Delete the IREF you are unhappy with, or the import block, keeping the text, of course, to make it easy.
- Save the CLD
- Open the CLD
- Add a blank IREF or import block
- Put the saved OREF text on it.
- The GUID for this reference will be that of the OREF and you will have made a strong connection between IREF and OREF

Poor Composer work creates these weak connections all the time. The right way to add an IREF obviously is to stop what you are doing, create the OREF you need first, save that CLD, then continue. These weak connections are extremely common in systems imported from WinCAD, too.

We worked very hard in DBDOC to avoid navigation problems from these weak connections and detect places where errors should be checked for as we go along.

I would be happy to know if you succeed with this.

by Alan Rank: 44 on 2/12/2018 3:25:46 PM | Like (0) | Report

Hi Geoff,
Some excellent points about orefs and irefs and workflows for adding cross references.

Hi again Tomas,
From your screenshot the compiler log output seems normal. Compiling 20106 should normally generate an "unused oref" message for a signal going to 20108 (the highlighted oref in your screenshot). Unfortunately, it falls to the user to determine if the unused oref is OK (a cross reference to another controller) or a potential problem (copy and paste error, other configuration error or incomplete demolition of configuration).

Thinking about this further, the compiler output log level is defined in Tools>Option>Compiler. Only level 4 (Inclusive) gives these messages whereas all other output log levels suppress unconnected oref messages (as well as all other information messages). If this behaviour has only recently been observed could the compiler output level have been set to 4? Personally, I normally use level 4 as it provides all available information from the compile.

Happy to discuss further if you have other examples that don't make sense.

Cheers,

Alan

by Geoff Michaels Rank: 510 on 2/12/2018 8:08:23 PM | Like (0) | Report

Hi, Alan.

When you said "all available information at the compile", I thought you did a fine job of avoiding saying saying that DBDOC finds all sorts of significant errors (and warnings) that Composer does not find, even at level 4. Is it valid for Composer users to be kept in ignorance of the numerous errors in their systems?

We have yet to find, in over four hundred systems, one that did not have significant errors that were not known to the owners. If anybody thinks they have a system that does not have any errors worth fixing, they are welcome to get it checked by DBDOC. It is a win-win situation. The site wins if it is checked and found to be error-free, they will be pleased. If they are informed of significant errors they did not know about, will they not also be ecstatic?

Thanks.

by tomas75 Rank: 443 on 2/13/2018 2:39:35 AM | Like (0) | Report

Thanks guys for detailed information, it explained to me how it works.
Well I try few scenarios - deleted OREF and later put new, deleted IREF and later put new, deleted OREF and IREF and later put new, of course after each action I saved and closed CLD’s, but log shows that OREF is not connected..???

Add new comment

tomas75 Rank: 443

Answered 6 months ago

Question details

Composer, Reference connection

Answers

Other questions needing answers

Related Topics

AKS experts