Table functionality to gather information is a follows:

  • Host: host name of the machine which is executing the Monitor service as shown in the Activity tab.
  • Device: select the device from the devices configuration (use and edinn® M2 Terminal to configure them) that will be used for the monitor. This is useful to trace certain information later.
  • Server: IP address of the OPC Server (OPC DA) or name of the computer providing the data (edinnHIP or edinnBOX_1, using edinn OPC Bridge).
  • Method: Any of the available methods or protocols (edinnBOX_1, edinnHIP, edinnSIM_1, Manual, OPCDA, OPCUA, Vision, VisionIP or MQTT) explained here.
  • URL: IP address of the OPC Server (OPC UA) or IP Address and port (IP_Address:Port) of the eBOX (for edinnBOX_1).
  • Endp.:  Endpoint (name of the driver for OPC UA), DCOM (Distributed COM for OPC DA) or JSON Template (MQTT).
  • Topic: tag or word to identify and group signals of the same process or group. It is very important to type here exactly the same word for signals that belong to the same process.
  • Item: has to be exactly as configured in the OPC Server for the OPCDA: identifies the exact signal or plc to monitorize, can be obtained in the OPC Server proyect. In the MQTT method the item is known as Topic.
  • Type:
    • Production: to indicate that the signal is a production counter of total results generated, including good and bad (scrap and rework) results. Records of counters need, to consolidate results, at least another identical record of totals.
    • Scrap: to indicate that the signal is a production counter of scrap results generated. Records of counters need, to consolidate results, at least another identical record of totals.
    • Rework: to indicate that the signal is a production counter of reworked results generated. Records of counters need, to consolidate results, at least another identical record of totals.
    • Consumption: to indicate that the signal is a consumption counter.
    • Generic: to indicate that the signal is generic: does not have a specified function in edinn.
    • Avail. Prod.: to indicate that the process has inputs to process available at its entrance.
    • Saturation: to indicate that the process has outputs saturating its exit.
    • Prod. Pulse: a pulse signal to indicate that a single Production result was generated. Records of pulses need, to consolidate results, at least another production counter of totals for the same topic and process.
    • Scra. Pulse: a pulse signal to indicate that a single Scrap result was generated. Records of pulses need, to consolidate results, at least another identical record of totals.
    • Rewo. Pulse: a pulse signal to indicate that a single Rework result was generated. Records of pulses need, to consolidate results, at least another identical record of totals.

WARNING: it is not recommended to use Pulses signals instead of Counters signals to count results or consumptions since the system might not read these signals fast enough or possible failures in the conexion with the OPC Server could result in an information lost. Also please remember to adjust the Check counters every parameter.

    • On/Off: to indicate that the process is working.
    • On/Off_T: to indicate that the process is working. This will take micro stops into consideration.

