A more efficient approach to live specs

Until DBDOC 11.1, "live specs" were a kind of live loop annotation.  Although simple conceptually, this caused a number of problems in practice.  For one thing, although "live" specs are live, in the sense that they may change, they very rarely do, and certainly not at live data fetch timescales.  So having live specs turned on for a block could cause the repeated fetching of tens of items, clogging up bandwidth for no benefit whatsoever.

In addition, it is laborious to compare the live spec values with the static spec values.

The solution in 11.1 is to display live specs integrated with normal layered specs on CADs/CLDs.  The live specs are fetched only once (or if you refresh them), and the static to live spec value comparison is done automatically, with discrepancies visually highlighted.

Note that you have to choose "Enable Live Specs" from the "View" menu in order to get this capability!

Grand Unified Table of Contents

The Table of Contents is the central unifying index of a DBDOC project file.  Until DBDOC 11.1, the "Classic" text view table of contents listed every document in the project, in a grand (and sometimes very long) list.  Although there was a certain elegance of simplicity to this presentation, when the index became tens or hundreds of pages long, its utility was somewhat compromised.

The Treeview Table of Contents was developed in response to the shortcomings of the Classic toc.  It presents a sensible hierarchical view of the project contents, and has served well.  Minor shortcomings have included the fact that it is not directly searchable, and not every index visible in Classic form can in fact be viewed view the Treeview.  Internally, of course, it also required separate maintenance.

In DBDOC 11.1, we have bitten the bullet and merged the Classic and Treeview table of contents in .  The new table of contents is hierarchical -- just like in Treeview TOC, you see the chapter headings at the top level, but instead of a tree, you simply click to display appropriate sub-indexes. 

The merged hierarchical table of contents is a solution that should capture the best of both worlds.  Now all the chapters are listed at the top level, just like in the Treeview table of contents, and you can load any of the chapter indexes with a single click. 

In future versions of Hyperview, the Treeview toc will disappear entirely, except for XP and Server 2003 systems, or when it is explicitly enabled on the command line.

DBDOC 11.1 is ready for download!

DBDOC 11.1 is a minor release that nevertheless makes considerable usability improvements to DBDOC 11.0.  If you've been holding off on upgrading from version 10.7, this is definitely a good version to move to.

Improved Hyperview startup performance

The first thing you will notice is much faster Hyperview project load times, particularly for large projects and when the dbdoc file is being loaded across a network.   Startup time is now generally faster than for equivalent 10.7 M14 files, sometimes significantly so.

New and improved table of contents

In DBDOC 11.1, we have bitten the bullet and merged the Classic and Treeview table of contents in Hyperview.  The new table of contents is hierarchical -- just like in Treeview TOC, you see the chapter headings at the top level, but instead of a tree, you simply click to display appropriate sub-indexes.  

Read more here...

Special treatment for live specs

Live specs are now handled in a far more efficient manner, fetched only once or when refreshed.  They are now automatically compared to static spec values, and discrepancies are visually highlighted.  

Note that you now have to choose "Enable Live Specs" from the "View" menu in order to get this capability!

Read more here...

File support improvements

Other notable improvements in this release include support for the new form of 800xA MDB files (800xA Version 6.0 and above) replacing Harmony Tag Exporter support that ABB removed. In addition, there is now support for Symphony Plus Engineering (SPE) 2.1 and 2.2 using PostgreSQL backups.  GPI, HGS, and HPG files are also now supported.

A wide variety of build configuration options have been added and improved as well.

Please see the Release Notes for details on the changes in this release and other releases.

New in 11.0 — Export project data

In DBDOC 11.0 you can explicitly export much of the configuration information found in the DBDOC system snapshot into a standard non-encrypted SQLite database. This exported database has similar contents to the “master.db” database produced during builds of earlier versions of DBDOC.

This database contains information about specifications, wiring, blocks, tags, and errors, all of which can be accessed by your own tools for your own purposes. Please contact GMCL for help making use of this valuable resource.

What can you do with the exported database? 

Controls enhancement

The exported database includes the specifications and the wiring in the configuration. One client is working with a controls performance monitoring package and getting the PID block parameters, control block parameters, process value range and interconnections. Applicable PID control strategies can be analyzed completely in order to improve tuning.

Calibration system

A second client is synthesizing the data needed to support an automated calibration system by relating slave parameters, analog zero and span and interconnections. Successively more complex queries will resolve as much as possible.

Alarm analysis

A number of clients have used the ability to identify the blocks feeding alarms, along with their alarm limits and sources, all easily accomplished using master.db or the exported database, to report the current limits of alarms. Identification of derived and adapted alarms are thus possible.

