00197458-01_UG_EDM_V2.2_en.pdf - 第84页

EDM V2.2 / U ser Guid e Ausgabe 10/2013 E dition 84 Paramete rs Setting Default Val id for Explanatio n LineDataTransferStatusMonitor. OldEntriesThreshold 30 days Data Transf er Manager Specifies t he period af ter which…

100%1 / 94
EDM V2.2 / User Guide Ausgabe 10/2013 Edition
83
6.2.7.4 Protection against Overwriting Current Production Data
In some cases, it makes sense to suppress the pushing of recipes or boards that are currently
being assembled on the production line. In the initial setting for push mode, the user at the line is
requested to confirm the push and is thus responsible for the decision as to when to import the
data. If this dialog box is not required (e.g. ConfirmAtLineServer is set to "false"), the push
would be executed immediately. The following settings delay import of the data until such time as a
new recipe is specified. The fine settings (EnableLineDataConflictChecks.Board,
EnableLineDataConflictChecks.Job,…) are related to the type of the pushed objects.
Dependent data is not taken into consideration (if, for example, a recipe is being produced that
requires component A, component A is nevertheless overwritten if a different recipe with setup A is
to be imported).
Setting Default Valid
for
Explanation
EnableLineDataConflictChecks
false
Line Enables overwrite protection.
EnableLineDataConflictChecks.Board true Line Protects the board currently being
produced.
EnableLineDataConflictChecks.Job
false Line Protects the job currently being
produced.
EnableLineDataConflictChecks.
ProductionSchedule
false Line Protects the current production
schedule.
EnableLineDataConflictChecks.Recipe true Line Protects the recipe currently being
produced.
EnableLineDataConflictChecks.Setup true Line Protects the setup currently being
produced.
Table 6-12: Settings to protect against overwriting
6.2.7.5 Settings for the Data Transfer / Push Mode GUI
Behavior
Setting Default Valid for Explanation
ClearCommentAfterDataTransfer false Data
Transfer
Manager
Specifies whether the comment
text box is to be cleared after the
push operation.
ClearDisplayNameAfterDataTransfer false Data
Transfer
Manager
Specifies whether the display
name is to be cleared after the
push operation.
ClearLineSelectionAfterDataTransfer false Data
Transfer
Manager
Specifies whether the line
selection is to be cleared after the
push operation.
ClearObjectSelectionAfter
DataTransfer
true Data
Transfer
Manager
Specifies whether the object
selection is to be cleared after the
push operation.
Table 6-13: Settings for data transfer - behavior
EDM V2.2 / User Guide Ausgabe 10/2013 Edition
84
Parameters
Setting Default Valid for Explanation
LineDataTransferStatusMonitor.
OldEntriesThreshold
30 days
Data
Transfer
Manager
Specifies the period after
which an entry in the status
monitor is classified as "old" in
the Data Transfer Manager
(and is therefore removed with
the Delete old entries
button).
History.MaxiumLength 10 Data
Transfer
Manager
Maximum number of history
entries in the Data Transfer
Manager.
Table 6-14: Settings for data transfer – parameters
EDM V2.2 / User Guide Ausgabe 10/2013 Edition
85
6.3 Workflow Configuration
The production process design varies greatly from customer to customer, which means the data
storage process also varies. Two aspects in particular stand out in this regard:
● the actual process of data flow – the dynamic part – between the central server (EDM Master
Server) and the local clients (EDM Line Servers)
● the type and amount of data to be transferred – the static part.
Both parts of the process may differ in customer processes. This section deals with the dynamic
part, the actual control of the flow of data. The configuration of the static part – the application
templates – is dealt with in section 5.1.6.
NOTICE
The workflow only needs to be configured if the default values do not work in your
environment.
6.3.1 Theory
The production process of the customer is depicted in a workflow using a finite state machine. A
finite state machine is a concept from theoretical computer science. It helps to know some
terminology to understand this concept.
A finite state machine generally consists of:
● A set of states. In the following, this set is called Q.
● Exactly one start state belonging to Q.
● A subset of Q that contains the valid end states.
● A subset of Q that contains the error states.
● A set of Events.
● A set of state transitions that cause a state q
1
to move to state q
2
when a certain event occurs.
A maximum of one transition can be defined for each state/event pair.
6.3.2 Application
6.3.2.1 Syntax and Options
The theory presented in the previous section must now be implemented in a manageable form for
actual use. This is done in the client workflow configuration file (see also section 6.2.6.21). This file
is in XML format. The following text deals with the contents of this file and how they relate to the
theory.
When starting, you will first need to declare all states, events and transitions. This is necessary so
that the workflow engine operating on the configuration file can more easily verify the finite state
machine.
First, you define the start state:
<state name="clientIdle" isStartState="true" />
In the following state declarations, isStartState="true" is not allowed to appear any more
because a finite state machine has exactly one start state.