WARNING: To use On/Off signals can lead to errors, instead. For example: when a process is not producing anything, but the operator of the process left it powered on. It is only recommended when the process needs a lot of time (hours or days) to produce a result, and we have another way (manually or electrically) to determine when the process is working, so the system will manage On/Off signals complementary. If not, we recommend the use of production counters.

    • Good_S: counter that automatically determines the quantity of Scrap production by substracting the amount of good productions to the total amount of production. Will not calculate the quantity of Rework.
    • Good_R: counter that automatically determines the quantity of Rework production by substracting the amount of good productions to the total amount of production. Will not calculate the quantity of Scrap.
    • Good_SR: to indicate the final quantity of good results. This counter, in conjunction with the Production counter, will automatically determine the bad (rework or scrap) results.
    • RGY: when a certain button (Sched. [Schedule], Resul. [Results], Statu. [Statuses], Consu. [Consumptions], Autoc. [Autocontrol], SPC [SPC] and OEE) of an associated terminal for a certain process is blinking in red (R), green (G) or yellow (Y) the system will write a 1 in this signal. This is useful to turn on beacons.
    • LifeBit: the system will write a 1 here every minute if the data from this driver is being obtained, processed and stored correctly.This is used to light the Data On LED on eBOXes.
    • Justify: this signal will automatically justify a stop since it was activated.
    • Justify_A: this signal will automatically justify a stop since the beginning (justify all) of the stop.
    • ResChange: when this signal becomes 1, it will change the result of the assigned process to the result code indicated in the field Indic.
    • Subscription: look for the subscriptions of the process and if there are any, this signal will be written to 1.
    • Status Active: this signal will be written to 1 when the current status of the assigned process is the same indicated, by its code, in the field Indic.
    • Measure_Res: it will store the values of this signal inside the assigned process, considering the active result for the selected program and measure. This signal will enable the Prog. and Measure fields.
    • Result_Id: this signal will change the result of the assigned process. The id of the new result will be taken from the value of the signal.
    • Measure: it will store the values of this signal inside the assigned process, without considering the active result but for the selected program and measure. This signal will enable the Prog. and Measure fields.
  • Counter / Signal / UDL: to indicate the behavior of the system with the signal: used as a counter, a signal or UDL. If UDL is selected, the UDL will be executed every time the system needs to read the signal.
  • Thre (%): to indicate in percentage the threshold in the process production speed that has to be surpassed in order for the system to determine that the process is working. For example: if a process has been configured to produce 1 result per minute, if we type 50% here, we are configuring the system to consider the process as working when the process is producing 0,5 results / minute, that is a cycle time of 120 seconds.
  • (%): to indicate the minimum percentage of the cycle time established that has to be surpassed in order for the system to determine that a product has been done. If not, the system will ignore it. This is useful to avoid spurious pulses.
  • Desc.: free text to describe the signal.
  • Proc.: process to which the signal is associated. On the right you can select whether the register will be total or by pieces.
  • Cons.: type of consumption.
  • Prog.: program that will be used to store the value of this signal.
  • Measure: measure that will be used to store the value of this signal.
  • Active: if not marked, the signal is totally ignored by the system.
  • DB: if not marked, the signal is not stored into the database. Although generally not used, it is useful to monitor very fast signals.
  • Reset on: mark this check if you want the system to write into the item to reset the counter when the value of the next field is achieved. Whether you mark this check or not, type in the next field the value to which the item automatically resets, or leave 0 if the item never resets automatically.

NOTE: There is a special use for the option Reset on: when it is active and the value of the next field is 0. In this case, if the counter has a new value which is less than the previous, it will consider that is 0 instead of the new value. This special use is convenient when we have counters that do not behave correctly because they decrease instead of always increase, and we prefer to ignore those counts which are less instead of considering that the new lesser count was entirely produced. The downpart of this use is that if the lesser count is because the counter resetted and produced until the new count, that count will be discarded and considered 0. To avoid all these problems and having to use this special use, please remember that correct counters for edinn are those which never reset or reset at fixed counts.

  • To UDL: if the signal is sent to the UDL for further processing.
  • Without label: dropdown list field to relate the item (normally a Generic Signal) with an Event. If this relation is set up, and in addition the item is also related to a process (field Proc. above in this document), and that process is configured as to Trace to devices, then the value of the signal will be visible from the Registry window of a win32 terminal.
  • Send desc.: if marked, every time a result is generated, the description of the associated counter will be sent as a comment on the result record. This is useful when we have more than one signal for scrap or rework, and we want the users to be able to distinguish the source of the bad results.
  • Indic.: useful to complete the Type option:
    • Justify type: to indicate the status id to justify.
    • Scrap / Rework: to indicate the product id to define as Scrap or Rework.
    • Reschange: to indicate the product id to change.
    • Active: to indicate the status id to active the signal Status Active.
  • Deadb (%): allows to ignore small changes in this signal. For example, a deadband of 10% will ignore changes in this signal which are less or equal to 10% of the previous value. This means it will process the signal only when Abs(NewData - OldData) / OldData > Deadband, where Abs means the absolute value.
  • Delay (secs): define the time it takes for products to pass from one process to another, in a continuous workflow. This is useful when it comes to justifying the status of a process that has other dependent processes behind it. For example: if process 1 breaks down at 10:00, and the process 2 has a delay of 5 minutes, the processs 2 will be automatically justified with a "dependent" status at 10:05, instead of at 10:00.
  • User: the OPC UA user.
  • Password: the OPC UA password.
  • Refresh button: refreshes the table below.
  • Configure button: only available to configure cameras. Please see: Configure Vision.
  • Insert button: inserts the Monitor configuration.
  • Modify button: modifies the Monitor configuration.
  • Delete button: deletes the Monitor configuration.
  • Table: shows the parameters already configured.