When trying to follow structured data through interfaces, or across multiple uses in a project, cross-reference doesn’t always work.
This is because, when using structures, the global access path to the variable and an interface access to the variable is not the same path.
For example, consider having a Function Block that has an INOUT interface that utilizes a structure. Inside the Function Block, you access the variables within the structure like so:
The above shows that we’re using Raw_Input on lines 2 and 4, which is part of the Asset_Data structure.
This shows us where the information is written to Raw_Input, but what if we wanted to know where it is read as well? Cross referencing here just yields results for Asset_Data.Raw_Input, what if the structure is called something else on a different interface?
Using Project Search To Search For Inner Structure Variables
Project Search is great, but when you use it, it returns everything
- Comments
- Interface Variables
- Logic Variables
If you have many instances of Function Blocks that use the name of the variable you are looking for, suddenly you are looking through lots of results:
This is just as bad as no cross references, as you have a lot of information that you just don’t need to be looking through.
When doing a “normal” project search, nearly all items that you’ll find will be because the name exists in the interface. After all, we’re searching for a variable that exists in a standard structure, that means it will always be available in any object that calls that structure as an interface element.
We can reduce the amount of results by including a “*.” before the element we want to search for:
This is because now we’re searching for <something>.Raw_Value.
The subtle difference here is that the interface for objects won’t contain the “.” element. That only occurs when variables are used in logic.
Notice that the above Path values all state “..\Code” at the start, whereas previous would state “..\Interface”
Unfortunately, the Project Search doesn’t tell us if the code is reading or writing like a cross reference does (perhaps Siemens could implement this!). But we can now see everywhere that our .Raw_Value is being used and the different block objects its used within.
Limitations
There are some limitations to this:
- This doesn’t cover two structures containing the same variables, both would appear in the list as both would have “Raw_Value” for example
- This can be mitigated by having a good naming convention to reduce the need for overlap
- This can be mitigated by having a good naming convention to reduce the need for overlap
- Common sense still needs to be applied
- If you started your search because you wanted to know where the “Raw_Value” came from for a Level signal, its not going to be in the “Flow Instrument” function blocks. The search results show that the “Level Instrument” results are also available. Choosing the correct search result is still on you to do correctly.
Conclusion
Whilst this isn’t a perfect result, this does go a long way from 0 cross references, to “Oh wow, this is used in all of these places!”. A few checks are required, but it’s better than hand-sifting through blocks like we had to in SIMATIC Manager years ago!
