Sunday, July 9, 2017

S+ Engineering (Composer) FC248, FC226 Documentation Vagaries

I had an interesting experience when I found that there are at least two versions of the single volume Function Code Manual. What looks like the newer one is, in fact, older.
2VAA000844R0001_G_en_S__Engineering_for_Harmony_1.1__Function_Code_Application_Manual.pdf
2VAA000844R0001_I_en_S__Engineering_for_Harmony__Function_Code_Application_Manual.pdf
You might think that 1.1 is "better" than the generic one, but you would be wrong. Imagine my surprise when I found an entire new function code! FC 248 Turbine I/O Device Definition is only documented in the August 2016 version. DBDOC supports it now.















If you need documentation of the specialized Turbine I/O Device, you need the new 2016 version, or a version better than the 1.1 one from 2015.

The August 2016 version refers to SCI200 as the equivalent of CI800. Presumably, this is an official change in the designation of that module.

Here are the differences in function code 226 tables.

























































In the documentation for FC 227, there is a minor terminology improvement, from










to (in the 2016 only version)











Under S4 in Specifications, in the 2016 version, we find this additional information on the defaults defined by the baud rate.


The 1.1 version simply says: "0-7 [retries], default = 7", which is nowhere near as complete as the above.

The point of this presentation is that you should keep on top of the new function code manuals if you have new modules, or are designing for them.

Monday, December 19, 2016

Has Recent Work Introduced Errors?

You may have read this analysis of the errors DBDOC found that had been introduced into a client system over four years.

Here is another summary analysis of the important errors introduced into a different system over five years. DBDOC makes this sort of analysis trivial if you have backups of systems before and after work is done. Here are questions that should be asked:
  1. How many errors that could hurt the plant are acceptable?
  2. Why were these errors not in front of the DCS team for evaluation?
  3. How could these errors, all breaking the rules, yield a clean Composer compile?
  4. Should Composer have caught them?

Duplicate ADAPT Blocks and Multiple TSTALM Blocks

There are ten errors that result from the failure of Composer to force a cloned ADAPT or TSTALM block to have S2 or S1 set to -1 when the block is cloned.


Two of these errors are shown below. It is absolutely clear that S2 of block 1060 and S1 of block 1066 both should be 1062, not 2450. The value 2450 is residual from the working logic that was cloned into this logic. This is typical of a class of error made again and again by Composer users.


The block index for the prototype MSDRVR FC 129 Block 1062, centre of a wonderful set of beautiful functioning logic. The highlights show the four extra TSTALM block errors, so there are six of each. Not one of the errors was found when the work was done, compiled by Composer or loaded by the user.

Some Function Blocks are Defaulted as Disabled

This error message shows that one lag function was not enabled when it was added. The effect would show up as inexpicable unintended excursions that are supposed to be smoothed out. Clearly, the default should be to be enabled, not disabled.

Specification out of Range

What does this block do?
We could guess. Why should we have to? Why is this not an error in Composer, as the only legal values are 0, 1 or 2?

TSTQ Tests Block With No Quality

The work being analyzed has only two errors where a block is being tested for quality when it does not have quality to test. Only two!

First, note how the blocks with quality, shown by DBDOC as blue lines, lose that attribute when they go through logic blocks. Here, the cost of the one second lag function is the loss of quality for the pressure signal.

So, bad quality on the pressure signal will not be detected. What is it supposed to do? Simply put the FLOW CONTROL STATION into Manual. Oops!

Summary

There are fourteen potentially significant errors documented here, with many more less severe not mentioned. They should not have been made, and they should have been caught.

Friday, December 16, 2016

Analysis: DBDOC Detects Four Years of Introduced Errors

This is a summary analysis of the important errors introduced into a system over four years. DBDOC makes this sort of analysis trivial if you have backups of systems before and after work is done. Here are questions you should ask.
  1. How many errors that could hurt the plant are acceptable?
  2. Why were these errors not in front of the DCS team for evaluation?
  3. How could these errors, all breaking the rules, yield a clean Composer compile?
  4. Should Composer have caught them?
Error Browser Presentation

The builds of 2010 and 2014 versions of the Composer project show 49 significant errors that were left in the system after the work was commissioned. DBDOC shows "new" errors highlighted and allows you to focus on them. Old ones are important, too, but good work should not introduce new ones. After all, Composer is two decades old now and ought to be counted on to protect the users.

Some Function Blocks are Defaulted as Disabled

