Part Labels display barcodes that are inconsistent or incorrect. This issue has a different resolution than when a report does not display correct barcode data in build 15.6. Click here for more information about that issue.
Build 15.6 contains an expanded ability to process with multiple processing stations. One of the reasons for this is that a User may want to direct the parts to one of several CNC machines to equalize the workload of those machines. Alternatively, while printing labels for their nesting CNC, they want to machine their remake parts on their point-to-point machine instead of the nesting machine.
When processing with multiple single parts processing stations, previously, the program would populate various data in the Parts table only for the last station of multiple stations processed. This is because that table has only a single field for the barcode data. We designed the Parts table to contain mainly un-optimized work order data. It was not desirable to change its design to support optimized data produced by multiple stations. As of the early release of 15.6, the OptimizationResults table now contains rows for all optimized parts multiplied by the number of stations used to process those parts. For example, if you are processing ten parts to three stations, the table will contain 30 rows.
The program modification required to accomplish this created an issue where the labels for one type of processing station no longer has access to the data produced by other stations. The reason is that the data for those other stations now exist on a different subset of records in the database.
As of build 15.6.1113, it is now possible to display the correct barcode data in the label from any of the multiple stations used to process that data.
When you open a Placed Part Label in the Report Viewer or Report Designer, the program now creates a dataset containing ten additional columns in the table OptimizationResults when compared to the actual database table. We have named these additional dataset columns "LinkIDStation1", "LinkIDStation2," and so on, through 10.
The names of the ten new columns represent a single processing station used to process the work order. We cannot name the columns with the names of the Processing Stations. Still, to make these internal dataset connections easier to comprehend and utilize, we sort the processing station names and apply the order of those sorted station names to the order of the dataset columns from left to right.
For example, suppose you apply the processing stations named "Default Nest," "Default Saw," and "Default P2P" to a work order when processing, and are using the revised default Microvellum label that already contains the necessary relationships. The dataset column name “LinkIDStation1” corresponds to the first sorted processing station name (Default Nest). LinkIDStation2 corresponds to the second (Default P2P). LinkIDStation3 to the third (Default Saw).
The OptimizationResults parent/child relationships within the label utilize these dataset column names to isolate the necessary data within the larger set of data in the table. Our default reports will contain ten relationships that match the ten columns in the dataset. The report relationship names are “OptResStation1,” “OptResStation2,” and so on, through 10.
Using your knowledge of the sort order of your processing stations, and left-to-right order of dataset columns, you can determine which relationship you need to use to display the necessary data on the label. If you are printing nesting labels (Default Nest), but want to print part remake barcodes produced by a single part station (Default P2P), simply use the expression {OptimizationResults.OptResStation2.Face5Barcode} in the desired barcode component.
An easy way to determine the sort order of your processing stations is to display them in the program interface. The program list is sorted in ascending order by default. Click “Toolbox Setup > Processing Station Setup” to see the list. The order of the processing stations from top to bottom in this list will be reflected in the dataset columns from left to right.
Another way to make sure you use the correct relationships in your report components is to write down each of your processing station names and arrange them with ascending sort order. Assign the number one to the first name in the sorted list, the number two to the second one in the list, and so on, for as many stations as you have set up in the list. Then as you are working in the report to set it up to display the correct data, determine which station you are printing labels for and which station contains the secondary data to include on those labels. In the example in the preceding paragraph, you want to display the part remake single part barcode on your nest label. The processing station "Default Nest" is first in the sort order (1), "Default P2P" is second (2), and "Default Saw” is third (3). Think of those sort index numbers as part of the dataset column names. Since you want the single part barcode, you know that originates with the Default P2P station, which you have assigned the number two. That means the reporting relationship to use is “OptResStation2,” consuming the dataset field “LinkIDStation2.” Enter the expression {OptimizationResults. OptResStation2 .Face5Barcode} in the required report component.
Since the new columns are not part of the database, they will not be viewable from any database management tool such as Microsoft SQL Server Management Studio, or the Microvellum SQL CE Viewer.
If you want to view the results of the dataset columns, open a report or label in the report designer using build 15.6.1113 or greater. Click the Dictionary tab and expand NewDataSet. Right-click the top-level OptimizationResults table in the dictionary and left-click View Data. Scroll to the extreme right of the table and note the columns as described above. As noted above, the work order database does not contain this data, and thus you may view it only within the dataset .
If you processed with two stations, LinkIDStation1 and LinkIDStation2 would contain data in some, but not all rows. There is no column data for rows belonging to the parent processing station. The rows that do contain data define a one-to-one relationship from the subset of parent data to separate subset of child data – a different OptimizationResults row using that column to link to OptimizationResults.LinkID. The rows that do not contain data define the subset of data that acts as the parent data alone. That means that if the first sorted processing station name is Default Nest, each cell in the column named LinkIDStation1 would contain data, except where the LinkIDProcessingStation matches the LinkID for that specific station. See Figure 3.
Since the sorted order of the processing stations determines the station referenced by any single column, you will need to give thought to the naming of any new stations you add after you configure your label to use one of the dataset relationships.
For example, let’s say you have processing stations named "Default Nest,” "Default P2P," and "Default Saw,” and you add a fourth named “Default Company Nest.” Since the sort order for the new station name locates it first in the list, that means the sort index numbers will be offset by one. What was previously the first processing station in the list is now the second. Now “Default Company Nest” is first in the sort order (1), "Default Nest" is moved to the second position in the sort order (2), "Default P2P" is third (3), and "Default Saw” is fourth (4). That means that the dataset columns are also offset by one – which also means that the dataset relationships used in your report expressions will also be incorrect.
It is a collection of data located on disk, usually on a server. This collection of data is managed by a database management system (DBMS) and is displayed in the format of tables, rows, and columns.
Since databases are contained in physical files, they are a more permanent form of data as compared to datasets. The downside of databases can be their access speed. It is significantly slower to open a database connection, extract the required data, and then close the connection than it is to access the same data from a dataset.
It is a collection of data held in the computer memory only. Think of the dataset as a ‘virtual database’ containing tables, rows, and columns. Dataset data may be extracted from a database. Once it has been retrieved from the database and stored in the dataset, the connection to the database is no longer necessary.
The advantage of using a dataset in Microvellum is the speed at which it may be accessed. It speeds up various aspects of Microvellum reports.
You may view dataset data from within the report designer, but you may not edit it. See the attached tutorial for information about how to view the data.
That depends on whether you are processing with multiple stations and need data from one type of station to be displayed on a label for a different type of station. If that description matches you, then your label will likely require modification.
Your labels should be configured with a number of dataset relationships equal to or greater than the maximum number of processing stations you would ever use simultaneously when processing for that label. You may configure your label with more relationships than required by the maximum number of processing stations you use.
It depends on the purpose of that selection box. It would be a good idea to evaluate whether you still need the selection box because of the new internal OptimizationResults relationships. If you still need it, it should still work.
If you don’t have it already, your label may require the addition of a processing station selection box to isolate and limit data to one of the nesting machines.
No. But, you will need to make sure that the system printing the labels contains all the Processing Stations that were initially used when processing the work order. You may import any missing stations from other machines where they already exist.
Yes, with the following conditions. With version 15.6.1201 or greater, these modifications apply to “Manufacturing Reports,” which are Batch style reports (have the IsBatchReport property checked ON). If the structure of a manufacturing report is similar to that of a part label in that it displays data for a single subset of rows in the table OptimizationResults, you may also apply this information to that report.
Configure a Default Microvellum Part Label Containing Pre-Defined OptimizationResults Dataset Relationships
In this tutorial, we will show you how to configure a default Microvellum Part Label that already contains the dataset relationships to match your specific combination of Processing Stations.
Add the Necessary OptimizationResults Dataset Relationships and Modify a Custom Label
In this tutorial, we will show you how to configure your custom Part Label with the addition of the dataset relationships necessary to match your specific combination of Processing Stations.
This overview article and tutorials should give you the knowledge necessary to modify other reports and labels using the same principles.
You may also experience an issue where your edgeboring barcodes or file name locations do not match the part picture depicting the edgeboring. For more information about that issue and how to correct it, click here .