Chinese Language and PGP Support - New in DBDOC 10.6

DBDOC's first pass at Chinese language support was implemented in 2007, but we did not include Chinese language support for Composer, nor for PGP graphics.  In DBDOC 10.6, Chinese language support for Composer and PGP is now implemented.

Composer Sheets

PGP Graphics Descriptions

PGP Graphics


Audit Window showing where a tag is used



Text Select on graphics works on Chinese text, too!


So why not search for the text in the project?





What does it mean?



This was the easiest blog that I have ever written! Enjoy. (But our people did a massive amount of work to make it work this well.)

How Safe Is Your System From These 56 Dangers (That Your Infi 90 Tools May Never Warn You About)?

Why 56?  That is the current number of types of serious configuration errors that DBDOC routinely detects and reports.  An example of one of these issues is explained in detail later in this article.  Your system almost certainly harbors a few of these significant errors.

Read on for a review of DBDOC's ever expanding integrity management capabilities.

Since the beginning, DBDOC has been helping users find and fix system configuration issues. However, understanding and navigating the somewhat arcane log files involved was always something of an ordeal for most DBDOC users. The more intrepid among you might recognize this sort of log content, and breathe a sigh of relief that there is now an easier way. And if you've never worried about these issues before, you will see that it's now far easier than it used to be.

Dealing with errors DBDOC found (the "old" way):

Viewing issues these days, inside the interactive Error Browser:

It has taken us a dozen years, but we have finally created a system to manage these "issues". We called it Error Browser, but you can think of it as Integrity Browser, because some people take exception to using bad words. We could run a poll or survey on a new name, but the spectrum of perspectives ranges from clear to rose-tinted:

• some people that say DBDOC found an issue, and they fixed it and saved a lot of grief,
• some people that say DBDOC found an issue, but they did not fix it, and it hurt them,
• some people that say they do not have any issues,
• some people that say if their INFI 90 tools say there is no problem, there is no problem.

We run into all the above and more.

The Error Browser makes it extremely easy to view and manage errors.

Anyhow, the Error Browser was invented to give you the ability to view issues very easily, access integrated documentation to explain them, study them and mark them as "starred," "reviewed," or "hidden" (and combinations).

You can the share the work of reviewing errors among a group of users.

The next enhancement was to allow sharing of the "starred" and "reviewed" status among members of your DCS team. This also happened to solve the problem of working on more than one computer as yourself, or working on the data on your laptop. It synchronizes nicely if you connect and have new error data information.

However, I have been told that people do not have time to study the "issues" we raise, even once. So now we have made it even easier:

New in 10.6: Error Markers right on documents alert you to the presence of errors.

DBDOC Version 10.6 has "Error Markers" that show, as well as we have managed so far, where
issues exist. This means that, when you get to a configuration CLD or CAD sheet with issues, you will see the error markers.  Simply mousing over an error marker will immediately tell you something about the problem it is flagging.

A fabulous client asked: "I want to know if it is possible to turn on and off the error markers. Some areas may get quite cluttered if there are multiple error markers for a block."

Yes, indeed, on the View menu. But we suggest letting people see them, because the idea is to add our diagnostics to your trouble-shooting approach.

Some examples may be helpful.   Below are examples (from actual systems) of two of the 56 types of serious errors DBDOC detects.  DBDOC also detects on hundreds of other less serious sorts of issues, some of which are cosmetic, and some of which are generally not serious, but should be evaluated on a case by case basis.

Error Example: The Case of The Broken Timer

So here you are. You expect a timer to be working (Block 3103 in the image), but it is not. What do you see (ignore my orange oval for a moment)?



There are two warning triangles on the sheet! What could they be telling you? Click on the first one to see what it is telling you.




What? Didn't Composer flag that sort of thing? I dunno, maybe it did. Click on the second one (because it is trivial and might add some context to the issue).



Now, to get more information, you can right-click on the text [FC86] above the ETIMER Block 3102, or on the ETIMER Block itself (new in 10.6) and get access both to our "thumbnail sketch" and also to the Function Code PDF documentation.

