This file documents the enhancements and problem fixes provided with dbMASS version 3.7. Please read to stay up to date on these developments.
----------------------------------------------- Version / Published
------------------------------------------------- 3.70 / July 26, 1999
------------------------------------------------- 3.71 / August 19, 1999
------------------------------------------------- 3.72 / September 27, 1999
A new set of report layouts is provided in the "Report Layouts" database. (The Entry Fields and Custom Reports Module is required to use report layouts.) Many of the report layouts have been modified to provide a better assortment of styles which can be used as is or modified for your particular needs.
Improvements were made that will save paper for long reports and keep the data aligned properly when the report is created in a delimited format. Paper will be saved by making use of the first page header to give the report title and path to the report file. Not including this information on the regular header pages saves paper by decreasing the number of lines allocated to the header, making more room available for data on each printed page. To keep the columns of text and data properly aligned when a report is imported into a spreadsheet via a delimited format, blank text cells were added to the layouts. You can use this technique in your own layouts.
Three new report layouts are provided giving several alternatives for presenting uncertainty analysis data. The following heading discusses their use.
To make use of the report layouts you will need to copy them to your working database. Use the Database vocabulary to do this. Use "Copy to the active" database vocabulary to open the Select Database Window. Then use the "add unlisted database" button to add the Report Layouts database to your list. It is located in the dbMASS\Examples\Layouts directory. After you have added it to your list of databases, select it to finish the copy command you started. Then copy the "report layouts".
Create a personalized set of report layouts that you can copy to each new database you work on. Delete report layouts that are not being used to eliminate clutter.
The biggest enhancement with this version is the addition of uncertainty analysis by class field categories and the use of the report layouts to assemble uncertainty analysis reports. This means that if you have the Uncertainty, and the Entry Fields and Custom Reports Modules, you will be able to total the uncertainty by either the drawing tree structure or any class field structure that you define. The uncertainties are still assigned the same way they have always been, i.e., to the parts and, as desired, to the location of the instance of an entry. The only changes that you will see are that you can now include the uncertainty fields in your custom report layouts.
Start by using any of the three new report layouts provided for uncertainty analysis (see previous heading) or create your own. Just chose the report layout you want to use and create the report. For report layouts that use a class basis, you will be asked, if there are multiple classes, which class field you would like to use. dbMASS will do the rest. It can't get much easier than that.
You will probably notice that the uncertainty data will vary depending on the reporting structure. The total weight uncertainty will always be the same, however, the CG and inertia uncertainties are dependent on the hierarchy in which they are summed. This is due to the non-linear nature of the uncertainty analysis process. If you want to determine the uncertainty of all entries as if they were summed at the same level, you can use a class field without any categories or one that has no category assignments made to the entries for that particular class field.
A memory allocation problem was identified and repaired in the Report Layout Window which could corrupt memory if you pasted more than four cells without defining any new cells in-between.
The Template Window, which is a sub-window to the Report Layout Window, had a bug that would cause changes made to the height of a section to be ignored if the [return] key was used to close the window before exiting the changed height field. If you either tabbed from the field or used the mouse to depress the continue button, you would not have seen this problem. With this version the problem has been fixed.
Some enhancements and a bug fix have been made for the processes called by the Balance Window. When you use the Balance Window to balance an entry, the process is slightly different depending on whether you are balancing a part or an assembly. When a part is balanced, items are added to the part at the location required to produce the desired balance. The items, in this case, were given a spherical shape that wasn't fully defined. When the part was updated with the new features provided in version 3.53, which recalculates the items mass properties, a floating point error would result. This problem has been fixed.
Balancing an assembly did not cause this problem because new parts are created and added to the assembly but no items were assigned to the parts. With this version, these parts do have an item assigned. In all cases the item uses a spherical shape with the densest material found in the material library. So now when you balance an entry you can quickly see where the balance weights are located by displaying the particular entry balanced. The spherical balance weights are sized according to their weight.
We also found that when balancing an entry that already was balanced along an orthogonal axis the algorithms would "blow up" because of a "difference of very small numbers" problem. This condition has been address and the robustness of the algorithms improved. Let us know if you experience any strange behavior when balancing any of your entries.
This version also adds weight change tracking to the balance entry process. This was previously overlooked. So now, if you have the Weight Change Tracking Module and it is enabled, the weight change tracking window will pop up after an entry is balanced.
We found a bug in the global database update process that would cause parts which use any one of several shape types to have their mass properties summed incorrectly. This problem would only show itself if the part mass properties were calculated, not user defined, and the part included an item which used the cone, frustum, hemisphere or paraboloid shape. The calculations made when the part is defined or modified within the Items Windows were not affected by this bug. Only if the Database Maintenance Update command was run and the option to recalculate all parts was selected would the problem produce incorrect part mass properties.
To repair and verify your database first create a backup of your database and then run the Database Maintenance Update command to repair any calculation errors. If you notice any changes in the total mass properties, isolate the part(s) that were changed and inspect to see if they were using one of these shapes. Let us know if and how severely you were affect by this problem.
A problem with the Mass Distribution Reporting feature would on some occasions create a Mob No. error which would abort the operation. This problem has been corrected.
A couple of minor cosmetic problems were fixed that would cause a window to display incorrectly. The first was in the Translate Window. The "to" database label was displaying as "toto." The second problem corrected was with the Define Cell Window. If the right mouse click was used to open this window and the mouse was positioned in the same area of the screen where this window is originally drawn, the mouse cursor would cause some of the button labels to be blocked out.
A number of enhancements have been made with regard to the flow-up of class category assignments. The most significant of these is the ability to abort the class flow-up process. Now you can ignore or delay until later the class flow-up after doing a global class field update, as provided by the database update command, or after modifying an assembly or an entry's category assignment. In these situations you are normally asked to resolve which super category should be assigned if a unique assignment cannot be determined. In the past you were required to respond to each ambiguity. The only alternative was to close dbMASS. Now you can simply close the Select Window which requests the category assignment and this will abort the flow-up process. You can also use the [Esc] key which will close a displayed select category window or abort an on-going global class update.
Other enhancements have to do with the flow-up of the class categories when assigning a category directly to an entry or at the location. Now assigning a category to an entry will start the automatic category flow-up process. Assigning a category to the location previously started the flow-up process, but only if a category was already assigned to the referencing entry (super). Before, changes to the assembly were required to cause an entry category assignment to flow-up. Now it always does.
A bug was found in the Path Window that limited the last drive letter to "P." Now it will recognize drive letters up through "Z."
A bug was found that would occur when the rounding of a numeric value for the display precision would cause the magnitude of the number to change. For example, 9.96 would be 10.0 when rounded to tenths. This was being incorrectly displayed as 0.0. This problem has been fixed.
A couple of problems with the paging operations within the Bin Window have been fixed. The Bin Window is used to define a bin and the slices within the bin for mass distribution analysis. The Page Down and Page Up buttons for slices along the height dimension were not working. Also, when a page was full of slices, the page down button would not advance the display to the next screen as it should.
One of the methods used to define hierarchical relationships in the MPEX format is with indentured lists that use periods, semicolons or spaces to indicate relative parent child relationships. We discovered that when using newer versions of Microsoft Word or Excel, triple periods are automatically replaced by a single ellipsis character (...) as they are typed. (The ellipsis character is only available in the Microsoft TrueType fonts. You can expose the usage of the ellipsis character by changing to the "Fixedsys" font. The ellipsis character will be displayed as a solid block.) When this data is saved as a tab delimited file, as specified for the MPEX format, the three periods you may have typed show up as a special single character. The dbMASS MPEX import translator has been enhanced to detect this character and to interpret it as three periods when it is used to indicate indentation level.
A problem was fixed in the dbMASS Word Macros, which were not handling the "marked" headers given in the fixed format reports properly. This was only a problem if the report contained more than one section with different "marked" headers and the data of the section flowed into multiple pages. An example where this occurred was with the weight maturity report which adds a section for unassigned entries when they occur. The unassigned entries have a new header defined for that section of the report.
Fixed a problem with the Class Window that would occur when inserting/pasting a category at the top of the display (first line) on a second or beyond page. The category was being inserted at the top level instead of as a peer to the preceding category, which is the intended behavior.
A couple of minor issues were fixed in the Custom Report Layout feature. The first issue was a bug that was found in the Custom Report Layout feature that caused the description of standard parts not to be listed correctly in these reports.
The second issue pertained to the descriptions used for the data cells in class based reports. With class based reports, the main body of the report presents the categories of a class field as the primary sort. The fields for the mass properties of the categories are labeled with a preceding "Category" to clarify their unique attribute, e.g., "Category CGx". However, the data cells were given as just the mass property description, e.g., "Xcg". This worked fine but could present some confusion if the sub-element section of the report layout was also used. In the sub-element section of a class based report the data cells are for the entry data versus the category data given in the main body. In the sub-element section the entry mass properties are labeled with a preceding "Entry", e.g., "Entry CGx". The associated data cell is given as just the mass properties description, e.g., "Xcg", just as was given for the category. So both the entry and the category data cell would have the same description. Their uniqueness was given by the section of the report that they were initial inserted into, i.e., body versus sub-element. However, once added to the report, the cell data maintains its original definition even if moved from one section of the report to another. This could present some confusion because it wasn't obvious that this occurred unless one closely looked at the data given in the report. To prevent future confusion the category mass properties are now preceded with "Cat" in the data cell, e.g., "Cat Xcg".
The new descriptions for these data cells, however, will only become effective for new databases. If you suspect that some of your custom report layouts have the category and entry mass properties data cells moved into the wrong section, you will need to transfer the report layouts to a new database to visually inspect them. Be sure to copy an entry to the new database and include all the defined fields before copying the report layouts to maintain all user defined fields in the layouts. If you want your working database to reflect these updated cell descriptions, you will need to copy the data to the new database. Use the "Database Cleanup" procedure outlined in the Frequently Asked Questions document, to perform this operation.