By registering, you agree to the terms of service.*
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
You must login to ask question.
If you like C# you would like to have an application development kit for C# where you only have to enter username and password and access the collections and the MQTT broker directly with client stubs in C#. So to say “getting started in 5 minutes”. But I would rather have the whole package in Python and then the training data for predictive maintenance and predictive quality assurance directly as CSV file that I can easily import using Keras.
Excuse me, I have missed the second question. The answer is yes.
First, the target processing time of the operation is divided by the quality rate in order to determine how long production is expected to last, taking into account yield and scrap. Then there is a division with remainder by the intermediate setup interval from the manufacturing variant rule. This determines how often retooling will be necessary. Finally, this must be multiplied by the intermediate setup time from the manufacturing variant rule in order to obtain the cumulative intermediate setup time of the operation as specified in its manufacturing variant.
Manufacturing variants and setup matrix are used for detailed order planning. The manufacturing variants define, among other things, different delay factors for the execution of an operation at the different workplaces of a capacity group. The setup matrix defines the setup times for the transition from one material to another.
The objection is justified in principle, but in resource design the question must always be asked whether a separate data structure must be defined for each resource or whether it does not make more sense to use existing data structures more than once. Otherwise, the number of defined data structures becomes unmanageably large at some point.
In this case, the decision was made to use the same data structure in the response of the following two resources:
As a consequence, however, workplaceId and operationId must be returned in the response of both resources.
No, that’s not exactly what it means. It means that for every resource that is published, the properties must be adopted completely and unchanged. Identifiers for resources and properties must not be changed. The structure of resources and sub-resources must also not be changed. But you can omit as many resources as you like.
However, if a resource is omitted, no similar resource may be published instead. Applications developed for Bridge API should be executable on every instance of Bridge API in the same way, as long as the required resources are available.
Production resources/tools are all production resources (tools, documents, NC programs, …) stored in the ERP system for the operation. Only the requiredTools are relevant for detailed order planning. These are the tools that are required to execute an operation and are mapped as /tools in the API.
In HTTP the PUT method is used for changing a ressource. However, according to the HTTP specification for PUT, only a single resource can be changed with the method. See: https://tools.ietf.org/html/rfc7231
If several resources are to be changed at the same time, Bridge API offers the POST method. This reduces the number of method calls and ensures transaction security. This is because the forecast result would be inconsistent during the individual PUT calls. For example, if an application reads the forecast result in this time period since it was informed of the change by an MQTT event, this application would receive the inconsistent result. The entire forecast result should therefore be updated with POST, whereas the PUT method is used for rescheduling a single operation. By the way, this applies to both the forecast result and the planning result.
For the general use of the POST method in FORCE Bridge API please refer to https://docs.forcebridge.io/intro.html#http-methods-used-in-force-bridge-api
A consistency check is not performed, because when you create an inconsistent set of rules, you need not know that at some point there will be a material that meets several criteria. Inconsistency can be avoided if every material characteristic that occurs as a condition in one rule also occurs in every other rule as a condition. In your example, 3 rules result:
width=gt=40;color==black –> delay factor: 1.5 (or whatever)
width=le=40;color==black –> delay factor: 1.1
width=gt=40;color!=black –> delay factor: 2
width=le=40;color!=black –> delay factor: 1 (or whatever)
Note: If a rule is explicitly specified for a material number, it does not matter whether its material characteristics fulfill the condition of another rule. Rules explicitly formulated for a material number always overwrite all other rules.
All durations are specified in milliseconds. All key figures have a value between 0 and 1, which multiplied by 100 corresponds to the percentage value of the key figure. The key figures are derived from the time specifications. Example
Availability = Production Time / Scheduled Operating Time.
All key figures are explained in the appendix of the tutorial, please refer to