I circled another way to get to the PDF documentation. However, our sketch is enough here.

Anyway, looking back at the misconfigured ADAPT Block 3095, you can see that it is adapting S3 (the Time units spec) of Block 3102, which is illegal. 

S5 is the Timer reset value of Block 3102, which is what it should be adapting, i.e. S3 of ADAPT Block 3095 should be 5.

The point of this is that the issue pops into view when you get to the problem sheet. Of course, you should have already gone through the issues we identified and hidden ones you found to be inconsequential. But the error markers put the issues we have found right in front of you..

Error markers are the latest enhancement to integrity management for INFI 90. You need them to step on problems before they step on you, your plant and the people in your path.

Four New Ways to Select and Search for Text On Graphics and Configuration

We've always wished we could copy and paste or search for text direct from graphics and configuration.  With DBDOC 10.6, it's now possible.

Here are four new easy ways to get text directly from graphics and configuration:

1. Right-click on any text (for example a tag name) and search for it directly:

2. Right-click on a function block hotspot (new in 10.6), and search for the function block text, or look up the associate function code documentation:

 

 

 

3. Even on a graphic, any text can now be accessed via right-click:

 

 

 

 

4. If there is text associated with a hotspot, it will be automatically loaded into the search/copy buffer for you:

 

 

Once you have the text, you can

• Look it up in the DBDOC help
• Do a full text search of your project for it
• Do a database search for it
• Find topics with that name

or just copy it and paste it somewhere else useful. 

Try it out.  This new feature is long overdue, but better late than never.

Four common scenarios (such as very large DBDOC builds) that will benefit from NEW sibling projects.

Sibling projects! Strange term. What does it mean?

New in DBDOC 10.6, the new "sibling projects" framework allows you to include configuration information from related projects in your build, without including all the documents and graphics from that project.

Here are a number of use cases:

1. Multiple Composer (and WinCAD) Projects - Build separate projects, each with the local console and still have the benefit of DBDOC checking for the existence and type of the imported blocks and tags from others projects. Relevant to people with multiple plants that have interconnections. Makes full checking possible without combining the projects into one DBDOC build, thereby including much more than is wanted for Unit 3 or Recaust area.
2. Huge Systems - We have some systems that are so big that they cannot be built into a single DBDOC project anyhow. This feature allows each large project to check blocks sourced in the other projects properly for the first time.
3. Development Projects - Build a small development project for one or more modules with the main project as a sibling project. This will give you full checking of imported blocks and tags from the rest of the system while making your limited build very quick.
4. AutoCAD Systems - Now, by building sibling projects, your build may be able to include all the AutoCAD files for an area, instead of a compromise being required because you would be building too much into one project.
5. Integrity Check for New Work - Now, you can give a contractor MASTER.DB from the main project (or projects) and let the error checking serve you so you get a tighter project done for you.

Upsides:

1. Faster, Smaller DBDOC Builds
2. DBDOC Builds Focused on Plant Areas
3. Cross-Checking Huge Projects
4. Including More AutoCAD Files
5. Integrity Check for New Work

Downsides:

1. Iteration might be necessary if interacting changes are simultaneously brought into your DBDOC builds. That is, if Project A imports new blocks from Project B, you might not pick them up when you do the first build, because the checking is done against the old build. The workaround is to build projects with changed configurations before the ones that have not changed, or rebuild if you have messages you do not expect to see.
2. "Stub modules" might have to be taken into account where some form of a module configured in another project is included in the one being built. This has been done in projects in the past where references were needed, but the actual configuration that had been cloned was not the master one.
3. Right now, our PCUMAP feature needs a full plant build to show all interactions. We intend to remove that limitation. For now, to get the full PCUMAP feature, just continue building the Composer (or WinCAD) projects without worrying about tags and graphics.
4. You need to open up the small projects with Hyperview to look at the details. The point of sibling projects is to have a nice plant focus to the DBDOC project, while ensuring interactions among projects are cross-checked. 

 

Operating / Conversion Parameters:

 