This error message shows that one lag function was not enabled when it was added. The effect would show up as inexplicable unintended excursions that are supposed to be smoothed out. Clearly, the default should be to be enabled, not disabled.


Looking at two of these messages (for Blocks 3678 and 3679), it is absolutely clear that the plant is not protected by rate limiter blocks (FC8) that were inserted to limit the rate of change. The red warning triangle shows the one we clicked on above. The yellow triangle (called an error marker) would also be visible, and you would see when you got to the logic in your analysis or troubleshooting.


TSTQ Tests Block With No Quality

The work being analyzed has thirty-seven errors where a block is being tested for quality when it does not have quality to test. None of that logic does what it is intended to do.

First, the simple error is clear. Testing quality on an output if a FC 80 M/A MFC/P block simply makes no sense. It does not work. The green arrow shows the erroneous test being carries out.


However, as is often the case, finding bad work makes you look at the intent of the logic. What was intended here?

It appears that either U1 ID FAN SUC PRESS BQ or ID MASTER IN AUTO is supposed to replace ID MASTER DEMAND with 100.0. That will not happen!

Summary

There are forty-nine potentially significant errors documented here, with many more less severe not documented. They should not have been made, and they should have been caught.

Friday, December 9, 2016

DBDOC 10.7 -- Download Your DBDOC Update Today!

We are delighted to announce the release of DBDOC 10.7, with a variety of upgrades, bug fixes, and new features.  A few of the major improvements are noted below.  For more information, please see What's New and the Release Notes.

Built-In PDF Files


If your system contains PDF file documentation, you will be happy to learn that PDFs are now first-class citizens in DBDOC, built directly into the M14 like other document types.  They can be viewed right inside of Hyperview, links to blocks and tag references are made automatically, and they can be searched like other documents.

Links to external PDF documentation are still supported, too.

See Built-In PDF Files and More! PDF File Support in DBDOC 10.7 for more information.

Configuration Change History Support


DBDOC 10.6.1 introduced the creation of DMPCFG files for both the .CFG files and the CLD and CAD sheets automatically when you do a DBDOC build.   DBDOC 10.7 introduces automatic archiving of the files from both the CLD / CAD sheets and the compiled or saved CFG files. When you do your DBDOC build, your DMPCFG files will now be archived with the error files. Also, the last build you did before installing 10.7 will be archived. Thus, you will start with a base for comparison of the last build you did with DBDOC 10.6.1 and the first with DBDOC 10.7.

See Configuration Change History Support in DBDOC 10.7 for more information.

Improved S+ and 800xA PG2 Graphics and MicroStation Drawings.


Display of S+ graphics has been significantly improved. Symphony Plus graphics rendering has been greatly improved. Splines, background colors, lines, etc. which previously were not drawn, now appear, and previously handled elements are now drawn more accurately.  The user can now also specify the path to their Symphony Plus image files in Wizard so that Hyperlink can find and use the correct image specified in a graphic. S+ and 800xA live data display sizing has also been improved. MicroStation drawings have improved text display, rendering and remove duplicate search hits.

Improved Error Detection


Processing has been extended to check more blocks for continuous exception reports.  The use of PID and APID blocks with derivative gain combined with inputs from discontinuous input blocks is reported.


"Lost Project" Recovery

DBDOC 10.7 can recover "lost" projects. A feature to recover "lost" projects has been added to BuildPlus, allowing project recovery if are inadvertently "lost" due to a change in UAC level on a machine or a user's privilege level.

There's more...


For more information, please see What's New and the Release Notes, or follow this blog, where we will be illustrating new features and DBDOC capabilities regularly.


Tuesday, November 29, 2016

Configuration Change History Support in DBDOC 10.7

Archived Text File Dumps of Configuration and CLD / CAD Source


DBDOC now reports the specifications that make up the configuration of an INFI 90 system in text files we termed "DMPCFG".  We use these dumps to cross-check DBDOC handling of the CLD and CAD files, verifying that we handle the CLDs and CAD sheets the same as the ABB compilers Composer and WinCAD (and DOS CADEWS and SLAD).

DBDOC 10.6.1 introduced the creation of DMPCFG files for both the .CFG files and the CLD and CAD sheets automatically when you do a DBDOC build.  Read about them here.