Welcome to DBDOC 11.0

DBDOC 11.0 is a major release, incorporating fundamental changes to the DBDOC system internals.  DBDOC was originally built on the scaffolding of the Microsoft MediaView library.  Although this was a powerful framework for its day, and has served DBDOC well, over time limitations became increasingly apparent.  DBDOC 11.0 

If you are upgrading from DBDOC 10.7 or earlier, some system-level changes you will notice include the following: 

• M14 project files have been replaced by dbdoc project files, which are about 30% smaller. 
• Builds are up to 30% faster than in 10.7. 
• There is no longer a 2G size limitation on project files. 
• CrypKey has been removed from BuildPlus, Hyperlink and CIUMon and replaced with new dongle protection.

Farewell M14 file!

When you update your installation to DBDOC 11.0, you will notice that DBDOC's faithful M14 file has retured, and been replaced by a "dbdoc" file.  This project file is usually considerably smaller than the M14 for the same system, and does not have a two gigabyte size limitation as the M14 file did.

Welcome hyperview.exe!

The Hyperview executable is now called hyperview.exe, instead of hyperview_winsock.exe.  You will notice that a modified version of hyperview_winsock.exe is also in your 11.0 installation, however.  Both are set up so that they seamlessly interoperate.  

If you attempt to open an M14 file with hyperview.exe (11.0 Hyperview), hyperview_winsock.exe (i.e. 10.7 Hyperview, basically), will be automatically started up to view it.  Similarly, if you attempt to open a dbdoc file with the 11.0 version of hyperview_winsock.exe, the new version of Hyperview will be automatically launched to display it.  

Project file wildcards (*, *.M14) are both interpreted to include dbdoc files as well as M14 files.  In most cases, this should allow shortcuts and scripts for launching Hyperview to remain unchanged.

Powerful access to the DBDOC snapshot.

In DBDOC 11.0 you can explicitly export much of the configuration information found in the DBDOC system snapshot into a standard, non-encrypted SQLite database.  This exported database has similar contents to the "master.db" database produced during builds of earlier versions of DBDOC.  

This database contains information about specifications, wiring, blocks, tags, and errors, all of which can be accessed by your own tools for your own purposes.  Please contact us for help making use of this valuable resource.

Everything looks better.

All text documents in Hyperview are now HTML, which opens up many improved formatting possibilities as well as routine Unicode support. The toolbar icons have received a facelift. Error markers no longer obscure block numbers, and live data no longer obscures function codes on CAD/CLDs. 

There are important improvements to the Watch Window, Audit Window and searching. 

You can now have large font labeling in the Watch Window, with configurable text size. Tags have been added to Watch Window plot labels, as well as better selection highlighting to make plots easier to read. You can now set a start time for the plot display, allowing you to focus easily on the most recently taken data for a group. Watch Window groups of block can now be exported and imported. 

The Audit Window has been reworked and is now easier to interpret. Audit entries that were effectively errors (e.g. unconfigured graphics) have been removed, but can still be seen in the Error Browser.  

Searching has been fully reimplemented in this release, but there should be no substantial behavior changes. 

Builds are faster, friendlier, safer, and can be larger. 

Builds are typically 30% faster than in 10.7, and project files about 30% smaller. The 2G project file size limitation is gone – test projects of close to 10G have been built. This allows a single build in cases where splitting the system would previously have been needed, and also facilitates the inclusion of more documentation types into the build. 

A new Wizard Configuration Tool lets you change Wizard settings without processing files – the new settings will be applied to the next build. 

Chapter titles generated for a build are now as short as reasonably possible, so that they can be better seen in Hyperview – only path subsets required for distinguishing paths are included. 

Improved support for SPlus and 800xA graphics. 

Presentation of dynamic bars, hotspot locations, and links to target graphics on buttons have been fixed or improved.  Support for control stations tagatoms improved on 800xA graphics. S+ horizontal dynamic bars are now properly displayed. 

Improved support for PDF, AutoCAD, MicroStation and text documentation. 

Links are now automatically made on pseudotags on these document types, very large dimension PDF files now display properly, and search results on PDF files are more accurately placed.

Iproved error and CAD support. 

New AOLDB and REDAI errors are detected. New FC 69 S1 error detected. 

CIUMon live data is more robust. 

A new monitor process tracks whether live data is being actively transmitted by CIUMon. It will disappear if CIUMon is unable to get data, freezes, or crashes. 

See the full Release Notes for further information on DBDOC 11.0 and prior versions.

 

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.

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.