To make the feature easily available to people, we made the following decisions:

 

1. We include existing files as sibling projects as the default
2. If you have individual projects plus a plant master project, do not include the plant master project as a sibling
3. You must build projects individually, because master.db file is not available to any other project when a build is going on
4. You should review any blocks with external sources to make sure you need them now and to mark them not to have live data fetched

How to Define a Sibling Project - Single Large Project

 

Suppose you have Loop 1, Loop 2, Loop 3, Loop 4, Loop 7 and Loop 9 Composer projects all in a single large plant DBDOC project.

 

Create a new project for Loop 1. Include the consoles and databases only for Loop 1. At the "sibling project" query, make sure the the large project is selected. Go ahead and build.

 

Any blocks that are not found in the local Loop 1 project will be looked for in the sibling project or projects. Thus, both imported blocks and tags from other projects will be resolved properly and you will not have to resolve numerous "no source" messages.

 

Now create projects for the others, one at time. Mark the previously created small projects as siblings, plus the large one, until you have done the last one.

 

When all small projects are created, use BuildPlus / Tools / Project Options / Define Blocks With External Sources to de-select the large project. From now on, each small project will check the others.

 

How to Define a Sibling Project - Existing Decoupled Small Projects

 

Suppose you have Loop 1, Loop 2, Loop 3, Loop 4, Loop 7 and Loop 9 Composer projects in their own individual project. You might also have a single large plant DBDOC project.

 

Open up the project for Loop 1 in BuildPlus. Include the consoles and databases only for Loop 1. At the "sibling project" query, make sure the the large project is NOT selected, but that the other small projects are marked as "siblings". Go ahead and build.

 

Again, any blocks that are not found in the local Loop 1 project will be looked for in the sibling project or projects. Thus, both imported blocks and tags from other projects will be resolved properly and you will not have to resolve numerous "no source" messages.

 

Now modify the other projects in the same way. When you are done, you will find that "no source" messages may have disappeared. Also, if they have, you can be confident in the fact that DBDOC has probably found the PV, SP and MA blocks for station tags properly. This will be an improvement of significance.

 

How to Set Up a Development Project

 

Although not a "Holy Grail" in INFI 90, we have often been asked to support DBDOC builds for development work. Now it can be done reasonably.

 

In the case of work being done in the main Composer project, the development DBDOC project would involve the following:

• Build the main project excluding the modules under development to keep on top of imported blocks and tags from the development work
• Build only the modules being worked on in the development project, using the same Composer project and use the main project as the sibling
• Rebuild the main project with the development project as sibling if this is useful.

If the Composer work is being done in a separate project, simply make it into a DBDOC project with the main project as its sibling project.

 

The Biggest Systems in the World

 

When multiple projects exist that cannot be built within the limitation of about 20,000 documents and 2 GB DBDOC M14 file size, the technique is trivial and very valuable. Simply mark the other projects as siblings. Most "no source" messages will disappear and you will be left with the errors that could bite you.

Pac-GMCL

We'll have news fairly soon about what to expect in our upcoming DBDOC 10.6 release, but in the meantime here's something entirely non-serious: it turns out that the area around GMCL makes for a fairly decent Pac-Man map. Cheers!

DBDOC 10.5.1: What's in it?

DBDOC 10.5.1 has made its appearance this summer, with some major updates to our support for SPlus and PGP graphics, as well as completely reworked 800xA support.  Database tag records are now much clearer and complete than ever before.  And with the addition of Error Data Sharing, the first example of data sharing support for Hyperview users is now complete.


Improved Database Tag Records

One of the first changes you might notice upon upgrading to DBDOC 10.5.1 (download here), is the completely reworked presentation of database tag records in the Hyperview browser.

For historical reasons, tag records displayed in Hyperview used to look like this:

 

 

And now they look like this, which is a lot easier to read:

 

Complete Tag Information from Operate IT and SPlus

In addition, ALL data is now extracted from Operate IT (PPB and 800xA) XML database files, and are now be usefully displayed (and searchable) within DBDOC.  Previously only a limited subset of tag attributes was extracted by DBDOC and presented in the Hyperview browser.