DBDOC 10.7 introduces automatic archiving of the files from both the CLD / CAD sheets and the compiled or saved CFG files. When you do your DBDOC build, your DMPCFG files will now be archived with the error files. Also, the last build you did before installing 10.7 will be archived. Thus, you will start with a base for comparison of the last build you did with DBDOC 10.6.1 and the first with DBDOC 10.7.

Changes from Date to Date


The simple application of the DMPCFG file archives is comparison and documentation of changes in blocks and specifications from any DBDOC build dates. The following examples show how any differences will be clear.

This example shows the changes made in a module in the space of three months. Having them available like this will allow them to be cross-checked against the management of change documentation. The symbol "<" indicates the old value, with ">" showing the new blocks and specs.

Comparison of May 8 to Sept 14, 2016 - Module 6,50,05

< Block 531 FC80 S1=3646 S2=5 S3=3493 S4=5 S5=0 S6=5 S7=6.0 S8=0.4 S9=1.0 ...
> Block 531 FC80 S1=3646 S2=5 S3=3493 S4=5 S5=0 S6=5 S7=6.0 S8=5.0 S9=1.0 ...
< Block 796 FC30 S1=5    S2=0  S3=0.0 S4=250.0 S5=300.0 S6=-10.0 S7=0.1
> Block 796 FC30 S1=4706 S2=17 S3=0.0 S4=6.0   S5=10.0  S6=-1.0  S7=1.0
< Block 797 FC30 S1=5    S2=0  S3=0.0 S4=11.0   S5=100.0  S6=-10.0 S7=1.0
> Block 797 FC30 S1=4708 S2=18 S3=0.0 S4=1E+006 S5=1E+006 S6=0.0   S7=1.0
< Block 3546 FC6 S1=5    S2=11.0 S3=-1.0
> Block 3546 FC6 S1=2003 S2=2.0  S3=0.0
< Block 3886 FC37 S1=1    S2=1
> Block 3886 FC37 S1=4714 S2=4719
< Block 4049 FC2 S1=961.0
> Block 4049 FC2 S1=1565
< Block 4050 FC15 S1=4048 S2=4049 S3=1.0 S4=-1.0
> Block 4050 FC15 S1=4710 S2=4056 S3=1.0 S4=-1.0
< Block 4051 FC2 S1=274.4
> Block 4051 FC2 S1=1000
< Block 4052 FC17 S1=4050 S2=4051 S3=1.0
> Block 4052 FC17 S1=4721 S2=7    S3=1.0
< Block 4053 FC2 S1=0.0
> Block 4053 FC2 S1=1.065
< Block 4055 FC9 S1=4052 S2=4120 S3=4054 S4=0.0 S5=0.0
> Block 4055 FC9 S1=5    S2=5    S3=0    S4=0.0 S5=0.0
< Block 4056 FC16 S1=2003 S2=4055 S3=2.0
> Block 4056 FC16 S1=4722 S2=4049 S3=1.0
< Block 4062 FC80 S1=4057 S2=4056 S3=4058 S4=4060 S5=4059 S6=5 ...
> Block 4062 FC80 S1=4057 S2=4713 S3=4058 S4=4060 S5=4059 S6=5 ...
< Block 4075 FC80 S1=4069 S2=5    S3=4070 ... S28=3061 S29=0    S30=0 S31=60.0
> Block 4075 FC80 S1=4069 S2=4053 S3=4070 ... S28=3061 S29=4716 S30=0 S31=60.0
< Block 4120 FC68 S1=0 S2=1.26 S3=0.74 S4=0.84 S5=0 S6=5
> Block 4120 FC68 S1=0 S2=21.5 S3=12.5 S4=12.5 S5=0 S6=5
< Block 4581 FC16 S1=4580 S2=6 S3=1.0
> Block 4581 FC16 S1=4580 S2=6 S3=0.05
< Block 4582 FC6 S1=4581 S2=200.0 S3=-5.0
> Block 4582 FC6 S1=4581 S2=10.2  S3=4.2

New blocks added:

> Block 4706 FC7 S1=4707 S2=0.115
> Block 4707 FC6 S1=1063 S2=2800 S3=0.0
> Block 4708 FC166 S1=796 S2=2 S3=5 S4=1 S5=9.223E+018 S6=-9.223E+018 S7=1.0 S8=1
> Block 4710 FC17 S1=4056 S2=4052 S3=0.5
> Block 4711 FC17 S1=4050 S2=4051 S3=1.0
> Block 4712 FC15 S1=5 S2=5 S3=1.0 S4=-1.0
> Block 4713 FC30 S1=4711 S2=117 S3=0.0 S4=5.0 S5=9999 S6=-9999 S7=0.5
> Block 4714 FC12 S1=4076 S2=1.07 S3=-9999
> Block 4716 FC35 S1=3886 S2=0 S3=2.0
> Block 4717 FC2 S1=21.5
> Block 4718 FC2 S1=12.5
> Block 4719 FC62 S1=0 S2=1 S3=0 S4=0 S5=0 S6=4719 S7=0 S8=2
> Block 4720 FC9 S1=4717 S2=4718 S3=4719 S4=0.0 S5=0.0
> Block 4721 FC30 S1=4720 S2=43 S3=10.0 S4=25.0 S5=-9999 S6=9999 S7=0.5
> Block 4722 FC3 S1=3546 S2=1 S3=0.0 S4=2.0

What Next?

This is a respectable first step, but of course these are text files, generated during a DBDOC build, and not nearly as accessible as they could be.  We would like to see support for interactive viewing and browsing of Management of Change information from right inside the Hyperview browser.

Andrew McKeown of Oji Fibre Solutions in New Zealand suggested:
  • My biggest need is around Management of Change. Knowing what has changed between each snap-shot build is an important part of managing and reconciling or even tracing changes between successive builds or across a period of time.  My contention was always that if you have the information about what is there then we should do something about seeing what has changed in detail.
  • My contention now is that you could build this into the M14 by changing the file contents so that the differences could be seen in the MoC list [showing] the change and also the hyperlink to the CAD sheet and Block.

As far as comparing from version to version arbitrarily, Andrew also sets the bar very high:
  • The trick then becomes what do you choose as the previous version to compare to [with] CFG and EWS CFG as sources plus the previous versions of the same.
  • Archiving files for comparisons to previous versions for an ad-hoc datetime difference is all well and good but you need to make this interface easy for the user.
We concur, and are starting on this and more now. The ideas of our clients will help us.  There was a time when the errors DBDOC found during builds were available only via build-level log files, but now the Hyperview Error Browser makes this information highly accessible, and links it effortlessly into graphics and configuration.  There isn't any reason why Management of Change information, changed specs and so on, couldn't be presented in Hyperview in an analogous fashion.

Would this be useful to you?

Wednesday, November 23, 2016

Text File Dumps of Configuration and Source -- A Useful New Tool

Since Version 10.6.1, DBDOC has reported the specifications that make up the configuration of an INFI 90 system in "DMPCFG" text files. We use these files to cross-check DBDOC handling of the CLD and CAD files, verifying that we are handling the CLDs and CAD sheets the same as the ABB compilers Composer and WinCAD (and DOS CADEWS and SLAD).




An offshoot of this work was that we were able to make DBDOC generate the same values as ABB compilers in the cases where we found the CFG files do not have the documented default values. Two examples are S28 of FC80 and S2 of FC 225. The documentation says each has a default value 2, but Composer and WinCAD compile a value of 0.

At the moment, you need to compare and interpret these text files manually, but look for DDBOC to do more automatically in the future.

The following example occurred this past week, and was something of a mystery to track down. DMPCFG proved its value as part of the solution.


Example 1: Mismatch Between CLD/CAD Files and the Module Load File.


A client was concerned at the failure of the blocks shown here (8120, 9498) to display live data in Hyperview.  As you can see, other blocks on the same sheet were showing live data without incident.  They speculated that the cause might have something to do with the fact that one of the blocks was an AOLDB, a new block type. 


DBDOC Analysis:


In fact, the block type issue was a red herring.  DBDOC does in fact support the newest block types added to Composer.   The fact that the values of the specifications were shown correctly was evidence for that.

The actual problem was almost certainly that the configuration in the module did not match the CLD, and the CLD is of course what is used to generated DBDOC's graphical representation of the CLD diagram.  We expected that most likely, for some reason, blocks 8120 and 9498 did not exist in the module, but that they were present in the CLD.

In order to verify this, we had a look at the DMPCFG files from the CFG (loaded into the module), and the CLD (used by DBDOC).  Surprisingly, they showed the exact opposite of what we were expecting!

CFG DMPCFG File -- 8120 and 9498 are present!
Block 8120 FC48 S1=9498 S2=16 S3=0.0 S4=50.0 S5=20.4 S6=-99.0 S7=1.0 S8=2.0 S9=2.0  
Block 9498 FC96 S1=5 S2=1254 S3=9497 S4=9.223E+018 S5=9.223E+018 S6=9.223E+018
And in the CLD DMPCFG file, 8120 and 9498 were absent. 