Before:

After:

Error Sharing
 

Another change you might notice, if you were introduced to the Error Browser in the last release, is the appearance of a new checkbox list on the left hand side of the browser window.  This is a list of users on your system who are sharing their error stars and checks, which you can choose to display in your Error Browser.  This makes it easy to review errors collaboratively.   It is planned for future releases to include shared bookmarks, annotations, Watch Window groups, and Watch Window data.  

 

 

 

To participate in error data sharing, use the new Sharing tab of the Options dialog to register for sharing in a specified Shared Data Folder.  Usually the name of the Shared Data Folder will be supplied in the project file, so all you have to do to start sharing is hit OK to register.

 

 

Extended Support for SPlus and PGP Graphics
 

If you have SPlus or PGP graphics, you will notice substantial developments in DBDOC's support for these formats.  Support has been extended past the initial support of systems converted from Conductor VMS systems to include consoles converted from Conductor NT and Process Portal B. Live controller data has been added.

Extended and Reworked Support for 800xA Graphics

The support for 800xA has been completely reworked to make use of data extracted by programs from Assistance Système LD Inc. (ASSYST) giving better images, access to controller data and text searching on graphics, and eliminating the numbers and arrows seen in earlier versions using the previous approach to extracting these graphics for DBDOC.

Other Updates

In addition to the major developments described above, 10.5.1 delivers plenty of minor bug fixes and
improvements.  More DBDOC error types have now been converted to display in the Error Browser.  Live data (notably in the Watch Window) can now be requested every 100ms.  Go To Use right-click navigation in Hyperview now places system uses before DBDOC generated documents.  Timestamp labels can now be hidden in the Watch Window.   CIUMon logging has been improved in many ways.  Command line support for importing DBDOC projects has been implemented, making it much easier to migrate the DBDOC build system to a new computer.  And many more small changes which you may or may not encounter but which increase DBDOC's robustness and usefulness in specific situations.

If you haven't already, take a moment to download DBDOC 10.5.1 and upgrade your system.

Managing Errors with the Error Browser: Function Generator errors

DBDOC has noted CHECK messages for over a decade.  Errors are classified with a CHECK severity (as opposed to ERROR) when many or most of them will not actually cause a process problem, yet certain circumstances exist where they could.   ERROR severity errors should be investigated and corrected first, and then CHECK severity errors can be addressed.

One example of a CHECK error is "X coordinates out of order for F(x)", which is DBDOC's check on the order of the X coordinates in FC 1, F(x) Function Generator block.

The X coordinates (the even numbered specs from S2 to S12 for a Function Code 1 block) must be in ascending order for the block to work properly. Essentially, linearization is done stepwise, with only one pair of coordinates involved. However, many of these blocks have inconsequential errors where the output is flat, or there are minor round-off errors, or the blocks are simply not used. Some have the errors outside the design range of the calculation. It's important to identify the particular situations where an actual problem is present.


Suggested process for analyzing CHECK errors with the Error Browser

Below we work through this process in a system with 39 such errors. We will walk through the steps of figuring out which of these are potential process-affecting errors, and which can be safely hidden and ignored. This can only be determined in the context of each specific site

We open the Error Browser, set Show these errors to "All," set  Group by to "Severity" and then by to "Error Name," and press Rebuild Tree.  The tree now shows all the different types of errors in the system, organized by their severity.

In general, it makes sense to hide CHECK errors and other errors less severe than ERROR errors (e.g. COSMETIC, INTERNAL).  They will then be out of your way while you focus on the ERROR severity errors.  When you are ready, come back to the CHECK errors, and identify those that could cause problems.  In this example, it took me about a minute to analyze the 39 " X coordinates out of order" errors and identify the single one of those that was actually a cause for concern.

Here is an Error Browser procedure to follow for this error type, and generally speaking, for any other CHECK severity error:

1. Set Show these errors to "All," set  Group by to "Severity" and then by to "Error Name," and press Rebuild Tree.
2. Select the error type of interest, in this case "X coordinates out of order for F(x)".
3. Mark them all as Hidden.
4. When you have time, walk through each error, checking if the block it refers is actually used.  If it used, Star it.
5. Mark the errors that you have walked through as Reviewed.  Now they are both Reviewed and Hidden, and need not be further worried about.

Analyzing the starred error is outside this minute, of course.


Marking the "X coordinates out of order for F(x)" errors as Hidden

Click on the "X coordinates out of order for F(x)" in the tree to select all errors of that type, then click on the Hide icon to hide them.  This will get them out of your way until you are ready to walk through them in detail.  Because they are CHECK errors, they are unlikely to be causing any problems, but a few of them might be.

 

 

Walking through the errors, checking which problem blocks are actually used

 

Click on the first "X coordinates out of order for F(x)" message. You will see both the message details in the lower panel of Error Browser, and the function generator block it pertains to on the CLD in the main browser window.

• The block index shows that the F(x) block in question is used in only one place (that is, it is not imported anywhere else) [green].
• Links to complete documentation of the message are available [purple].
• The specifications [blue] are there to examine. The problem with the specifications [red] is evident. The X coordinates (even numbered specs) are decreasing, not increasing. This block will give an output of 0.8 for all inputs less than 120.0, and 23.2 for inputs more that 120.0. It doesn't work.

But you do not care, because the F(x) output is not used.  If it were used, there would be more than one entry in the Block Index.

Arrow down through all the error messages of this type, and all but one will turn out to be unused.

 

 

 

 

The F(x) block with "X coordinates out of order" that is actually used

Only one block with this error is actually used in the process.  You can see (below) that it is used because more than one item (the block source, as well as its use) show up in the Block Index.

The output value is wrong in the input range from 5.0 to 10.0. Like the negative side, it is supposed to rise linearly from 1.0 at 5.0 to 3.0 at 10.0. Instead, the output jumps from 1.0 to 3.0 when the input reaches 5.0. Analysis of the logic using the FC 16 multiply block is needed to determine how adversely this will affect the process. However, if you consider that the output is 3.0 for all values of input other than from -10.0 to 10.0 (by design), it is clear that 25% of the design effect is missing. Furthermore, one can worry about the effect of the step function in the output, something that DBDOC also has flagged.

 

Click on the Star to mark the problem error. You can also Unhide it. Now you can Rebuild Tree, which shows up whenever the Error Browser presentation would change. I also changed to show "Active" errors instead of "All", which makes all the Hidden errors not show up in the tree.
 

 

 

 

What is the error? You must be curious by now.

 

The messed up number feeds an adapt block that affects the overall gain of an APID block controlling a tag called 2LIC-459 "GREEN OIL TOWER REFLUX DRUM". The error means that there is no gradual ramping of the overall gain from 1.0 to 3.0, which might be nasty. On the other hand, GREEN OIL TOWER might no longer be used at all, or perhaps never installed, or whatever. DBDOC makes it all as easy as A, B, C.

• A - The Function Generator Block 4008 is flawed, making a step change in the value where it should be smoothly changing.  This feeds into Multiply Block 4010.
• B - The bad output from Multiply Block 4010 is fed into the Adapt Block 4011.
• C - The bad value is set into S11 of APID Block 4016.
• D - As a result, APID Block 4016 has a step change in overall gain in part of its operating range.
• E - The output signal generated will jump if the error (my guess) exceeds 5.0.
• F - Control of 2LIC-459 will be dicier than it should be, because control signals will be more extreme than designed.

 

 

 

Displaying the actual F(x) Block function, with live data

 

As an aside, DBDOC will show you the actual F(x) Block function, with its live data (but not here, because I do not have the plant data). You turn it on by right-clicking the output block number [A]  and selecting the live function graph feature [B]. Double-click on the graph [C] to dismiss it.

 

 

 

Getting more information: Help links in the Error Browser

This is as good a place as any to mention the fully featured help that is built into Error Browser, from the purple highlights above.