So then, how did 8120 and 9498 get into the CLD diagram displayed in Hyperview?  And why weren't they in the module at the time when live data was being requested and the screenshot taken?

DMPCFG File Comparison

It's clear from the contents of the DMPCFG files provided by the client, that at the point the DMPCFG files were created, the CFG did have blocks 8120 and 9498, while the CLD did not.




Left: CFG (with block 8120), Right: Source CLD (without 8120) 

Left: CFG (with block 9498), Right: Source CLD (without 9498, and with new blocks 9499 and 9501) 

What Actually Happened


This is what the sequence of events turned out to be:
  1. By October, a CLD with block 8120 FC 48 and block 9498 FC 96 had been compiled into a CFG that was loaded into the module.
  2. This same CLD was built by DBDOC into the October M14 file shown, where blocks 8120 and 9498 are present.
  3. The CLD was changed to have blocks 8120 and 9498 removed, and blocks 9499 (a new DAANG block) and 9501 added.
  4. A new M14 file was built in November, which was not being used when the problem was noticed.  However, it was this DBDOC build that generated the DMPCFG files in the comparison above, since at that moment, the CLD no longer had blocks 8120 and 9498. It had not yet been recompiled, so the CFG file remained unchanged as shown blocks 8120 and 9498.
  5. Later, the CLD without blocks 8120 and 9498 was compiled, and the resulting CFG loaded into the module.
  6. Finally, the October M14 was accidentally viewed in Hyperview, instead of the newest November one, leading to the CLD "NO CONN" screenshot first noted, as Hyperview attempted to fetch live data for blocks that no longer existed in the module.

Of course, one might ask, what caused the client to accidentally view the second most recent DBDOC M14 file, instead of the most recent one?

It turns out, when Hyperview opens an M14 specified with '*' (most users do this, because it's supposed to allow the most recent build to be opened automatically), it checks the File Creation date, which can be changed to the current date by copying the file.  This is what happened with the M14s in question -- they were copied, and the less recent of them received a newer File Creation timestamp, and thus was erroneously opened by Hyperview as the most recent M14.

We are changing Hyperview to instead look at the File Modified time for this purpose, and this modification will be seen in DBDOC 10.7.  Hopefully this will protect clients from this problem in the future.

Tuesday, November 15, 2016

Built-In PDF Files and More! PDF File Support in DBDOC 10.7

You all have PDF files, integral to the support of many systems. DBDOC now supports them in an unprecedented way.

DBDOC has supported viewing PDF files with a PDF viewer for many years. This has been very useful. However, this support lacked the full suite of features that are integral to DBDOC. The new support adds these critical features:
  • You can search for text in all the PDF documents you build in at once. Conventional searching is limited to the document you have open.
  • You can have links from the PDF file to tags in your DCS configuration. This means you can simply double-click on the tag name link and go to its source on a CLD or CAD sheet.
  • You can also have links from the PDF file to other documents. Since DBDOC supports AutoCAD, Microstation, PDF files as well as your DCS configuration and graphics files, this can give you powerful inter-connections in your documention.
Let's look at the three ways that PDF files are now supported in DBDOC.
  1. The new support to compile them into the M14
  2. The existing support to link external files to be viewed by a PDF viewer
  3. The existing support to the Function Code PDF file documentation from ABB

1. Compiling PDF files into the M14



You can now view and browse pdf files directly in Hyperview.  For most people, this support will simply replace the linking they used to do. DBDOC will be even more useful than it was. Searching, tag  and document links will be automatic. You will find it natural and satisfying.

2. Linking external PDF files to be viewed by a PDF viewer


So why would you link PDF files? One client has a very solid application involving maintenance orders. By linking fixed file names to the most recent version of the document, people get to the current version. When it is updated, the new version is linked, because the name has not changed.

This feature remains supported, so you can have very good access to the information in PDF files by compiling them, while supporting access to system-wide documents by name.

3. Supporting the Function Code PDF file documentation from ABB


DBDOC implements support for calling up the ABB Function Code PDF file information by a "right-click" on the function block image. The feature works for individual files, plus for one-volume and two-volume document sets.

Where do we go from here?


We are at the starting point in our development of this support. Your feedback about things we ought to think about will be very useful. The support is important to DCS systems supported by DBDOC.