# NoGaps – the complete user help > NoGaps (NordicGate Production System) is a web-based system for traceability, quality control and digital work instructions in assembly. This file is the user help of the app, in English. A short summary is at https://nogaps.se/llms.txt and an overview at https://nogaps.se/about. Made by Nordic Gate Product Studio, Sweden (https://www.nordicgate.se, contact@nordicgate.se). # Getting started NoGaps keeps track of **what** is built, **how** it is built and **what actually happened** to every unit. Operators scan serial number, article number and revision on the parts during production and get digital instructions between the scans. The system stops the wrong part before it is built in, and everything is saved so it can be traced afterwards. ## Signing in - Go to **https://nogaps.se** on a computer, tablet or phone. - To see how the system works first, press **▶ See how it works** under the text on the sign-in page. There are five short videos: introduction, Design, Production, Dashboard and help button, and Traceability. - At the top of the sign-in page there is **About NoGaps →** and the language choice **Svenska | English**, so you can switch language before you sign in. **About NoGaps** opens a page that describes the system, to show or send to anyone who wonders what NoGaps is (nogaps.se/about, in Swedish nogaps.se/om). It needs no sign-in. - Type your e-mail and press **Continue**. If your company signs in with the **company account** (SSO, e.g. Microsoft), you go to your company’s own sign-in and then back into NoGaps, with no password here. Otherwise the **Password** field appears; **Change** next to E-mail takes you back if you typed the wrong address. - Accounts are created by an administrator; there is no self sign-up. Usually you get an **invitation by e-mail** from NoGaps: open the link and choose your password. If you got a temporary password instead, change it under **Account → Change password** at the top right. That is also where you sign out. - With the company account the sign-in lasts a number of hours (usually a shift, decided by the company). Then it says _Your sign-in with the company account has expired_: press **Continue** and sign in again. The company account’s password is handled by your company’s IT, not in NoGaps. - **Forgot password?** Press **Continue** and then the link next to **Password** on the sign-in page, enter your address and press **Send the link**. Open the link in the e-mail and choose a new password. The link works once; if it says _The link no longer works_, ask for a new one. - Top right you choose the **language** (EN/SV), and under **Account** the **theme** (Auto, Light, Dark). The choice is remembered by the browser. - On a narrow screen or a tablet the menu wraps to more rows, so every choice shows. - If the company has several sites there is a **site chooser** next to the company name. It starts at your own site and decides what is shown first: the start page, the station list in Production and where new stations are created in Design. It is a preselection – you can change it whenever you like, and the choice is remembered by the browser. - The phone camera can read barcodes wherever there is a camera button. That needs https, which nogaps.se always uses. ## The modules | Module | What it is for | Who uses it | | ---------------- | ----------------------------------------------------------------------------------------------- | ---------------------------------- | | **Start** | The situation right now: traffic lights, plan versus actual hour by hour, open calls. | Production leads, everyone | | **Design** | The products: articles, structure, flow, instructions and release. | Process engineers, quality | | **Production** | The station: scan badge and unit, follow the instruction step by step. | Operators | | **Traceability** | The history: build records, what sits in what, which units got a given lot. | Quality, customer service | | **Calls** | The call screen: who needs help, and who is on the way. | Warehouse, team leads, technicians | | **System** | Sites and stations, people, roles, settings, AI and labels. | Administrators | | **Help** | What you are reading. Every page also has a **?** that opens the right section beside the page. | Everyone | ## What you see depends on your role You only see what your role and scope allow, e.g. one site or one customer's products. Buttons you may not use are not shown. More in Roles and permissions. ## Ask the help At the top of the help (and in the help panel) there is the box **Ask the help**, if the company has turned it on under **System → Features**. Type a question in your own words, e.g. _How do I release a new revision?_, and press **Ask**. - **The answer comes only from the help texts**, the ones you are reading now. Below the answer, **Read more:** links to the sections it comes from. Do read there, as an AI can be wrong. - If the answer is not in the help it says so and shows **Not in the help**. It does not guess. - You can ask a follow-up question straight away. **New question** clears the conversation and starts a new one. - **Thumbs up or down** below the answer tells us whether it helped. Press the same thumb again to take it away. - **Marked Uses AI.** It costs your company nothing; NoGaps pays for it, and none of the company's data is sent, only the question and the help texts. - **The conversation is kept without name and without company for 90 days**, with questions, answers and thumbs, so we can see what the help is missing and improve it. So do not write names, passwords or codes in the question. ## Add NoGaps as an app NoGaps can be added as an app of its own on the computer, the tablet or the phone. It then opens in a window of its own without an address bar, with its own icon. It is the same NoGaps and the same sign-in; nothing is downloaded from an app store. - **Computer (Chrome or Edge):** click the **Install** icon at the far right of the address bar (a screen with an arrow), or choose **Install NoGaps** in the browser menu (⋮). - **Android (Chrome):** the menu (⋮) → **Add to Home screen** → **Install**. - **iPhone and iPad (Safari):** the **Share** button → **Add to Home Screen**. Remove the app like any other app. Nothing in NoGaps is lost by that. **The app starts without a network too**, because the browser keeps the program itself (this also holds in an ordinary tab). But everything you do is saved on the server: without a network **No contact with the server** is shown, and the app carries on by itself where you were when the contact is back. See [No contact with the server](/help/production#kontakt). ## A new version is available When we have released a new version of NoGaps, a box is shown at the bottom right: **A new version of NoGaps is available.** - **Reload** fetches the new version at once. The page is reloaded, so finish what you are doing first (a step at the station, for example). You are still signed in afterwards. - **Later** closes the box. You get the new version the next time you reload the page or open NoGaps. Nothing is reloaded by itself. An open app looks for a new version about every half hour and when you come back to the tab. ## A round through the system 1. **Design:** a process engineer sets up the product – articles, structure (what it consists of), flow (operations and stations) and instructions – and quality **releases** it. See Example: a new product step by step. 2. **Production:** the operator scans their badge at the station, starts or scans a unit and follows the steps. A wrong part or wrong revision is stopped at once. 3. **Calls:** if stuck, press **I need help**. It shows at once on the call screen and the start page. 4. **Traceability:** everything that happened is in the build record, and you can search both ways: what is in the unit, and where did a given part or lot end up. > **Tip:** The pages keep explanations short. They sit behind **?**: hover over it for a short explanation. Can't find something? Press **?** on the page you are on, or **Help** in the menu and search. The help opens in a panel on the right; the page behind stays as it was, with what you typed. **Open in new tab** gives the help on a page of its own. # Roles and permissions Access is governed by **permissions**, grouped into **roles**. A person gets one or more roles, and can also get single permissions on top of them. Roles apply to the whole company; a customer's own login is limited to that customer. Roles and permissions are set under System → People. The check is made in the database, so it cannot be bypassed. The menu only shows what you may see. Without the permission for Design, Production, Traceability, Dashboards or Calls, the module is not in the menu, and if you open it by its address, it says that you lack the permission. The same goes for the pages under System, e.g. People and terminals. An operator therefore does not see Design and Traceability, but the station shows what they need to work. ## The role templates Every new organization gets six templates. They can be changed, and you can create your own (e.g. _Warehouse_). | Role | Can, among other things | | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Admin** | Everything, including people, roles, AI key and settings. | | **Process engineer** | Set up and change products in Design, articles, import from the ERP, labels, handle calls. Cannot release. | | **Quality** | **Release** in Design, change revision status (approved, use up, blocked), lot status, dispensations, corrections, traceability and export, raise problems, publish dashboards. | | **Production lead** | See the dashboard and traceability, set production goals, handle calls, raise problems and take them on, publish dashboards, force waiting times (with their badge at the operator's station). | | **Operator** | Work at the station, call for help, force waiting times only when the step allows _anyone with a reason_. | | **Observer** | Read only: dashboard, Design and traceability, and make own dashboards. Used e.g. for customers (_Sees only the customer_). | ## Changing roles and adding your own **System → Roles → Manage →** (requires the permission to change roles). The table has one column per role and one row per permission. A tick is saved at once and applies to everyone who has the role. - **New role:** type a name at the bottom, optionally choose a role to start from, and press **Add role**. - **Your own roles** have a dotted line under the name in the heading: click the name to change it. You remove the role with ✕ – when no person has the role and it does not receive calls. - **The templates** can be changed but not removed or renamed. - You cannot remove your own way in, and the company must always have at least one administrator. If a single person needs something beyond their role: give an _extra_ permission on the person instead of creating a role, see System → People. ## Qualification tags Some steps require a **qualification tag**, e.g. _Welding_ or _Final inspection_. A signature step can require the signer to have the tag. Tags are set on the person. ## Badges and personal code At the station the operator signs in by **scanning their badge**. Everything is saved in the operator's name, not the tablet's. The badge code is also the personal code for **signatures**. Badges are only visible to administrators and are set on the person under System → People. The tablet itself is signed in as a terminal. ## Customers see their own products An observer with **Sees only the customer** filled in only sees that customer's products and units – but everything mounted in them, also parts that are not the customer's. A customer never finds another customer's units. # The start page (dashboard) The start page shows the situation **right now** for the site chosen at the top of the page (see Getting started). Everything is computed from the event log and updates in real time. ## The group's board If the site has groups, there is a chooser at the top right: _Whole site_ or a group (the groups are listed under their department). The page opens on your home group, and the screen remembers what you chose last – handy for a TV by the group. On the group's board everything is the group's: - **The shift** is the group's shift that is running, and **hour by hour** is spread out from the group's targets for the shift (and targets for the whole day). - **Done in the group this shift** counts units that have finished all of the group's steps (see The group's items), not released units. - **In progress** is units whose next step is in the group. **First time right** is about the group's own tests and measurements, and the **lead time** is counted from the first step in the group to done. - **The traffic lights** are for the families whose flow has steps in the group, sub-assemblies too. **Calls**, **stopped at scan** and **where the units are** are for the group's stations. ## Traffic light per product - **Green – Running:** no problems. - **Yellow – Needs attention:** open calls at one of the product's stations. - **Red – Stopped:** a station is stopped, waiting for help. ## Key figures | Figure | Means | | --------------------- | ------------------------------------------------------------------ | | **Released today** | Finished units today, compared with the plan right now. | | **In progress (WIP)** | Units started but not finished. Sub-assemblies counted separately. | | **First pass yield** | Share released today without a failed test or measurement. | | **Lead time** | Median from start to released, last 7 days. | ## Hour by hour Plan and actual hour by hour, from the **production goals** and the shift schedule (the shift going on; shifts are set up under System → Sites and stations). Hours behind plan automatically get a comment from the calls (which station, what, how long), marked _auto_. **Write why** (on a group's board): press **✎ Write why** in the column _Why we missed_ on an hour that has been or is going on and is below plan (where something was missed), type and press **Save** (Esc cancels). The comment is shown with the name of the one who wrote it, beside the calls' comments, and cannot be changed afterwards (several people can write on the same hour). Who may write is the company's choice under System → Production: by default everyone who works in the group – those with the group as home group, those signed in at one of the group's stations and those who set targets. ## The department and the site Above the group the board answers the question **where is my help needed right now?** The department, the site and the company have the same board; only the rows differ: the department's groups, the site's departments (and groups without a department), the company's sites. Everything fits on one screen. - **At the top** four key figures: how much of the plan so far the rows have done together, how many rows are green, what is **stopped now** and raised problems **without an owner** at this level. - **Hour by hour:** one row per group or department and one column per hour of the shift. The cell shows the percent of the hour's plan, green, yellow or red (the limits are set under System → Production), the hour going on is marked with the number done so far, and later hours are empty. The plan is spread over the working time, so a break has no plan. On the right the percent of plan so far and a traffic light: red if something is stopped or the row is far behind, yellow if it is behind, has an open call or a raised problem without an owner. - **Where it hurts**, most urgent first: what is stopped, problems raised here without an owner, problems past their date, then the others. What is handled further down is only shown as a number. - **Drill down:** click a row for the board below, and the breadcrumb at the top (_Company › Kalmar › Electronics_) to go up again. Below the board (not in big screen) are the level's raised problems with owner, date, raise further and resolved. - If a board has more than ten rows, the worst are shown, and the rest as _+ 4 more on plan_. - A site without groups shows its own board as before (hour by hour in pieces). ## The company If the company has more than one site, **Whole company** is at the top of the chooser (and first in the breadcrumb). The board is the same as for the department and the site, with one row per site. Each row has the site's own clock and the shift going on there, and the columns are **hour 1, 2, 3 … of the shift** instead of clock times, so that sites in different time zones line up. A site with groups is counted as the sum of its groups, one without groups as its own targets against released units. _Where it hurts_ shows what is stopped at any site and the problems raised all the way to the company. ## Raised problems A problem the group cannot solve itself is raised to the level above: the group's department, or the site if the group has none. From there it can be raised further, always one step at a time (department → site → company), so that each level gets a chance to solve it. - **Raise** (on a group's board, requires the permission to raise problems): press **↑ Raise** on an open call or on a comment in hour by hour, or **+ Raise a problem** in the box _Raised problems_. Type what the problem is and press **Raise to …**. The same call or comment can only be raised once while the problem is open. - **On the group's board** what was raised stays, slightly dimmed, with where it is and who owns it (_↑ At Electronics · Owner: Anna_), so that the group sees that someone is taking care of it. _No owner yet_ means nobody has taken it. - **On the department's and the site's board** the problems from their groups are listed. Those who may raise problems choose **Owner and date**, **↑ Raise further** or **✓ Resolved**. A resolved problem stays for the rest of the day. - Everything is kept in the event log and cannot be changed afterwards. ## Production goals With the permission _goals.edit_ you add goals: article, quantity and day (today or tomorrow). The goals drive the plan in hour by hour. **Goals for a group:** if the site has groups, you first choose **For**: _Whole site_ or a group (your home group is preselected). For a group you also choose the shift (or _Whole day_), and the items are the group's item list. The group's goal is counted against the units that became done in the group during the shift, and is shown under the group's and the shift's name, e.g. _PCBA test · Day shift_. On the site's board the site's own goals are counted as before against released units, and the groups' goals are listed below them. On a group's board the group's goals drive hour by hour, and a new goal is for that group. ## Where the units are now Per station: how many units are **waiting** and how many are **being worked on** (activity in the last 15 minutes), and whether the station has an open call. ## Stopped at scan How many wrong parts were stopped before they were built in, last 7 days, per reason (wrong article, blocked revision …). The proof that the checks work. **Click a bar** to see the stops behind it: time, station, the unit's serial number (leads to Traceability), what was read and what was expected. ## Big screen **Big screen** shows the page without the menu, for a screen on the shop floor. Forms and small buttons (goals, _Write why_, _Raise_), the test environment line, **Report** and the ?-links are hidden, so that the board can be read from a distance. **A TV by the group:** 1. Choose the board in the chooser (e.g. the group _PCBA test_) and press **Link for a screen**. An address is copied, with site, board and big screen. 2. Sign in on the TV with a login of its own for the screen – a person with the role **Observer** is enough (it may only read) – and open the address. 3. The board opens in big screen and updates by itself. The screen remembers the board even if the page is reloaded. (Full screen needs a click, so press **Big screen** once if the browser should fill the whole screen.) **Rotation:** choose _Rotate every 30 s_ (or 60, 120) next to **Link for a screen** before copying the link. The screen then shows the board and then, in turn, each board below it (company → sites, site → departments, department → groups) and starts over. At the top right it shows where it is, e.g. _↻ 2/4_. # Calls for help A call is a signal from the station that someone needs help. It shows at once on the **call screen** and the **start page**. ## Calling from the station 1. Press **I need help** (bottom of the station page). On a phone it is the small yellow **Help** button in the station row at the top; while the call is open it shows **Call** and how long it has been open. 2. Choose **who** you need: e.g. Material, Technical, Quality or Manager. 3. Answer **Are you stopped?** Yes turns the line red until someone helps. No shows yellow – help when someone can. 4. You see when someone **acknowledges** ("Erik is on the way"). Press **Problem solved** when done. ## The call screen The menu **Calls** opens the call screen, e.g. for a screen in the warehouse. - Each call shows station, category, age and the countdown to **escalation**. The standard categories (_Material, Technical, Quality, Maintenance, Manager_) are shown in your language; a category the company has named itself is shown as it is called. - **I'm on my way** acknowledges the call. **Done** closes it. - **For me** shows only calls for you (if you receive a category), **All** shows all. - **Sound on** plays a signal when a new call arrives. ## Escalation Escalation is set up under **System → Calls** (requires the permission for settings). There is a box per category: - **Name** and **In use**. A category not in use cannot be chosen at the station. **Add category** at the bottom makes a new one. - **Step 1:** the call goes straight to the recipients (roles or people, for all sites or one). If nobody has acknowledged when the time has passed, the call is marked **escalated** (red). - **Step 2** (optional, **+ Step 2**): after a longer time the step-2 recipients get the call too, e.g. the department manager. It then comes under **For me** on their call screen, with sound. The call screen shows _Escalated · step 2 in …_ and then _Escalated twice_. No recipient means the call shows for everyone under **All**. Notifications outside the app (push, email) come later. # Own dashboards Under **Dashboards** you build your own views of what happens in production: stops, units, tests, measurements and output against plan. You choose what is shown and how, and save the dashboard for yourself or for the whole company. The feature is called _Own dashboards_ and is turned on under System → Features. **The numbers are always counted by the database**, with the same rules as the rest of NoGaps. You only see what you may see elsewhere: if your role is for a group, only the group's stations are counted. No dashboard counts per person. ## The list At the top there are four ways to start: **+ New dashboard** (empty), **The week's stops**, **Quality per article** and **Pace and standstills**. The templates are ready dashboards that you then change as you like. Below them are **The company's** dashboards and **My own**. Click a card to open the dashboard. ## Viewing a dashboard The row above the panels applies to every panel: **Period** (e.g. _Last week_ or _Last 30 days_), group, **Station** and **Article**. If you change them, it only applies to your view until someone edits and saves the dashboard. A line below the filters says so. Days, weeks and shifts are counted in the site's time, and the dashboard shows the site you have chosen at the top. - Hold the pointer over a bar or a point to see the value. On a line, every series for the same day is shown. - **Table** in the panel's corner shows the same numbers as a table. - **How it was counted** below the panel shows data, measure, period, split and filters. - A **key figure** is compared with the period just before, of the same length. For shares the difference is shown in percentage points. - A filter that does not fit the panel (e.g. station for _Output against plan_) does not apply there, and it says so below the panel. - **Copy to mine** makes your own copy of the company's dashboard that you can change freely. ## Building and changing Click **Edit** (shown if you may change the dashboard). Then you can give it a name and a description, choose who sees it, change period and filters, and work with the panels: - **+ Add panel** opens the panel window. - **←** and **→** move the panel, **✎** changes it and **✕** removes it. - **Save** saves a new version. **Cancel** throws the changes away. If you try to leave the page with unsaved changes, you are asked first. ## The panel In the panel window you choose with menus, and the preview counts at once: | Choice | Means | | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Title** | An empty title gives an automatic one, e.g. _Number of stops by reason_. | | **Data** | Stops, Units, Tests, Measurements, Output against plan or Reports, see What is counted. | | **Measure** | What is counted, e.g. _Number of stops_, _First pass yield_ or _Share near a limit_. | | **Split by** / **and then by** | Up to two: time (day, week, month, weekday, hour, minute), shift, station, group, department, article, revision, step, reason, kind of report or time between reports. | | **Show as** | Key figure, bars, stacked, line, pareto, table or cumulative. Only those that fit the split can be chosen. | | **Count as a report** | Only for Reports: one kind of report, e.g. _Step done_, or all. | | **Only the step** | One step of the instruction (family · operation · step). The step is followed through new revisions of the flow. | | **Standstill from (min)** | Only for Reports: a gap of at least this many working minutes counts as a standstill. 10 by default. | | **Width** | ¼, ⅓, ½, ⅔ or full width. On a narrow screen the panels get wider. | - A **key figure** has no split. A **line** needs time as the first split. A **pareto** sorts one split from largest to smallest and shows the cumulative share. Those that together make up 80 % are shown in full colour. - **Cumulative** needs _minute_ as the first split, see Pace and standstills. _Minute_ can only be shown cumulatively or as a table, and for at most 7 days. - With two splits the second becomes series, with a legend below the chart. More than eight series are combined into _Other_ (or, for shares, only the eight largest are shown). More than 50 categories shows the 50 largest. ## What is counted | Data | Counts | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Stops** | Rejected scans, calls that stopped the station, and forced waits. Time stopped is the time from call to resolved (an open call counts until now). | | **Units** | Main units, not sub-assemblies: started, released, scrapped, blocked, lead time (start to released) and first pass yield. A voided unit is not counted at all. | | **Tests** | Test results from the steps: number, passed, failed and share failed. | | **Measurements** | Measured values against their limits: average, lowest, highest, share outside the limits and share near a limit (within 10 % of the tolerance from a limit). Split by step: different measuring points cannot be compared. | | **Reports** | What is reported at the stations (step done, scan, test, measurement, signature, check, material, unit started or released) and the time between, see Pace and standstills. | | **Output against plan** | Released main units against the production goals. Split by group or shift uses the groups' goals, otherwise the site's. | **First pass yield** is the share of released units that had no failed test or measurement, forced wait, correction, removed component or status change on the way. A rejected scan does not count: it is mostly a misread and not a fault in the unit. Corrected events are not counted. ## Pace and standstills The time between reports shows when production runs and when it stands still. The template **Pace and standstills** has the most important parts, and the test environment has **Exempel: Takt och stillestånd** for 15–16 October. - **You choose what counts as a report** in the panel: all, one kind (e.g. _Step done_) or a single step of the instruction. - **Time between reports** is counted at each station, from the previous report there (of what you chose), in **working time**: breaks and time outside the shift are taken away. Only within the same day, so the day's first report has no time before it. If neither of the two reports is in a shift (overtime), the clock time counts. - **A standstill** is a gap of at least _Standstill from_ minutes (10 by default). The measures _Standstill (min)_ and _Number of standstills_ count them. A gap belongs to the report that ends it, e.g. when split by hour. - **The histogram** (Split by _time between reports_, Bars) shows how often it is 0–1, 1–2, 2–3, 3–5, 5–10, 10–20, 20–30, 30–60 or over 60 minutes. A tight peak to the left is the usual pace, a tail to the right is the interruptions. - **The cumulative curve** (Split by _minute_, Show as _Cumulative_) sums up over time. While it climbs, it is being built, and a flat stretch is a standstill. Standstills from the limit and up get their length written out (with one or two curves). Breaks and time outside the shift are grey. Hold the pointer over the curve to see the value of every curve at that time. - **Plan:** for _Units – Released_ the cumulative curve also draws the day's goal as a thin grey line, spread evenly over the working time. If the curve is below the line, you are behind. - **Not per person.** The time is counted per station, group, step, article or shift. If only one person works at a station per shift, the numbers can still say something about that person. Agree with the employees (and the union) on how the numbers are used. The template therefore counts per group. ## Building with AI With the feature _AI for dashboards_ on, you can describe in plain words what you want to see, and the AI builds the dashboard. - **In the list:** write in the box **Describe what you want to see** and press **Build with AI**. A new dashboard opens, and the AI builds it. - **When you change a dashboard**, the box **Build with AI** is beside the name. Ask for changes in the same conversation, e.g. _"make the pareto per station instead"_ or _"add shift"_. Every answer that changes the dashboard is marked **✓ Dashboard changed**, and the panels are counted again at once. - **Undo the AI's last change** brings back what it was before. Nothing is saved until you press **Save**. Then the conversation is saved too, so that you (or someone else who may change it) can go on later. The version is marked _AI_ in **Versions**. - **What the AI gets:** the catalog of what can be shown, the dashboard's spec, the names of stations, groups, articles and steps it looks up to filter on, and how many rows a panel gives. **Never the production's numbers and never people's names.** The numbers are always counted by the database, as for every dashboard. - **Cost:** every question is taken from the company's AI budget, usually a fraction of a cent. See AI for the key and the monthly limit. - The AI can only build what is in the catalog. If you ask for something it cannot do (e.g. per person), it says so. ## Who sees and changes - **Private** (_Only me_): only you see and change it. - **Company**: everyone allowed to see dashboards sees it. It can belong to a department or group, and then only those who may see the area see it. - The permission _See the company's dashboards and make your own_ is in every role that sees the start page. _Publish and change the company's dashboards_ is in Admin, Production lead and Quality. See Roles and permissions. - **Versions** shows every saved version. **Restore** saves an older version as a new one, so nothing is lost. - In a paused company you can look but not save. # How Design fits together In Design you describe a product so the station can build it right. Everything for a product is on **one page** with a row of steps at the top: **Product → Articles → Structure → Flow → Instructions → Release** Each step shows what is left ("2 to do"), and **Next** leads on. You can jump back and forth; nothing has to be finished in order. ## The list of products **Design → Products** is a table with one row per product and sub-assembly: customer, which sub-assemblies the product has (or which product a sub-assembly is built for), number of articles and revision. Click a row to open it. - **Search** by name, type, customer or article number. - **All / Products / Sub-assemblies** shows just what you want, and **Drafts only** what is not released yet. - **Sort** by clicking a column header (once more reverses the order). - Sub-assemblies of the same type are under a shared heading that can be folded. Those alone in their type come last, under **Other sub-assemblies**. ## The idea: sub-assemblies that come from the structure - The **top level** is the product and its articles, e.g. eight variants of a pump. - A part you **build yourselves** – for example a motor unit or a housing – becomes a **sub-assembly** with its own articles, flow and revision. You create it with **+ Make sub-assembly** in the structure. - Sub-assemblies are called what you call them (Motor unit, Housing …). The system has no fixed levels: the top and each sub-assembly is a level. - A sub-assembly can be used in **several products** (the same motor unit in two pumps). It then has one flow and is released on its own. - A sub-assembly built **to stock** is built first, on its own, and **scanned in** as a part of the level above. The top gets its own serial number. ## Sub-assembly type: the same kind of sub-assembly together Often the same _kind_ of sub-assembly is built a little differently for different products – one base unit for one computer and another for the next. If you want to change them separately, they become **separate sub-assemblies**, each with its own flow and revisions. Give them the same **Sub-assembly type** (the first step, **Sub-assembly** → _Sub-assembly type_, e.g. _Base unit_), and they are gathered under a shared row in the table under **Products**, with the number of variants and articles (press the row to fold or unfold). Each variant shows which product it is built **for**. A sub-assembly gets the type of the position it is built at in the structure automatically; change it if needed. If the process is the same for all variants, put the articles in **one** sub-assembly and handle the differences with conditions on the steps – then one change is enough. ## Two revisions: product and instruction The **product revision** is the article's revision in the register (e.g. 03 or 1.0.1). It changes when the design changes. The **instruction revision** (/1, /2 …) is a running number per level (the top and every sub-assembly) that goes up every time the structure, the flow or the instruction is released in a new version, and never starts over. They live their own lives, and the build record shows both: _Product rev 03 · Instruction /5_. More in Release and revisions. ## Draft and released Everything new is a **draft**. Nothing reaches production until it is **released**, and what is released is locked. To change it you start a new revision (**Change (new revision)**), a copy to work in. Labels are the exception: they belong to the article and can be changed at any time. ## Free while drawing, strict when releasing You may leave things half done. **Ready for release** (the last step) shows everything that must be fixed, with a **Fix →** button that takes you to the right place. Red items block the release, yellow ones are warnings. The steps at the top show e.g. _1 to do_ in red, and at the bottom of each step it says _1 left here_. Hover over either (or tap the text at the bottom) to see what they are, with **Fix →** on each row. ## Where do I find … | I want to … | Go to | | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | create a new product | Design → **+ New product** | | create a sub-assembly on its own | Design → **+ New sub-assembly** (or in the structure: choose the part → **+ Make sub-assembly**) | | add a customer | **+ New product** or the **Product** step → the _Customer_ field → **+ New customer…** at the bottom of the list | | add articles from the ERP | step **Articles** → _Paste from ERP or Excel_ | | say what sets the articles apart (size …) | step **Articles** → _Properties_ | | decide which parts each article has | step **Structure**, the matrix | | make a part something we build ourselves | **Structure** → choose the part → **+ Make sub-assembly** | | build from the bottom up (sub-assembly first) | create the lowest with **+ New sub-assembly**, then choose it in the next: Building from the bottom up | | create operations and stations | step **Flow** | | write instructions, measurements, signatures | step **Instructions** | | see the instruction as the operator will | **Instructions** → **Preview** | | decide how a label is read | **Structure** → **Show labels** | | approve or block a revision of a part | Design → **Article register** | | delete a product | step **Product**, at the bottom | # Example – a new product step by step Here we build a small product from scratch: a **pump in two sizes** where we build a **motor unit** ourselves that is scanned into the pump. Try it in the test environment – the product can be deleted afterwards. | Top article | Name | Size | | ----------- | ------- | ---- | | `PX-25` | Pump 25 | 25 | | `PX-40` | Pump 40 | 40 | ## 1. Create the product 1. Go to **Design** and click **+ New product**. 2. Type the name _Pump PX_, choose a customer (or _Own product_) and click **Create and start**. 3. You land in the step **Articles**. The product is **instruction /1**, draft. ## 2. Articles and properties 1. Under **Properties** type `Size` and the values `25, 40` and click **Add**. 2. In **Paste from ERP or Excel** paste (tab or semicolon): ``` PX-25; Pump 25; A; 25 PX-40; Pump 40; A; 40 ``` 3. Click **Add articles**. The size is filled in from the last column. If the articles already exist in the register, type the article number in the field under the table – a list shows matches from the register. ## 3. The structure: the tree 1. Go to **Structure**. The top level is selected. Click **+ Under**, type `Motor unit`, press Enter. Type `Nameplate`, Enter. Click **Done**. 2. Click **Nameplate** in the tree and then **SCAN** so it becomes **NO SCAN** (a nameplate is not scanned). 3. Click **Motor unit** and then **+ Make sub-assembly**. The motor unit becomes a sub-assembly (marked _Sub-assembly_ in the tree), built to stock, with its own articles, flow and revision. 4. With **Motor unit** selected: **+ Under** and add `Motor` and `Screws`. Make **Screws** **NO SCAN**. ## 4. The structure: the matrix The matrix has a column per top article and a row per position. Click a red **Choose…** cell: 1. **Motor unit** for PX-25: type `PM-25` in the search field, choose **+ PM-25 – create it as a new part**, type _Motor unit 25_ and click **Create and use**. The next empty cell is chosen automatically – create `PM-40` _Motor unit 40_. 2. **Nameplate:** click the cell, choose **All** under _Quick_ and pick an article from the register (search), or create one. 3. **Motor** under Motor unit: pick the motor for **PM-25** and for **PM-40** (if they are not in the register: type e.g. `M-25` and create _Motor 25_ the same way). The choice belongs to the motor unit's article – it applies to every top that uses that motor unit. 4. **Screws:** choose **All** and the same article. **n/a** means the parent is not in that article. **—** means "not used here" (e.g. a pressure sensor only some have). ## 5. The flow The step **Flow** has one block per level, the top first. 1. In the **Motor unit** block: type `Assemble motor unit` and click **+ Operation**. Choose a station (or **+ New station…**). 2. Under _to mount here_ choose **Choose where it is mounted → Assemble motor unit** for **Motor**. The scan step is created by itself. 3. In the top block: create `Final assembly`, choose a station, and mount **Motor unit** at **Final assembly**. The motor unit block's heading now says _Finished → stock → scanned into Pump PX at "Final assembly"_. More operations are linked with **Feeds into**. The **Flow chart** tab shows the whole. ## 6. The instructions 1. Go to **Instructions** and pick **Final assembly** in the list. The list reads from the top: the last operation on top. 2. Click **+ Instruction**, type the title _Fasten the lid_ and the text. The toolbar gives bold, size and lists. Add a **picture** too. 3. Click **+ Measurement**: _What is measured_ `Torque`, _How_ _Read from a tool_, Min `8`, Max `10`, Unit `Nm`, Readings `4`. 4. A step for size 40 only: open the step, choose **Which articles does this step apply to? → Articles with a property… → Size = 40**. 5. Click **+ Signature** and choose who may sign (e.g. _Final inspection_). 6. Click **Preview** and choose PX-40 to see the instruction as the operator will. ## 7. Release 1. Go to **Release**. The list shows everything left – **Fix →** takes you there. 2. When nothing is red, someone allowed to release (e.g. Quality) clicks **Release all 2 levels**. The motor unit and the pump are released together, bottom up. 3. Now the stations can build: first the motor units (to stock), then the pumps – where the motor unit is scanned in. > **Delete the example:** step **Product → Delete product** (possible as long as no units have been built). # Articles and properties The step **Articles** shows the product's **top articles** – what is sold and has its own serial numbers. The articles of the sub-assemblies come from the structure. ## Adding articles - **From the register:** type in the field _Article number_ under the table. A list shows matches on number and name. Grey articles already belong to another product and cannot be chosen. Pick one and click **Add**. - **New article:** type a number that does not exist. It says _New article – it is created in the register too_, and the button says **Create**. - **Many at once:** paste from the ERP or Excel, one article per line: number, name, revision, then the property values. Tabs or semicolons. - **Edit** (✎) opens the row: change the article number, name and latest revision, and click **Save**. The name can always be changed. The number and the revision are on the labels and in the build records, so they can only be changed until something has been built or scanned with them – then the field is locked and says why. A revision in use is replaced by a new revision in the Article register. - **Remove** (✕) takes the article out of the product, together with its property values and its column in the structure. It stays in the register. An article that is released in the product cannot be removed here: set it to _Obsolete_ in the Article register. - **New – not released** is shown on an article added after the product was released. It needs no new revision: choose its parts in Structure and release it in Release. See A new article after the release. A new article's first revision is _approved_ if you may set revision status (e.g. Quality), otherwise _not assessed_ – see The article register. ## Properties (options) Properties describe what sets the articles apart, in your words: _Size 25/40_, _Material Standard/Stainless_, _Sensor Yes/No_. They are used to: - decide **which articles a step is for** ("Fit reinforcement" only for Size = 40), - choose quickly in the matrix (**With property…**), - get an overview (the values are shown under each column of the matrix). Properties **never choose parts** – that is done in the structure. ## Editing a property Click **✎** by the property: rename it, rename values, add values or remove. A value used in a condition cannot be removed (you are told). Renaming does not affect any conditions. ## None – an active choice In the article table each property has three kinds of choice: | Choice | Means | | -------- | ---------------------------------------------------------------------------------------------------------------------- | | **–** | Not decided yet. _Ready for release_ warns. | | a value | The article has the value. | | **None** | Actively chosen that the article has no value. No warning, and conditions on the property do not apply to the article. | ## Inherited downwards Properties are set on the top articles but **inherited downwards**: a sub-assembly only used by tops of size 40 has Size = 40. That is why a condition like _Size = 40_ also works on the sub-assembly's operations. If the tops using a part disagree, the part has no value. # Structure – the tree and the matrix The structure says **what** each article is built from. It has two parts: the **tree** on the left (the positions) and the **matrix** on the right (which article number sits in each position of each top article). ## The tree - The **top level** is the product. Under it are the positions: _Motor unit_, _Nameplate_, _Box_ … - Names are chosen from the company's **library** (suggestions as you type) or typed freely – a new name is added to the library. - **SCAN / NO SCAN** on each position: is the part scanned in production? Consumables, software and packaging usually are not. ### The tool row Select a position in the tree and use the tool row: | Button | Does | | ------------- | ---------------------------------------------------------------------------------------------------------- | | **+ Under** | Add a part under the selected one. If the selected one is a bought part it first becomes a _sub-assembly_. | | **+ Next to** | Add a part on the same level. Enter adds and lets you type the next. | | **↑ ↓** | Move up or down. | | **← →** | Move out one level, or in under the part above. | | **✎** | Rename (or double-click the name). | | **✕** | Remove (click twice). Also removes what is below. | You can also **drag** ⋮⋮: drop _on_ a part to put it under it, or above/below to place it next to it. ## Sub-assembly – something you build yourselves Select a bought part and click **+ Make sub-assembly** in the panel under the tree. The part becomes a **sub-assembly**: its own family of articles with its own positions, flow and revision. The articles you choose in that position in the matrix become the sub-assembly's articles. In the tree it is marked _Sub-assembly_. - The **name of the sub-assembly** can be changed in the panel. - **Built:** _To order_ or _To stock_. A sub-assembly built to stock is built on its own and scanned into the level above. The choice follows the revision: it is changed in a draft, applies when the draft is released and is locked when the revision is released (see [What applies at once?](design-release#direkt)). - **…or use something that already exists:** pick from the list instead of creating a new sub-assembly. It has sub-assemblies already used in other products and things you set up on their own first, see below. ## Building from the bottom up Many set up the lowest part first and work upwards, for example _part → sub-assembly → larger sub-assembly → top level_. That works just as well as from the top: 1. Create the lowest with **+ New sub-assembly** on the Products page (e.g. _Motor unit_): articles, structure, flow and instructions. It is listed under _Sub-assemblies_ with the text _Not used in any product yet_, and can be released and built right away. 2. Create the next with **+ New sub-assembly**, or with **+ New product** if it is what you sell (e.g. _Pump_). In **Structure**: add a position (e.g. _Motor unit_), select it and choose _Motor unit_ under **…or use something that already exists**. 3. Click the cell in the matrix and choose which article of the sub-assembly sits in which article. The sub-assembly's own articles come first in the list. 4. Continue upwards the same way. **Chose wrong?** The **Product** step has the field _This is_, where you switch between _Product_ and _Sub-assembly_. What is built into something else always counts as a sub-assembly, even if it was created as a product. Something cannot be built into what it is itself part of. ## The matrix One column per **top article**, one row per position (the whole tree). Click a cell to choose the part: 1. **For which articles?** The clicked one is selected. Add more with Ctrl-click, or with **Quick**: _All_, _Empty ones_, _None_, _With property…_. 2. **Pick the part.** At the top is what is chosen _now_. Type in the search field (article number or name) – the search covers the whole register. Without a search the tabs show **Suggested** (parts already in the position or belonging to the level), **Whole register** and **Recent** (what you chose lately in this browser). Click a row, or move with ↑ ↓ and choose with Enter. The chosen row says **✓ Chosen**. **—** means _not in these articles_. If the number does not exist, **+ NUMBER – create it as a new part** is last in the list: choose it, type the name and click **Create and use** (or **+ New part** for an empty form). ### The choice belongs to the parent article A part under a sub-assembly belongs to **the sub-assembly's article**, not to the top. Choosing the motor for motor unit _PM-25_ applies to every top that uses PM-25. The cell editor shows _used by …_ under each choice. ### What the cells mean | Cell | Means | | --------------------------- | ---------------------------------------------------------------------------------------------------- | | **Choose…** (red) | No part chosen yet. | | article number + r-revision | The part and its approved revision. | | **—** | Not used in that article. | | **n/a** | The parent is not in that article. | | **↑ choose first** | The sub-assembly above has no article in that column yet. Choose it first in the sub-assembly's row. | | _same in all articles_ | The row has the same part everywhere (shown as one cell). | | **+1 rev** | The position has another part from a revision. | ## Another part from a revision When an article gets a new revision where a part is replaced by one with a **new article number** (e.g. a TFT from a new supplier), no copy of the structure is needed. The position's usual part stays, and you add an **exception** for the new revision: 1. Click the cell for **one** article. At the bottom of the cell editor it says **4. Another part from a revision of …**. 2. Click **+ Another part from a revision**, choose which revisions (e.g. _from 1.0.1_) and choose the part. **—** means the position is _not used_ in those revisions (a part that goes away, or that only exists in older ones). 3. Change the revisions right in the row, **Change part** or **Remove**. The choices are the same as in When does the step apply?. The cell in the matrix gets the mark **+1 rev**. **At the station** the unit's revision decides: an exception that holds for the revision gives its part, otherwise the usual one. Every row has its own alternatives, see Alternatives. Scanning the wrong part stops as usual, and if the position is not used for the revision the scan step is skipped. The article number in the instruction text is right too. **Ready for release** stops if two exceptions hold for the same revision. A new revision of the article must then be released before it can be built, see A new revision of an article. The structure is locked after release, so the exception is added in a new revision of the level (**Change (new revision)**). ## Alternatives – another supplier A bought part can have **alternatives**: another article with the same function, e.g. an RJ45 connector from another supplier. At the station both the part and the alternatives are accepted, each with its own approved revision. 1. Click the cell for **one** article. Under **5. Alternatives for …** the usual part and every exception with a part are listed, one row each. 2. Click **+ Alternative** on the row and choose the article. ✕ removes an alternative. **Every row has its own alternatives.** An exception (e.g. _from 1.0.1 → 4105-01_) thus has other alternatives than the usual part, and they only hold for those revisions. When the exception's revisions change the alternatives follow, and when the exception is removed its alternatives go. When a change makes a new revision, today's alternatives come along to it. There are no alternatives for sub-assemblies built here. ## Fill from bill of materials **↓ Fill from bill of materials** takes lines like `parent article; position; part` (from the ERP or Excel) and fills the empty cells. `—` as the part means _not used_. ## Show labels **Show labels** puts a dot by every scanned article: green = tested label, grey = no format yet, red = an example is read wrongly. Click a cell (step 3 of the cell editor) or a **column header** (the top article's own label) to set up how the label is read. See Labels. ## On a phone On a phone, Structure shows **The labels in the product** instead of the table: every article that is scanned, with the same dots, and those without a tested label first. It is made for walking round the first parts and teaching the system their labels. 1. Press **Scan label** and point the camera at the label (or type the code in the field below). 2. The system finds the article: if the label is read already it says so, if an article number is in the code that article opens at once with a **proposal** for how the code is read, otherwise you pick the article in the list. 3. Check the proposal and press **Save format**. **Scan next** at the bottom takes the next part. Press an article in the list to see or change how its label is read. **Show the whole structure** shows the table; the structure itself is easiest to change on a bigger screen. ## Locked after release A released structure cannot be changed. Click **Change (new revision)** in the panel of the level you want to change, or in the box that opens when you click a locked cell – only that level gets a new revision. The exception is an article added after the release (marked **New – not released** in the column heading): its cells are open and are filled in without a new revision. The released articles in the same box have a lock (🔒) and are not changed by your choice. See A new article after the release. # Flow – operations and stations The flow says **where and in what order** each level is built. The instructions are written in the next step. ## One block per level The step **Flow** has one block per level – the top and every sub-assembly – with the top first. The block's heading says where the finished article goes: _Finished → stock → scanned into … at "…"_, or in red that it is not mounted anywhere yet. ## Operations - **+ Operation** (the last card in the block) adds an operation. The new one is linked after the last. - Choose the **station** in the list. If the company has several sites, the stations at the chosen site come first. With the right permission there is **+ New station…** right in the list: a small form opens on the operation: type the station **name**, choose the **group** (or _+ Group…_ and type its name) and click **Save**. The station is created at the site chosen at the top of the page, and can be moved afterwards under System. - **Feeds into** decides the order. Parallel tracks join by feeding into the same operation. The lines are redrawn. - **✎** renames, **✕** deletes (click twice). ## Parts to mount Every **scanned** position must be mounted at an operation. The yellow field _to mount here_ lists them with a red frame until they have a place – choose **Choose where it is mounted**. The scan step is created by itself and shows as a chip on the operation (✕ removes it). A sub-assembly is shown as _from stock_. ## The flow chart The **Flow chart** tab shows all levels in one picture: solid line within a level, dashed where a finished article comes in from the level below. Click an operation to open its instructions. ## Locked after release A released flow is locked. **Change the flow (new revision)** in the block heading gives the next instruction revision (e.g. /1 → /2) for that level. # Instructions – steps, conditions and preview This is what the operator sees at the station. The list on the left reads in one direction: **the last step on top**, the top level first. ## Kinds of step | Kind | The operator … | | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Scan** | scans the part. Created by the flow ("Choose where it is mounted") and follows the structure: the right article and an approved revision are checked. Can have its own text and pictures. | | **Instruction** | reads and confirms. | | **Measurement** | types or reads values (with limits), or gives pass/fail. | | **Signature** | signs with a personal code. Can require a qualification tag. | | **Wait** | waits a set time (curing, drying). The next step is held until the time has passed. | | **Label** | presses **Print the label**. The step is done when the label has come out (only with the feature Label printing). | **Kind of step** (next to the title) changes the kind afterwards. Title, text and pictures are kept. Change the order by dragging **⠿**, see Move steps. ## Signature A signature step needs someone to scan their **badge**. Under **Who may sign?** you choose a qualification tag (e.g. _Final inspection_); otherwise anyone at the station may sign. **Require PIN** (only if the feature _PIN at signing_ is on under **System → Features**): the signer also gives their personal PIN. Badge plus PIN are two parts, which makes the signature harder to lend out. The one signed in at the station gives the PIN the first time per login; someone else who signs (e.g. Quality) gives it every time. The person chooses their own PIN (4–8 digits), under **Account → PIN at signing** or at the station the first time it is needed. The build record says _with PIN_. Note: the box applies only to the step you have open. If several operations have a step called _Signature_, first choose the right operation in the list on the left. The change is part of the instruction and applies from the next release. ## Label A label step prints a label in the middle of the flow, e.g. _Print the type plate_ in the last operation. It is there when the feature **Label printing** is on (System → Features). - **Which label?** Choose an approved template, or _The unit's label_ (the same template as when the unit starts). A chosen template that is replaced by a new revision follows on to the new one. - At the station the operator presses **Print the label**. The step is done only when the label has come out; if it did not come out, the step stays with **Try again**. - If the feature is turned off, the step is done without a label, so production does not stop. Templates and printers: see Printing your own labels. ## Move steps - **Change the order:** drag **⠿** on the left of the step and drop it where it should be. A blue line shows where it lands. - **To another operation** (e.g. if the steps were written on the wrong station): drag the step and drop it on the operation in the list on the left. The operations that can take the step get a dashed border while you drag. The steps are put **last** in that operation, with text, pictures and conditions. - **Several at once:** tick the box on the steps. Drag one of the chosen ones and all follow, or choose **Move to …** in the bar shown at the top. **Choose all** ticks every step in the operation. - After the move, **Go there →** takes you to the operation the steps went to. Steps can only be moved within the same level (the same flow), and only while the flow is open for changes. **Scan steps** are not moved this way: where a part is mounted is chosen in the flow. ## Text and pictures - **Instruction for the operator** has a toolbar: **B**, _I_, underline, text size (Normal, Large, Heading), bullet list and numbered list. The text is saved when you click outside. - **Scan steps** get text and pictures too: click the step. Which part is scanned is still decided by the structure, so kind and conditions are not shown there. ## Pictures in the instruction Each picture becomes a **row** in the instruction: the picture on the left, its own text on the right. - **Adding:** click **+ Add pictures** (several at once), **drop files** from the computer on the picture box, or click in the box and **paste** a screenshot with Ctrl+V. JPG, PNG or WebP, at most 10 MB each. New pictures go last. - **Text for the picture:** type in the box beside it. The toolbar (bold, lists, **{ } Article number**) shows while you type. The text is saved when you click outside. - **Order:** drag **⠿** and drop where the picture should be. A line shows where it lands. - **Large picture:** click the picture. Browse with **← →**, close with **Esc**. - **Remove:** **✕** and then **Remove?**. - **Always shown:** tick it under the text for a picture that matters. It is shown, with its text, even when the operator has chosen **Compact**. At the station all pictures are shown right in the step, as rows in the order they have here, with the text beside them. In **compact mode** – for those who know the job – only the step's heading and the pictures marked **Always shown** are shown; the instruction text and the other pictures are behind **Show the whole instruction**. So mark what must not be missed, not everything: too much is not read. ## Article numbers in the text An instruction can name **the article number in a position**, which differs depending on the article being built. Write the text once – it fits every variant. 1. Put the cursor where the number should be. 2. Choose the position in **{ } Article number** in the toolbar. The list shows the level itself first, then the positions below it. The text gets the position's name in braces, e.g. `{Motor}`. 3. Below the text you see what each name becomes: _{Motor} → M-25 / M-40_. Example in the Motor unit block: _Put the label of `{Motor}` on the motor unit. Then scan the label of `{Motor unit}`._ At the station this becomes _Put the label of **M-25** on the motor unit. Then scan the label of **PM-25**._ when PM-25 is built. - **The level's own name** (here `{Motor unit}`) gives the article being built. Positions further down the tree can be named too. - **–** is shown where the position is not in that article (_not in these articles_). - When a position is renamed in the structure, the texts follow in flows that are not released. A name that does not exist (misspelt, or changed after the release) is shown with a red **⚠** in the step list and in red at the station – choose the position again. - Preview shows the text with the numbers filled in for the article you choose. ## Measurement - **What is measured**, e.g. _Torque_. If the step still has the heading _New measurement_, this becomes the heading too. - **How:** _Read from a tool_, _Operator types the value_, _Pass / Fail_ or _Result from a test program_. With the add-on Integrations the test program can report the result itself, see Test results from a test program; otherwise the operator presses **Passed** or **Failed**. - **Min, Target, Max, Unit, Readings** (e.g. 13 screws = 13 readings). - **If it fails:** stop and call a team leader, or let the operator re-measure once. - _The operator sees_ shows the text as it will be at the station. ## Wait Give the time in hours and **May the operator continue early?**: _No_, _Yes, with a reason (logged)_ or _Yes, but only someone who may force (e.g. the production lead)_. The last one means the permission **Force a stop**, which Production lead, Quality and Admin have from the start. Forcing is always shown in the build record with the reason and who forced. ## Which articles does this step apply to? (conditions) The choice decides **for which articles** the step is shown in production – not which person does it. (Who may work is decided by the station and the person's permissions; who may sign is chosen on the signature step.) | Choice | The step is done for … | | --------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | **All articles** | every article of the level. | | **Articles with a property…** | e.g. _Size = 40_ (the property is inherited downwards). Choose the value in the list beside it; nothing is preselected. | | **Articles that contain a part…** | e.g. _contains 2330 Pressure sensor_ – looks down through the whole tree. | | **Chosen articles…** | the articles you tick. | Below the choice it says which articles the step applies to. Scan steps are only done for articles that have a part in the position. **A property on a sub-assembly:** the sub-assembly gets the value from the products it is used in. If a sub-assembly article is used in products with different values (e.g. one with _Size = 25_ and one with _Size = 40_) the value cannot be decided, and the step is **not** done for that article. **Ready for release** then warns, and **Preview** for the article says in yellow which products differ, e.g. _PX-200 (PX-1 = 25, PX-2 = 40)_. Usually a property is set wrong on a product; correct it under **Articles**. If it is right as it is: use **Articles that contain a part…** or **Chosen articles…** instead. ## When does the step apply? (revision and period) Below **Who does the step** is **When does the step apply?**. It is decided for **each unit** at the station, not for the article, and can be combined with the choice above. **Revision** – the unit's revision (from its label, otherwise the newest approved one when the unit was started): | Choice | The step is done for … | | ----------------- | ------------------------------------------------------------------ | | **All revisions** | all units. | | **From** | e.g. _B_: revision B and all later ones. A change in B stays in C. | | **Up to** | e.g. _A_: revision A and earlier – the old way. | | **From – up to** | e.g. _B–D_. | | **Only** | the revisions you type, e.g. _B, C_. | | **All except** | all but the ones you type. | The order is the article's own revision order. Revisions the article does not have are compared as text (1 < 2 < 10, A < Z < AA). **Period** – dates, both days included. **Only during the period** or **Not during the period**. Example: tool X is on service for a week. Add a step with tool Y that applies _only during the period_, and set the usual step to _not during the period_. After the period the usual step applies again by itself. The day that counts is when the work on the unit in the operation began (the site's time zone), so a unit does not change instruction half-way through. In the step list and the preview the condition is written out, e.g. _rev B and later_. The preview shows all variants, as revision and date are only known at the station. ## Preview **Preview** (top right) shows the operation as the operator sees it, for an article you choose in **Preview as**: only the steps for that article, numbered, with text, pictures, the expected article number and revision at scans, measurement limits and waiting times. Conditional steps have a yellow tag saying **why** they are there. At the bottom are the steps not done for the article. ## Viewer – the whole product **👁 Viewer – the whole product** at the top of the Instructions step shows every instruction in the structure for **one top article**, the way the operators get them. It is only for reading. - Choose the **Top article**. Everything built for it is shown in **build order**: the sub-assemblies first (deepest in the tree first), the top last. Each level shows the article number built for that very top. - Under each level come the operations in flow order, with the steps that apply to the article, what is scanned and the article numbers in the text filled in. - **Contents** on the left shows levels and operations with the number of steps. Click to jump there. - **Print** prints without the contents list. - **Per operation** takes you back to editing. # Release and revisions ## Ready for release The step **Release** lists everything left in **all levels** with drafts, checked in the database: - **Red** items block the release, e.g. _no part chosen_, _not mounted anywhere_, _no station_, _min is above max_, _no approved revision_. - **Yellow** ones are warnings, e.g. _no instruction text_, _decide if the operator may continue early_, _no tested label_. - **Fix →** takes you to the right step and place. The row of steps at the top also shows the count per step. ## Release the whole tree The button **Release all N levels** (or **Release …** when only one level has changed) releases every level with a draft **in one sweep, bottom up**. First a box shows what will be released (level, instruction and which articles it applies to), and the release happens when you click **Yes, release**. **Cancel** releases nothing. Only someone with the permission to release (e.g. Quality) sees the button; others see an explanation. When a level already has a released revision, **Old revisions** is shown below the list: whether a unit of a revision built today gets the same instruction after the release (_Unchanged for product revision 02_) or what changes. See Unchanged for the old revisions. If the draft changes nothing at all for what is built today, a yellow box above the button says so, so that no new revision is released for nothing. It does not stop the release. ## A new article after the release Adding is not changing. An article added to a released product (e.g. a right-hand variant PX-2 of the pump) needs **no new revision**, as long as it is built with the same positions, flow and instruction: 1. Add the article in the **Articles** step. It is marked **New – not released**. 2. Choose its parts in the **Structure** step. Only the column of the new article is open; the released articles are locked (🔒). 3. Click **Release new articles** in the **Release** step. It requires the permission to release, and who released it and when is saved in the change log. The instruction revision keeps its number (e.g. /4), and the articles that were already released are not affected. The new article cannot be started in production until it is released. **In a sub-assembly** (e.g. Main board) it is not enough to add the article there. A sub-assembly is built for what the level above chooses, so the new article must also be chosen in the structure where it goes (a new revision of that level, usually as a change). Until then it is a red point in the **Release** step: _not used in any product yet_. If you want to change something that is already released – a part in a released article, a new position, the flow or the instruction – a new revision is needed. ## A new revision of an article A new revision is made as a **change**: click the part in the matrix and choose **New revision of …**. NoGaps shows where it is used all the way up, makes drafts and approvals in every level at once, and everything is released together by Quality. See Changes – a new revision. **Until it is released it cannot be built.** A label with the new revision is stopped at the station (_Rev 03 is not released in Design yet_), and units without a revision on the label are started as the latest released one. So no new revision reaches the assemblers without someone going through the instruction. Units already being built carry on with their revision. A new revision of a part you buy (a component that is scanned in) stops until Quality has assessed it and it is approved in the product. In a change both happen when the change is released. ## Revisions - **Product revision**: the article's revision in the register (e.g. 03). It is shown at the station and in the build record. - **Instruction revision** (/1, /2 …): a running number per level that never starts over. - **Change (new revision)** in the structure and **Change the flow (new revision)** in the flow both give the next instruction revision, e.g. /5. The structure gives a copy of everything; the flow only of the flow. - If you have a flow draft and start a new revision of the structure, the draft comes along, with its changes kept. - One draft at a time per level. When something is released, the previously released revision expires. - Units already being built continue after the revision they were started with. New units get the new one. ## Look at what is released, or delete the draft When there is a draft, the revision pill at the top right (**Instruction /5 · Draft ▾**) is a menu: - **Show: The draft / The released one** switches between what you are working on and what production builds after right now. The released one is shown read-only. Everything is locked there. - **Delete the draft** (click twice) throws away the draft of that level, both structure and flow, and you are back at what is released. A sub-assembly made in the draft (**+ Make sub-assembly**) that is not used anywhere else goes with it. It cannot be undone. A first draft that was never released is not deleted here – delete the product instead. ## What applies at once, and what follows the revision? | Detail | When does a change apply? | | ---------------------------------------------------- | ------------------------------------------------------------------------------------- | | **Name, customer, description, type** (step Product) | **At once**, without a release – also for what is already released. In the audit log. | | **Built** (to order or to stock) | Follows the revision: changed in a draft, applies when the draft is **released**. | | **Structure, flow and instructions** | Follow the revision: apply when the draft is **released**. | - Name, customer, description and type are details about the product, not about how it is built. That is why they are not part of the revision. Who changed them and when is in **System → Audit log**. - **Built** is locked (dashed frame) when the revision is released. Click **Change (new revision)** below the field, choose and release. At the release the change is in the confirmation: _Built: To order → To stock_. ## Delete a product At the bottom of step **Product** there is the row **Delete product** (for a sub-assembly: **Delete the sub-assembly**). Click the row to fold it out, read what happens and then click the button twice. - The product is removed with its structure, flow and instructions, and sub-assemblies that nothing else uses. The articles stay in the register. It cannot be undone. - **If the instruction is released** the box says so: deleting it removes it from production at once, and the articles can no longer be started at the stations. - **If units have been built** it is not possible – they are history. Phase out the articles in the register instead. - **A sub-assembly used in a product** cannot be deleted. Open the product, remove the sub-assembly from its structure (in a new revision if it is released) and release. Then it works. # The article register and approved revisions **Design → Article register** holds every article: tops, sub-assemblies, bought parts, software and consumables. ## Approved revision on two levels 1. **In the register (level 1):** each revision of an article has a status: **Approved**, **Use up** (until a date), **Blocked** or **Not assessed**. Blocked always stops. 2. **In the product (level 2):** in the structure a revision can be approved, used up or blocked _for that product_. When a part is chosen in the matrix, its latest approved revision is filled in automatically. A not assessed revision never becomes approved by itself. At scanning both are checked: a wrong revision is stopped with the reason (_blocked_, _not approved in this product_, _not assessed yet – ask Quality_). ## Who may change Changing the **status** of a revision requires the permission for revision status (Quality). A process engineer can create articles and revisions, but new revisions are then _not assessed_ until Quality approves them. A new revision of an article you **build** cannot be built just because it is approved here. It must also be released in Design, see A new revision of an article. ## Serial numbers and lots Per article you set whether the serial must be unique per article, per organization or per supplier article. Parts without serial numbers can have a **lot**, registered the first time it is scanned. # Changes – a new revision A **change** gathers a new revision of a part and of what it sits in, all the way up. Everything in the change is released at once by Quality, and nothing changes in production before that. Example: the circuit board 3001-12 goes from A to B. Main board 3101-12 then goes from 02 to 03, the base units from 2.1 to 3 and the tops from C to D. ## New revision 1. Go to **Design**, open a product and click the part in the matrix (the **Structure** step). 2. Click **New revision of …** in the box that opens. 3. Write a **change number** and **what changes, and why**, if you like. 4. **The chain upwards** shows where the part is used, all the way up, with the revision in production and a suggestion for the next. Write what PLM says. - **Untick** an article that does not get a new revision. It keeps its revision, and the new part is approved in it anyway. - What is not affected (e.g. 10-inch variants when it is the 12-inch board that changes) says _not affected_. 5. Click **Create change**. You come to the change. Behind the scenes a draft is made in every level that is built here, and in each parent the new part is approved: a 03 requires board B, while a 02 carries on with board A. The new revision cannot be built until the change is released. If the position already has an exception from an earlier change (e.g. _from 03_), it ends with the old revision: the card shows _now holds for only rev 03_, and 04 gets a row of its own. That way two exceptions never hold for the same revision. ## The change The change has a card per level, bottom-up. Each card shows **what differs**: parts that are replaced and steps that are new, changed or taken away. The list is worked out from the draft, so nobody has to describe the change by hand. - **Open and change** takes you to the level's instruction, with the draft chosen. See The instruction in a change. - When a level is done, tick **Gone through**. - When every level is gone through, click **Send to Quality for release**. - **Cancel the change** throws away the drafts and the new revisions. If Quality has sent the change back, the comment is at the top. Fix it, tick again and **Send to Quality again**. ## The instruction in a change At the top of Flow and Instruction it says that you are working in the change, and which revision it is about. What you do applies to the new revision, and the old ones are not affected: - **New step** gets the condition _from_ the new revision by itself. - **Change a step:** you choose **Only for 03** (the default) or **For all revisions**. _Only for 03_ splits the step in two: what you write applies to _the new revision in the change and later_, and the old revisions keep what is released, unchanged. It is decided per article: if one article goes 04→05 and another 03→04 in the same change, your new step applies from 05 and from 04 respectively, and an article that is not in the change keeps the old one. _For all revisions_ is for e.g. a typo, and Quality sees it as a change for 02 too. - **Delete a step** makes it apply _up to 02_ instead of disappearing. The conditions are the same as in When does the step apply?. ## Where the changes are - **Design → Changes** lists the changes: _Waiting for me_ (for whoever may release), _Open_ and _Released_. - On the **start page** whoever may release sees a card when a change is waiting. - In a product with a draft that belongs to a change, the **Release** step says so, with **Open the change**. The level is released in the change, never on its own. ## Releasing a change (Quality) Open the change and go through the cards. On the right is **Release the change**: 1. **Assess the bought part**: tick that the new revision is approved. 2. **The old revisions**: choose for each _Finished as they are_, _Used up_ (until a date) or _Blocked_. The number of units in progress is shown beside it. 3. Click **Release the change**. All levels are released bottom-up, and who released it and when is saved. New units are then built as the new revisions, and the stations require the new parts. Units in progress are finished with their old revisions. If something looks wrong, click **Send back…** and write what needs fixing. ## Unchanged for the old revisions Under each level is **Old revisions**: for every revision built today, NoGaps compares what a unit of it gets after the release with what it gets now. - **✓ Unchanged for product revision 02**: the same steps, texts, pictures, order and parts. The instruction is frozen for 02 without a copy, e.g. when the customer has approved it in a PPAP. - **! Changes for product revision 02**: the list says what differs, e.g. _Changed: Solder_ (changed for all revisions), _New step_, _Removed_, another part or a part revision that is now approved as well. The article numbers beside it show which articles the answer is for. The same check is in the **Release the change** box beside each old revision (_Instruction unchanged_ or _Instruction changes_), and in the **Release** step of a product with an ordinary draft. If something changes for an old revision that should not: open the level and choose **Only for 03** on the step instead (see The instruction in a change). ## Cleaning up after blocked revisions When old revisions are **blocked**, steps and exceptions that only held for them are often left. Then a line is shown at the top of the **Instructions** step for the level: _Left over from blocked revisions: N_. **Show** lists them: - **Remove the step**: the step's condition only holds for blocked revisions (e.g. _up to 02_ when 02 is blocked). - **The condition goes**: a _from 03_ that holds for every revision in use anyway, so the step applies to all. - **Remove the exception**: an exception in the structure that only held for blocked revisions. - **The exception becomes the usual part**: the usual part was only used by blocked revisions, so the exception takes its place. Click **Clean up in the draft** (or **New revision and clean up** when the level is released). It is done in a draft and goes through **Ready for release** and **Release** as usual. Units in progress keep their old revision. Approved, used-up and not yet assessed revisions count as in use. An article without revisions ignores revision conditions, so then no steps are removed. When the level belongs to an open change, it is cleaned up when the change is released. # Labels – how they are read When the operator scans a label, the system must understand which part is the **article number**, **revision**, **serial number** or **lot**. Labels look different at different suppliers and customers, so you tell the system how they look. AI can help with the proposal, but at scanning only fixed rules run – fast, the same every time and without AI. ## Three layers 1. **Standards are recognised automatically:** GS1 (e.g. `(01)…(10)…(17)…`) and ISO/IEC 15434 (`[)>…`). No setup needed. 2. **Label formats** you set up: parts with a separator (`|`, `$`, `+`, `;` …), prefix + value, pattern, several codes on one label, or _free text_ (the code is kept as it is, see below). 3. **The built-in form** `ARTICLE|REVISION|SERIAL` (also `ARTICLE|SERIAL|REVISION`) and `ARTICLE|REVISION|LOT:batch`. It is read without any setup – so a label in that form can be scanned even if you have made no format for it. ## What a format applies to | Applies to | Example | Set | | ----------------------------- | ------------------------------------- | -------------------------------------- | | **Articles** (one or more) | the same supplier label on two motors | in the structure, cell editor step 3 | | **A product or sub-assembly** | all its articles have your own label | in the structure or in System → Labels | | **The whole organization** | the company's standard format | System → Labels | The most specific wins. An article always has the same format, but different articles can differ – e.g. the customer's own label on parts sold separately and yours on parts for internal assembly. ## A code without an article number (free text) Many parts have a code without the article number, or one nobody knows the exact meaning of – e.g. a supplier serial like `7P35V368U009`, or `92 008JZ` on a flex cable. Then choose **Free text – keep the code as it is** under _How code 1 is read_ (System → Labels): 1. **Expected form** stops other codes. If the part has two barcodes and the lower one is the one to scan, write a form only it fits, e.g. `^7P[0-9A-Z]+$` (starts with 7P, then digits and capital letters). Leave the form empty and any code is accepted. Write **the code's form, not the code**: only what is the same on every part is fixed (e.g. `7P`), the rest is given as kinds of characters and length – the next part has another number. The proposal from the picture and the AI do the same and fix at most the first four characters. 2. **Revision:** _Operator picks from approved_ or _Not revision controlled_ – the code has no revision. 3. **Applies to:** preferably the article or the product, so the form is only tried there. 4. The test bench shows **from the step** under Article. That means OK: the article is taken from the step where the code is scanned. Add the other code on the part as an example too – it should turn red (_does not have the expected form_). The whole code is saved in the build record: as the **serial** (the part's identity – the same serial is accepted only once) or, with **Save as**, as the **lot**, model number or supplier part no. A lot may be scanned on many parts. It works in steps that wait for a specific article; to start a unit (_Scan unit_) the label must contain the article. ## Talking to the AI The AI only sees the picture and the examples. What you know about the part – which of the codes is to be scanned, what a part means, that nobody knows what the code stands for – you write in the box **Tell the AI** and press **Send to AI** (Enter sends, Shift+Enter makes a new line). - The AI answers with a new proposal and an explanation, and the structure and the test bench are updated at once. If it is not right: write again. The AI remembers what you wrote earlier about the label. - You can write before you press **Analyse with AI**; the comment then goes with the first analysis. A picture or at least one example is needed. - Example: _"The lower code (7P…) is the one to scan, not the upper one. We don't know what it means – keep it as it is."_ - **Start over** clears the conversation. The conversation is not saved, but the latest explanation is saved with the format. - Every message is one AI call and shows in the AI budget under System. The box is in System → Labels and in the structure (next to **Ask AI**). ## The reader never guesses Every approved format is tried, but only **plausible** readings count: the article exists, the format applies to it, and a revision on the label is one of the article's. If the label can still be read in two ways it is stopped with _The label can be read in two ways_ and listed in System → Labels. **A draft is not read.** If an article or a product has a format that is a _draft_ and the label matches it, the label is stopped with _The label matches the format … which is not approved yet_ – even if the built-in form could have read it. Approve the format, or remove it, and the label is read again. (A draft for the whole company stops nothing.) ## Setting up in the structure This is the usual place to set up labels: here the system already knows which article it is. 1. **Structure → Show labels.** The dots: green = tested, grey = no format, red = an example is read wrongly (or a code that must be stopped is accepted). 2. Click a cell (e.g. the _Motor_ row, **All**). Step 3 **The label on the part** shows the article's formats and how the code is read (e.g. _Article % Serial_ or _Free text → Lot_). **Change** opens the format; **Remove** (click twice) removes it – if the format applies to more articles, only the chosen ones are taken out of it. 3. **📷 Set up the label** opens the same editor as System → Labels: picture, AI, structure and test bench. Start with the picture, see below. If the article already has a format the button says **One more format** – but usually you want to **Change** the existing one; all formats are tried when scanning. 4. **Approve format** when every example in the test bench is green. Quick check: scan or paste a code and press **Read** (or the camera button). If it is read right it says _Read as …_. If it cannot be read: **Set up the label with this example**, or choose another format the label looks like (only formats the code has the same shape as are suggested). If the label fits a format that is a draft, **Open the draft … and approve it →** is shown instead. If a label is already read right but the dot is grey: **Save as tested example**. **The column heading** (the top article) opens **The label on the unit** – the label that starts the unit at the station. Everything the label says, also model number and the supplier's number, is saved with the mounted part in the build record. ## Picture – tap the code to scan 1. **Take photo** (phone/tablet) or **Upload picture** of the part, so the barcodes show. 2. Every barcode on the picture is found and framed. **Tap the one to scan** – on the picture or in the list beside it. 3. Three things happen: the code becomes an example _to be read_, the other codes become examples _to be stopped_ (⛔ in the test bench), and a first structure is proposed (free text with a form only that code fits). If AI is set up, the AI proposes the structure at once – tell it in the box if something should change, e.g. _it is a batch number_. 4. In the test bench every row should be green: the right code _OK_, the others _Stopped_. If it says _Read – but should be stopped_ the form is too wide. The picture and the mark are saved with the format. **At the station** the picture is shown with the code marked if the operator scans a wrong code at a step waiting for the article. If no code is found: take a sharper picture closer. You can always scan the codes in the test bench instead; choose **⛔ To be stopped** (instead of **✓ To be read**) for a code that must not be accepted. ## System → Labels - **The company's standard formats** – apply to every article without a format of its own. Take a photo or upload a picture, **Analyse with AI**, adjust the structure and test in the **test bench** (all examples must be green before approving). **Save draft** saves also when examples are read wrongly, but a draft is not used in production; saving an approved format as a draft takes it out of use until it is approved again. - **For a product or article** – the formats set in the structure, in one place. Each row shows the article (or product), the format's name, how the code is read and when it was changed. If an article has several formats it says so in orange, e.g. _3 formats for the same article_. - **Stopped as unknown label** – labels from production that could not be read (also from _Scan unit_). The list only shows those that still cannot be read. - **Test labels to print** – real barcodes for demos and tests. Of the badges, only your own and an unknown badge that must stop are shown, since a badge signs in and signs in someone's name. Another person's badge is printed under **System → People and terminals** → the person → **Print the badge →**. Example step by step: Example – setting up a label. ## Printing your own labels The feature **Label printing** (System → Features) prints labels from your own templates. It has four parts under **System → Label printing**, and a page of its own, **Labels**, in the menu: | Part | What | | ------------------------------------------ | ---------------------------------------------------------------- | | **Templates** | The company's labels. As many as needed, each with its own name. | | **Label stocks** | The labels loaded in the printers, e.g. _50 × 25 mm_. | | **Unit label** | Which template is printed when a unit starts. | | **Printers** | The printers per site, and which ones stand at which station. | | **Labels** (the menu) | Printing a batch beforehand, a label again or an example. | **A new template:** 1. **+ Template** shows ready-made layouts: _Serial number with barcode_, _Serial number with QR code_, _Small with DataMatrix_, _Nameplate_ and _Carton label_. First choose the **Label stock** (or leave _New stock in the size of the layout_) and then the layout most like your label. It becomes a draft named after the layout. 2. Under **Content** you choose the **Code** (barcode, QR code, DataMatrix or none), what the code holds, whether the code is to the left of the text or below it, and the **Text rows**. Click in a row and put in fields with the buttons under it: _Serial number_, _Article number_, _Article name_, _Revision_, _Customer_ and _Date_. The fields are written as `{serial}`, `{article}` and so on, and are filled in when the label is printed. Your own text, e.g. _S/N_, is typed as it is. **Frame around the label** draws a frame. 3. The **Label stock** decides the size. When you change stock the label is laid out again so that the code and the text fit. You do not give a resolution: the template is written for the resolution of each printer. 4. **Preview** shows the label with example values. **Show the ZPL code sent to the printer** shows the code the app has written. **Print an example …** tries the template in a printer, see Print an example. 5. **Approve**. An approved template is locked. **Several templates and revisions.** Each template has its own history. **Change (new draft)** makes a copy that replaces the approved revision of _that template_ when it is approved (r2, r3 …). Other templates are not affected. The prints remember which revision they were made with. The company's first template becomes the unit label for the whole company by itself; the next template is not chosen for anything until you choose it under Unit label, in a label step or by hand under Labels. **Take out of use** (click twice) removes an approved template from the choices without replacing it. If the template is chosen as a unit label you get _The template is chosen as a unit label. Choose another template there first._ **Show replaced and out of use** shows the old revisions and the templates out of use; **Change (new draft)** on a template out of use brings it back when the draft is approved. **Change layout** on a draft opens the choice again. What is on the label is replaced, the label stock is kept. **Paste ZPL (advanced)** is for a label already made in e.g. Zebra Designer or BarTender. Paste the code and put in the fields where the values go. Also give the **Resolution**: pasted ZPL is written for one resolution and only goes to printers with the same dpi. The preview draws the most common ZPL commands (text, text boxes, boxes, pictures, Code 128, QR and DataMatrix); the printer gets the whole code. ## The label designer The feature **Label designer** (System → Features, requires Label printing) lets you draw the label freely. Without it you make labels with the ready-made layouts or with pasted ZPL. - **Open:** **+ Template → Draw freely** starts with an empty label. **Open in the designer** on a draft from a ready-made layout continues with what is already there. When you change something in the designer the label becomes freely drawn, and the form is no longer used for it. - **Add:** **+ Text**, **+ Field** (a text holding a field, e.g. Serial number), **+ Barcode**, **+ QR code**, **+ DataMatrix**, **+ Picture**, **+ Line** and **+ Frame**. The new element lands below what is already there, when it fits. - **Move and resize:** drag what you want to move. Drag the small square at the lower right to change the size. The arrow keys move the selected element one step (Shift = ten steps). **Delete** removes, **Ctrl+Z** undoes, **Ctrl+Y** redoes and **Ctrl+D** makes a copy. - **The panel on the right** shows the settings of the selected element: the text or what the code holds, the size, and the position in millimetres from the left and from the top. **Centre horizontally** puts it in the middle of the label. Below it everything on the label is listed; click in the list to select something lying under something else. - **Grid (1 mm)** makes what you drag snap to half millimetres. Without the grid it moves in tenths. **Example values** shows the fields filled in; without it the field names are shown. - **To look at** warns when something goes outside the label, when a code cannot be drawn with its value, when a text does not fit its text box and when a field stands in a text that cannot fill it in. The element gets a dashed red frame. - **Saved by itself.** _✓ Saved_ is shown at the upper right. The name is changed at the top; the size is that of the label stock. **← Label printing** goes back to the template, where you approve it. An approved template is locked in the designer too: go back and choose **Change (new draft)**. When Label designer is turned off the drawn templates print as usual and can be looked at, but not changed. ### Text: font, width, text box and rotation Select a text to see its settings in the panel. - **Font.** **The printer's font** is the only one that can show fields (serial number, article number …), since the printer fills them in. Under **More fonts** there are Inter, Roboto Condensed, Source Serif and JetBrains Mono, and with **Upload a font …** you add the company's own (TTF, OTF, WOFF or WOFF2, at most 2.5 MB). A text in such a font is sent to the printer as a picture. It suits fixed text such as the company name or _Made in Sweden_, and can be **Bold**. If you put a field in such a text, _To look at_ warns. You are responsible for having the right to use an uploaded font. - **Letter width (%)** makes the letters narrower (below 100) or wider. - **Text box, width (mm).** Without a value the text is one row, as long as it gets. With a width the text is broken into rows inside the box, up to **Rows (at most)**, and **Alignment** puts it to the left, centred or to the right. Use a text box for fields whose length varies, e.g. the description. If the text does not fit, _To look at_ warns. The row breaks in the preview are approximate for the printer's font: try with the longest text that can occur. - **White text on black** puts the text in a black box. It needs a text box, and gets one by itself if none is set. - **Rotation** turns the text 90° clockwise, upside down or 90° anticlockwise. Barcodes and pictures can be turned the same way. ### Pictures **+ Picture** adds a logo or a symbol (PNG, JPEG or SVG, e.g. the CE mark). Drag the corner to resize; the proportions are kept. **Replace picture** changes the file but keeps the place and the width. The printer only has black and white, so the picture is turned into dots, and the designer shows the dots as they are printed: - **Darkness** decides how dark a point must be to become black. Drag to the right if thin lines disappear, to the left if the picture fills in. - **Dots (for photos and greys)** turns greys into a pattern of dots. Leave it off for logos and symbols, which are sharpest without. - **Inverted** swaps black and white. The picture is worked out again for every printer resolution, so the same template suits 203 and 300 dpi. Always check a real print (**Print an example …**): darkness and sharpness depend on the printer and the label material. Pictures and uploaded fonts are kept in the company and are part of the export. ## Label stocks A **label stock** is the label loaded in a printer: a name, **width** and **height** in millimetres and a note (e.g. material or order number). The stocks are under **System → Label printing → Label stocks**. - A **template** is made for a stock, and a **printer** has a stock loaded. That way every label goes to a printer where it fits, also when a station has several printers. - The first stock is created with your first template (_50 × 25 mm_ from the layout). **+ Stock** adds more. - The size cannot be changed while a template uses the stock. Add a new stock and change stock in a new draft of the template. - **Remove the stock** only works when no template or printer uses it. ## Unit label Under **System → Label printing → Unit label** you choose which template is printed when a unit starts. Choose **Applies to** (the whole company, a product or sub-assembly, or an article) and **Template**, and click **+ Add**. - The most specific choice wins: the article before the product, the product before the whole company. Example: _The whole company → Serial number_, _Article 1103 → Nameplate_. Then 1103 gets the nameplate and everything else the serial number label. - The template is changed in the list on the row. **✕** removes the choice. If no choice applies to an article, no label is printed when it starts. - The choice follows the template, not the revision: when a new revision is approved it is used at once. - **Other labels** on the same unit, e.g. a carton label in the last operation, are added as label steps in the flow, where you choose the template. In the template list _Unit label: …_ is shown on the templates that are chosen. ## Printers Printers are set up per site under **System → Label printing → Printers**: - **Preview**: no real printer. The station shows the label on the screen and the operator presses **Done** (for test and demo). - **Zebra Browser Print**: Zebra's program on the station's computer sends the label to a Zebra printer (USB or network). A network printer with a fixed IP address is first added in Browser Print on the computer. Leave the name empty for Browser Print's default printer, or type the printer's name. **Find Zebra printers on this computer** shows what Browser Print sees. On nogaps.se, Browser Print's certificate has to be accepted once in the browser. - **Agent (network printer)**: an agent in the factory sends the label to a printer in your network. The station needs no computer of its own with a printer, so it also works from a tablet. Choose the **agent**, type the printer's **address** in the factory network (e.g. _192.168.1.50_) and the **port** (usually 9100). For each printer you give the **Resolution (dpi)** (on the printer's nameplate: 203, 300 or 600) and the **Label stock in the printer**. _Any stock_ means the printer takes any template. When you change the label roll in the printer: change the stock here too. **Printers per station.** Below the printers the site's stations are listed with a checkbox per printer. A station can have several, e.g. one for small serial number labels and one for carton labels. Nothing ticked means the station uses the site's printers. The label goes to the printer with the right label stock (and, for pasted ZPL, the right resolution). If there is none you get _No printer here has the right label stock for that template_. At the station you see whether the label came out, and an error (e.g. paper out) can be tried again. **Print the label again …** needs the permission to print again and a reason, which is kept in the build record. ## Printing through an agent An agent is a small program on a computer in the factory that sends the labels to network printers. The agents are added and installed under **System → Agents**, see Agents in the factory. The printer is set up under Printers with the kind **Agent (network printer)**. **At the station** it says _Sending the label to …_ while the agent works, and then that the label is printed. This can happen: | Message | What it means | | --------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | _The agent … is not answering right now_ | The agent has not been heard from for half a minute. The label waits for at most a minute and then becomes an error with **Try again**. It is never printed long afterwards. | | _The printer is out of labels_, _The printer's head is open_, _The printer is out of ribbon_, _The printer is paused_ | The printer has told the agent, and no label was sent. Fix it and click **Try again**. | | _The agent cannot reach the printer_ | The printer is off, unplugged or has another address. | | _The agent is not allowed to connect to that address_ | The address is not in the agent's own list. Your IT adds it in _config.json_ on the agent's computer. | | _It is unclear whether the label came out_ | The agent took the label but never answered (e.g. a power cut). Look in the printer and answer **Yes, it came out** or **No, print it again**. The label is never printed again by itself, so that there are never two with the same serial number. | _Printed_ means the printer has taken the label. The agent asks a Zebra printer about paper, head and ribbon before it sends, but cannot see the label itself. ## Print an example **Print an example** prints a template with example values (_26-12345_, _C000123-50_ …), to see that the template, the label stock and the printer go together. No serial number is taken and nothing is kept in any build record. It also works on a draft, before the template is approved. 1. **System → Label printing**: choose the template and click **Print an example …**. Or **Labels** in the menu, at the bottom, and choose an approved template. 2. Choose the **Printer**. _Show on screen_ shows the label instead of printing it. A printer with another stock or resolution can be chosen, but is marked. 3. Click **Print an example**. You get _The example is sent to …_, or why it did not work (e.g. that Browser Print does not answer). With a printer of the kind Agent it first says _Sending the label to …_ while the agent fetches the example. The warning _The printer has another label stock than the template is made for_ means the example is printed anyway, but may end up wrong on the label. ## Labels in the menu **Labels** in the menu is for printing away from the stations, e.g. in the office or the warehouse. The page is shown when the feature Label printing is on and you may print a batch, print again or change templates. It has: - **Batch beforehand**: reserve serial numbers and print the labels before the build. - **Print again**: a new label for a unit that already exists. - **Print an example**: try an approved template in a printer. Templates, label stocks and printers are set up under **System → Label printing**. ## Batch beforehand Sometimes the labels are needed before the units are built, e.g. 50 serial numbers for a PCB panel. Under **Labels → Batch beforehand** (requires the permission to print a batch): 1. Choose **Site** (if you have several), **Article** and **Count** (1–500). **Template** is set to _The unit label of the article_; choose another approved template if the batch should have another label. **Printer** is set to _Choose for me_, which takes a printer with the right label stock. 2. Click **Reserve … and print**. The serial numbers are reserved for the article and printed as one job. With _Preview_ the first label is shown; click **Done, the labels are printed**. 3. At the station the operator scans the label under **Scan unit**. The unit starts with that number, no new label is printed, and the build record says _Label printed beforehand (batch)_. 4. **Latest batches** shows how many are used and left. **Show serial numbers** lists them. **Void unused** (e.g. when the labels were thrown away): a voided label is stopped if it is scanned. A reserved number belongs to its article and is used once. Ordinary serial numbers never take a reserved one. ## Print again A label that was damaged or lost can be printed again without going to the station. Under **Labels → Print again** (requires the permission to print again): 1. Scan or type the unit's **serial number** and click **Find**. The unit is shown with its article and name. 2. Under **Which label?** are the labels the unit has got, with when they were printed and how many times they were printed again. Choose one. If the unit never got a label you can print its unit label. 3. Type a **Reason**, e.g. _smeared_, choose the **Printer** (or _Choose for me_) and click **Print again**. With _Preview_: click **Done, the label is printed**. The label is printed with the unit's own values and with the same template and revision the unit got. The reason and your name are in the build record as _Label printed again_. Only started units are found: a reserved number that has not been used is under **Latest batches**. # Example – setting up a label ## The supplier's label on a bought part A motor from the supplier has a label with the code `[G1]95.07A01.001+M71B4-0550+264100084+XA`. 1. Open the product → **Structure** → **Show labels**. 2. Click a cell in the row **Motor** and choose **All** (both motor articles, if they have the same kind of label). 3. Scan the label in step 3 and press **Read**. It cannot be read yet, so the suggestion shows the separator `+` and four parts. 4. Choose what the parts are: | Part | Choose | | ------------------ | -------------------- | | `[G1]95.07A01.001` | Supplier part no. | | `M71B4-0550` | Model number | | `264100084` | Serial | | `XA` | Revision (or Ignore) | If it says _Not an article number in the register_ under a part you called Article, it is probably the supplier's number. 5. **Revision:** _read from a code_ if the label has the revision, otherwise _the operator picks_ (among the approved) or _none_. 6. The test line should turn green (_Read as …_). **Save format.** The dot turns green. 7. Scan a label from the other motor article and click **Save as tested example** – then both are green. ## Your own label on the unit The label says `C000123-51$A$123123` (article, revision, serial). 1. **Structure → Show labels** and click the **column header** (or an article of a sub-assembly). 2. Scan the label in **The label on the unit** and press **Read**. The suggestion finds `$` and which part is the article and the revision. 3. **Save as:** for that article only, or _for the whole sub-assembly or product (all its articles)_ if they all have the same kind of label. 4. At the station: scan the label in **Scan unit** where the flow begins – the unit is started with the serial and the right instruction. See The station. ## The company's standard format If all your labels have the same form: **System → Labels → + New standard format**. Take a photo, **Analyse with AI**, add a couple of examples in the test bench and **Approve the format**. # The station The station view is made for tablets and phones. The tablet is signed in once as a **terminal** (a shared login set up under System); the operator scans their **badge**, and everything is saved in the operator's name. ## Getting started 1. **Production** → choose the **station** (_Which station is this?_). The list shows the stations at the site chosen at the top of the page; a terminal always shows its own site, and if it is locked to a station it skips the choice. 2. **Scan badge**. If you are signed in with your own login you can press _Sign in as me_ instead; a terminal always requires a badge. 3. Change station with **Change station**. **Sign out** signs out the operator (not the tablet). On a phone, **Compact**, **Change station** and **Sign out** are under **⋯** in the station row. 4. If you change site at the top of the page you leave the station, since it belongs to the old site. The station asks again, or goes to the new site's first station if it follows the unit. ## Starting a unit Three ways: - **Start a new unit:** the list shows articles whose flow begins here. Choose the article, scan or type the serial number (empty = a number is created) and press **Start**. - **From the label:** scan the unit's label (article + serial number) in **Scan unit**. The unit is started with that serial and gets the instruction for the article (_Started from the label_). It works where the article's flow begins; otherwise it says where it is started. If the company requires the right revision on the label (System → Production), the revision must be on the label too. - **Continue:** scan the serial of a unit already started. ## Working - Operations and steps are shown in order. Steps you cannot do yet are held, with the reason (_Finish the previous step first_, _The operations before this one are not finished_). - Each step has its instruction, pictures as rows with their text beside them (click for a large picture) and what to do: scan, confirm, measure, wait or sign. See Steps at the station. The green bar at the top of the step shows how far the operation has come. - If the step went well, a short green confirmation is shown at the top and disappears by itself after a couple of seconds, and the next step flashes green. If something went wrong, a red box is shown and stays until you scan again. - When a new step or new buttons come up, they take taps only after a brief moment. That way a double tap on **Done** does not also register **Passed**, which comes up in the same place. Scanning works straight away as usual. - **On a phone** the station is in **work mode** while an operator is signed in: the app's top menu is hidden, the station and operator are on one line, and what to do (the scan field or the button) stays at the bottom of the screen while you read the instruction. Bring back the top menu with **⋯ → Show main menu**. - **Compact** is for those who know the job: only the step's heading and the pictures marked **Always shown** in Design (with their text) are shown. **Show the whole instruction** shows the rest of the step, **Show short** hides it again. Critical text and what to do are always shown. - When the unit is done at the station, the scan field **Scan next unit** is ready: scan the next label or serial number at once, without pressing a button first. - When all steps are done the unit is **released**. A sub-assembly built to stock can then be scanned into the level above. - **I need help** calls for help, see Calls. On a phone it is the small yellow **Help** button in the station row. ## The station follows the unit If the company has turned on **The station follows the unit** (System → Production), no station has to be chosen. The tablet starts at the site's first station where new units can be started, and the station and **Follows the unit** are shown at the top. - To start somewhere else: **Change station** and choose. You stay signed in, and the stations where new units can be started are marked. The station follows the unit again at the next scan. - Scan a unit or label: if the unit has nothing to do here, you are taken to the station where it is next, with the same sign-in (no need to scan the badge again). A blue line says _You are now at S3 · Final assembly_. - A new label whose flow begins at another station takes you there and starts the unit there. - When the unit is done at the station you stay; it is the next scan that moves you. - A terminal locked to a station does not follow. ## No contact with the server The station asks the server at every scan: it is the server that says right or wrong. If the network is gone for a while, a yellow box is shown at the top, **No contact with the server**. - **Wait and do not scan.** The scan field and the buttons are held meanwhile, so that nothing is scanned into thin air. The unit, the step and your sign-in stay on the screen. - **The station notices by itself when the contact is back** (it asks every few seconds) and then reads the unit's state from the server. You do not need to reload the page. - **If you reload the page anyway** (or start the computer) while the network is gone, NoGaps still starts and shows a card, **No contact with the server**. Wait: when the contact is back the station opens by itself, with your sign-in and the unit still there. - **What you did just as the contact was lost is taken care of:** - If the scan or **Done** had not arrived, it is sent again by itself, and you get the usual green or red answer. - If it had arrived, _The last thing you did had been saved_ is shown, with the next step. Nothing is saved twice. - If it is something that cannot be repeated by itself (starting a unit, signing, a wait, a printout), _The last thing you did may have been lost_ is shown: look at what the station shows and do it again if needed. - If the contact does not come back: check the network (wifi, cable) and tell whoever is responsible for it. Nothing that is already saved is lost. The app starts without a network, but the station cannot work without it: starting, scanning, signing and printing need contact with the server. ## The camera The camera button next to the scan fields reads barcodes and DataMatrix with the phone's or tablet's camera – only the code inside the frame, two reads in a row to be sure. ## Test labels For demos without a handheld scanner: **Test labels** under the scan step gives clickable labels – right ones, wrong revision and wrong article. # Steps at the station and why it stops ## Scanning a part Scan the label (or press the camera button). The system checks in turn: 1. **Can the label be read?** Otherwise: _The label could not be read_ – the technician sees it in System → Labels. 2. **The right article?** Otherwise: _wrong article_, and what was expected. 3. **An approved revision?** Blocked, not approved in this product, not assessed yet or used up – stops with the reason. 4. **The individual:** serial already mounted in another unit, a sub-assembly not finished, a lot in quarantine or past best before. Labels with several codes: the station asks for _code 2 of 2_. If the revision is not in the code the station can ask the operator to pick among the approved ones. Every stop is saved and shown on the start page – the proof that wrong parts are not built in. ## Confirm **Confirm – done** when the work is done. ## Measurement Type every value (one box per reading) and **Save**. Out of limits: _Out of limits. Correct and measure again._ Both measurements are saved. Test: **Passed** or **Failed**. If it says _Waiting for the result from the test program …_ the test program can report the result itself: the step then moves on by itself (or the unit is blocked), and the buttons remain in case no result arrives. A failed test **blocks the unit**: _Test failed. The unit is blocked …_ – call for help. It is not built further until someone with the right permission has released the block, see Blocked unit. ## Waiting time and test time **Start waiting time** (or _start the test_ for e.g. a leak test). The next step is held until the time has passed. If the step allows it you can **Force…** with a reason, shown in the build record. If only someone with the permission may force (e.g. the production lead), that person scans their badge in the field below the reason, at the operator's station. The operator does not have to sign out, and the build record shows who forced. ## Signature **Scan personal code** (the badge). The signer can be someone other than the operator, and must have the qualification tag if the step requires it. **PIN** (if the step requires it): after the badge it says _{name}: enter your PIN_. Type it and press **Sign**. If you are the one signed in at the station, the PIN is needed only the first time per login; someone else who signs gives it every time. If you have not chosen a PIN yet (you can also do it under **Account → PIN at signing**), you choose one here: 4–8 digits, twice. After five wrong attempts the PIN is locked; ask an administrator to reset it (System → People), and you choose a new one. ## The label If the company prints labels, the unit's label is printed when you start it. At the top of the step it says whether it came out. If the printer is _Preview_, the label is shown on the screen: press **Done, the label is printed** (or **It did not come out**). If it did not come out of a real printer, it says why (e.g. that Browser Print does not answer, or that the printer is out of labels) and **Try again**. If the label is printed through an agent, it says _Sending the label to …_ for a short while. If it says _It is unclear whether the label came out_: look in the printer and answer **Yes, it came out** or **No, print it again**. The label is never printed again by itself. A **label step** has the button **Print the label**. The step is done when the label has come out (with Preview: when you have pressed **Done**). **Print the label again …** (under the step) prints a new label with the same serial number. Write a reason, e.g. _smudged_. It needs the permission to print again, and the reason is in the build record. ## Common messages | Message | Do this | | ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | _You are signed out at the station_ | Scan your badge again. | | _There is no released flow for this article_ | The product is not released – contact the process engineer. | | _… is started at S…, not at this station_ | Go to that station, or choose the right station. | | _Serial number … exists for several articles_ | Serial numbers are per article, so the serial alone is not enough. Scan the label with article number and serial number. | | _The label says revision …, but the unit is revision …_ | The company requires the right revision on the label (System → Production). Check that it is the right label on the right unit, otherwise contact quality. A label without revision is stopped too. | | _Rev … of … is not released in Design yet_ | The revision is new and has not been released in Design. That is on purpose: someone must go through the instruction first. Contact the process engineer or Quality, see A new revision of an article. | | _The label can be read in two ways_ | The label format must be fixed (System → Labels or Structure). | | _Serial number … is already mounted in unit …_ | The message says which unit. If the part is right and that unit is the mistake: ask someone who may to void the unit in Traceability, and the part becomes free. | | _The label matches the format … which is not approved yet_ | The technician approves the format under System → Labels. | | _This part is blocked or scrapped_ | The part may not be mounted. Take another one. | # Traceability Everything that happens is saved as **events** that are never changed or deleted. Traceability reads them. ## Searching Scan or type a **serial number** (unit or component) or a **lot number**. The beginning is enough: _26-1_ finds all that begin like that. A **scanned label** works too, also when it holds more than the serial number (for example _serial|article|revision_). It is read the same way as at the station, with your label formats. If no format fits, the search looks for the part of the label that is a whole serial number or lot number. If several articles have the same serial number, the article named on the label is opened. ## Browsing Without a search: product family → article → serial numbers, with the number in progress, blocked, in quarantine, released and scrapped (the same words as on the unit's page; a count of zero is not shown, except released). ## The unit's page - **Deviations:** in the unit itself and **in the parts**, all the way down the tree. See Deviations. - **Build record:** who did what, when and where, with revision, stops at scan, forcing with the reason, signatures and calls (_I need help_: one line per call, with whether the operator was standing still, who acknowledged it and how long it took). A test result reported by a test program stands with _from the test program …_ and the link **Open the report**. **Print** gives a printable version. - **Contents:** everything mounted in the unit, down through all levels (top → sub-assembly → components). - **Mounted in:** upwards – which unit this one sits in. If it has sat somewhere else before (taken out, or freed when that unit was voided), it is listed under **Earlier placements**, with time and reason. ## Deviations A deviation is when the unit was not built exactly by the instruction, or when someone had to step in and approve something the app would otherwise have stopped: - **Forced wait:** a wait (e.g. curing) was broken before its time, with a reason. - **Failed:** a test or measurement was out of limits. If a new attempt passed it says _Failed, then passed_; it still counts, since the product was out of limits once. - **Voided:** the unit was voided. **In the parts** shows deviations in everything mounted in the unit, at every level: one row per part, with what, when, who and why. Click the serial number to open the part. Under **Contents** the same parts are marked _deviation_. So whoever looks up a returned product sees at once if something happened in its parts, even far down. **Prevented errors** are stops at the scan: a wrong component was scanned and stopped. That is not a deviation, since the wrong part never got in. It shows that the gate worked. The deviations are also at the top when the build record is printed. ## Void a unit that went wrong Started the wrong unit, or scanned the wrong part into it? A unit cannot be deleted – the log is never changed – but it can be **voided**: 1. Open the unit in Traceability (search for the serial number). 2. Press **Void the unit…** under the unit's details, write a **reason** and confirm. This happens: - The unit gets the status **Scrapped** and cannot be worked on in production any more. - **The parts mounted in it become free** and can be scanned into another unit. The build record says _Removed_ for each part and _Unit voided_, with the reason and who did it. - The serial number cannot be used again. If the unit is mounted in another unit, void the top one – then everything in it becomes free. The button is only shown to those with the permission _units.status_ (the roles Quality and Admin from the start). ## Blocked unit If a **test** fails at the station, the unit becomes **Blocked**. It cannot be built further – at that station or any other – until the block is released. The station shows _The unit is blocked_ and the operator calls for help. 1. Open the unit in Traceability. At the top it says _The unit is blocked_, which test failed and when. 2. Investigate the cause, e.g. a retest or a repair. 3. Press **Release the block…**, write a **reason** and confirm. The unit gets the status **In progress** again and continues where it was: the failed test is done again at the station. The build record shows _Blocked: the test failed_ and _Block released_ with the reason and who did it. If the unit is not to be built further: **void** it instead (see above). The button is only shown to those with the permission _units.status_ (the roles Quality and Admin from the start). A measurement out of limits does not block: one corrects and measures again. ## Lot The lot page shows every finished unit that got the lot – the answer to "which units have sealant from lot L2291?". ## Where is an article used? For recalls and complaints: _which products, at which customers, have 3001-12 rev A?_ 1. **Traceability** → the tab **Where is an article used?**. From a part's page you can also use the button **Recall: all units with … rev … →** under **Sits in**. 2. Search for the **article** by number or name. 3. Choose **revisions** (none chosen = all) and, if needed, a date **From** and **To and including**. The date is when the part was mounted. 4. **Search.** The answer comes in parts, with counts at the top: - **Finished products:** released products the article sits in, at any level, with the customer, the part's serial and revision, the sub-assembly it sits in and the date. - **Blocked:** the part sits in something that is blocked or in quarantine. What you look at first in a recall. - **Being built:** the part sits in something not released yet. - **In stock:** loose parts, and released sub-assemblies with the part that are not in a product yet. Block them before they are built in. Click a row to open the product. **Download (CSV)** gives the list as a file, e.g. to pass on or open in Excel. The address keeps the search, so the link can be sent to a colleague. Scrapped units are not shown. The list is always complete, also when it is several thousand rows long. Past 20,000 rows the first ones are shown and a red line at the top says how many there are: then narrow by revision or date and search in several rounds, so that nothing is missing. The same goes for the list on a lot. ## Who sees what If you may see a unit you may see everything mounted in it. Upwards and for lots, only units you may see are shown, so a customer never finds another customer's units. # System System (called Admin until October 2026) is an overview with one tile per area, in three groups: **The company** (sites, people, roles), **Way of working** (how production works) and **Add-ons and data** (features, labels, AI, import from ERP, export, support access). Each tile says what it is for and shows how things stand in one line, for example _People: 9 · Terminals: 2_ or _Support access: Closed_. Click the tile to open its page. You only see the tiles you are allowed to open, and at the bottom **What may I do?** lists your own permissions. ## Sites and stations Sites, departments, groups and stations (name and code, e.g. _S4 Final assembly_). A station always belongs to a site and can be in a group. The tile **Sites and stations** shows how many there are and opens the page where you make changes (requires the permission for sites and stations). Each site is shown as a tree: departments as cards, groups as cards inside them and stations in their group. Changes are saved at once. - **Change group** of a station: drag the station to the group. You can also click the station and choose the group in the list (handy on a tablet). Click the station to change its name or code. - **Move to another site** (if something ended up in the wrong place): press **⇄** on the station, the group or the department, choose the site and press **Move**. A department takes its groups and stations with it, a group its stations, and people who have the group as home group follow. Operators signed in at the station are signed out, a terminal locked to the station follows it, and the history stays at the old site. A station code is unique in the whole company, so the code goes with it. - **Remove:** a station used in a flow or with history cannot be removed – rename it instead. A group can be removed when it has no stations. If you remove a department, its groups stay directly under the site. A site can be removed when it is empty. ## Departments and groups A **group** is the people who work together at the same board, e.g. a line, a cell or a team, and gathers stations. A **department** gathers groups. Both levels are optional: a small company manages with a site and stations, and a group can lie directly under the site without a department. - **Add:** **+ Department** and **+ Group** below the site's cards (directly under the site), **+ Group** in a department and **+ Station** in a group. Type the name and press **Save** (Esc cancels). A new station gets the next code that is free in the whole company (two stations cannot both be S7, not even at different sites), and the form stays open so that you can add several in a row. - **Change department** of a group: drag the group by the handle **⠿** to the department. While you drag, a box appears where you can drop it directly under the site. The number after the name is the number of stations. - **Rename:** click the name of a department or group and type. - **Other stations** are not in any group. A station belongs to a group or to none, never directly to a department. **Names of the levels:** at the bottom of the page you can give the levels your own names, e.g. _Line_ instead of _Group_ or _Hall_ instead of _Department_, one name per language. An empty field gives the standard name. The names are used throughout the app. ## The group's items Each group has a list of the items it is responsible for. Targets are set per item in the list. Open the list with **Items** at the bottom of the group's card. **The group's shifts:** **Shifts** at the bottom of the group's card shows the site's shifts. Tick the shifts the group runs. If none is ticked, the group runs all of the site's shifts. A target for the group can only be set for a shift the group runs. - **The list fills in by itself** with the items whose released flow has a step at the group's stations. A new item joins when its flow is released. - **Remove** (✕) an item the group does not want to follow. It stays crossed out, and **↺** takes it back. - **Add** an item in advance, e.g. a new board that is soon released: type the item number and press **Add**. As long as it has no step in the group it says _No step here_, and nothing is counted for it. - Changing the list requires the permission to set targets. Everyone who sees the group sees the list. **When does a unit count as done in the group?** When all of the group's steps for the unit are done, at the time the last of them was done. If the flow has parallel tracks in the group, the unit counts when all tracks are done. If the flow passes the group twice, the unit counts once, at the last pass. A test that fails does not count; the unit counts when the test finally passes. An item that is not in the list still counts, but without a target, so that nothing disappears. ## Shifts At the bottom of each site is **Shifts**. Type the name, when the shift starts and ends, and press **Add shift**. Then: - **Weekdays:** press the days the shift runs (blue = runs). New shifts run Monday–Friday. - **Breaks:** **+ Break** adds a break in the middle of the shift; change the times and the name (e.g. _Lunch_). Breaks are left out when the day's plan is spread over the hours. - **Remove:** **✕** and then **Sure?**. **Hour by hour** on the start page shows the shift going on. Between two shifts and after the day's last one, the latest shift is shown until the next starts, so you can see how it went; before the day's first shift, the first one is shown. This holds for both the group's and the site's board. "The day's" means the production day's, see below. **Night shifts:** a shift that ends before it starts (e.g. 22:00–06:00) ends the next day and is shown with _(+1)_. Breaks after midnight work like any other. **The production day starts** (at the top under Shifts) decides which day a shift counts to: targets, output, hour by hour and _per day_ in custom dashboards. A shift counts to the production day it starts in. The default is 00:00. If you have night shifts: - **06:00** (or when the day's first shift starts): the night shift Monday 22:00 → Tuesday 06:00 counts to **Monday**. - **22:00**: a time after 12:00 means the evening before. The day "Tuesday" then starts Monday 22:00, and the night shift counts to **Tuesday**. If a shift crosses the start of the day (e.g. a night shift with the day from 00:00) the page warns, since part of the shift then counts to the wrong day. ## People and roles The tile **People and terminals** opens the page where you see who works in the company and which roles they have (requires the permission to manage people). What each role contains is changed under the tile **Roles and permissions**. The list is on the left, the one you picked on the right. Add with **+ Person**. | Field | Means | | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Site** | The site the chooser at the top of the page starts at when the person signs in, or _All sites_. It is a preselection, not a restriction. | | **Group** | The person's home group at the site (shown when the site has groups). A preselection, not a restriction. | | **Roles** | One or more. The person gets everything the roles give together. See Roles and permissions. | | **What the person may do** | What is ticked and locked comes from the roles. Tick something more to give a single permission on top of the roles (marked _extra_). Nothing can be taken away. | | **Qualification tags** | Which steps the person may perform and sign, e.g. _Welding_. A new tag is created in the field next to them. | | **Badge** | The code scanned at the station, when signing and when forcing. **Print the badge →** gives a label to print for the person. | | **PIN at signing** | Only if the feature is on. Shows whether the person has chosen a PIN (never the PIN). **Reset PIN** when it is forgotten or locked after five wrong attempts; the person chooses a new one at the next signing. | | **Sees only the customer** | For a customer's own login: the person sees only that customer's products and units. | Everything is saved with **Save**. The company must always have at least one administrator who can sign in, and you cannot remove your own administrator role. **When someone leaves:** press **Deactivate**. The person can no longer sign in or use the badge, but the name stays in the history, and **Activate again** undoes it. **Erase personal data** removes name, badge, roles and the login with its e-mail address for good (the history then shows a removed person) and cannot be undone. A login that is also used in another company stays there. ## Login and password A person only needs a **login** to sign in themselves; at the station the badge is enough. There are two ways: - **Invitation by e-mail (most common):** fill in **E-mail**, leave **Temporary password (optional)** empty and save. The app shows _An invitation has been sent to …_. The person gets an e-mail from NoGaps (`noreply@nogaps.se`, in Swedish and English), opens the link, comes to _Welcome to NoGaps_ and chooses a password. The link is valid for one day and only once. - **A password you hand over:** fill in E-mail and a temporary password (at least 8 characters, **Suggest** gives one) and save. No e-mail is sent. The person can change the password under **Account → Change password** at the top right. If someone has forgotten their password, they can click **Forgot password?** on the sign-in page themselves. You can also open the person and press **Send a link for a new password** under **Login** (the same e-mail, and it also works when an invitation has expired), or type a new password and press **Set new password**. The **e-mail address** is shown under the name in the list (you can search for it too) and in the field **Signs in with** under **Login**. If the person should sign in with another address: type the new one and press **Change e-mail**. The app asks first and says if the same login is used in another company, where the change applies too; press **Yes, change e-mail**. It applies at once, and the password stays the same. A login can be used in several companies (for example the test environment and the real company). Then you can only change the e-mail and password if you are an administrator in all of those companies, and the change applies in all of them. ## Company account (SSO) If the company has **company sign-in** (SSO, set up by NoGaps together with your IT), the people sign in with their usual work account, for example Microsoft. They have no password in NoGaps, and passwords, two-step verification and leavers are handled by your IT. Which domains it applies to (e.g. _customer.com_) is shown under **Login** when you add a person. - **New person:** fill in name, roles and **E-mail** with the company’s domain. The password field goes away and it says _The address belongs to the company’s sign-in_. Save. The list shows **Not signed in yet** until the person has signed in the first time; then the account is connected and it says **Company account**. No e-mail is sent. - **Wrong address before the first sign-in:** open the person, type the right address under **Signs in with** and press **Change e-mail**. After the first sign-in the address is changed by your IT, not here. - **People who already have a password** and an address in the domain sign in with the company account next time. The password in NoGaps then stops working, and the person keeps roles and history. - **Someone leaves:** close the account at your IT, and the person cannot get in again once the sign-in has expired (usually after a shift). To stop it at once: **Deactivate** the person here too. - **Let in everyone from the domain** (if NoGaps has turned it on for you): whoever signs in the first time becomes a new person without roles. They see nothing until you have given roles. - Addresses outside the domain (e.g. consultants) and **terminals** sign in with e-mail and password as usual. ## Terminals A **terminal** is a shared login for tablets and handhelds on the floor, so operators without e-mail can work. Add with **+ Terminal**: name (e.g. _Assembly 1_), **site**, e-mail and password. The address does not need to receive e-mail. - The terminal can only open the station view. The operator **scans a badge**, and everything is saved in the operator's name – never the terminal's. - The same terminal can be signed in on **several tablets** at once. - **Locked to station:** a fixed tablet always shows its station. Without a lock the station is chosen on the terminal, among the stations at the terminal's site. ## Usage The box at the top counts **full users** (own login), **operators** (badge only) and **terminals**. Inactive people are not counted. The numbers are counted from the list and cannot be changed by hand. **The licence** covers full users and terminals. If the company has a limit it says e.g. _3 / 5_: three of five are in use. **Operators have no limit** and can always be added. - **The limit is reached:** the box turns yellow. You cannot give more people a login or add more terminals until someone is deactivated or the licence is extended. Everyone who is already there works as before, and production is not affected. - **The agreement has run out:** the same – nothing stops working, but no more logins and terminals can be added. The last day is shown in the box when fewer than 30 days remain. Contact the supplier to extend the licence or renew the agreement. ## Read-only company A yellow row at the top of every page means that the company is **paused** or that the agreement has **ended**. Then everything is read-only: - Everything can be **read**: products, instructions, traceability and build records. - Nothing can be **changed**, and nothing can be **built**: the stations cannot be opened and everyone is signed out of them. The station says that the company is paused, and signing in is blocked. - Buttons for changing and saving disappear, because the permissions temporarily only cover reading. The pages for people, roles and settings under System cannot be opened meanwhile. Roles and people stay as they were. A paused company is back to normal as soon as the supplier removes the pause. After an ended agreement everything can be read for one year; the last day is in the yellow row. ## Features **System → Features** (requires the permission for settings) shows which features the company uses. Turn off what you do not use, and the menus get cleaner. | Group | Means | | ------------ | ---------------------------------------------------------------------------------------------- | | **Included** | Comes with the system. Turn on and off with the switch. | | **Add-ons** | Bought separately. If it says _Not included_ the company has no access – contact the supplier. | | **Core** | Design, Production, Traceability and System. Always on. | - **Off means hidden, not removed.** Menu items and buttons disappear for everyone in the company, and the permissions that belong to the feature do not apply meanwhile. All data stays and is back when the feature is turned on again. Traceability is never affected. - **New features** appear in the list marked _New_ and are off until you turn them on. So the menus never change by themselves. - **Requires …:** some features need another one. _AI for labels_ only works when _Labels_ is on; the choice is kept and applies again when the other is turned on. - **Ask the help** is off from the start. Turn it on and the box is at the top of the help for everyone in the company, see Ask the help. - **Calls** cannot be turned off while there are open calls. Resolve them first. - **Labels** off: the formats that already exist are still used when scanning, but they cannot be changed and the Labels page disappears. GS1 and ISO 15434 are always read. - **Goals and dashboard** off: the start page only shows shortcuts. - **AI for dashboards** needs _Own dashboards_ and the company's AI key. It is off from the start. - **Own dashboards** is off from the start. Turned on, **Dashboards** is in the menu, see Own dashboards. ## Support access The supplier never sees into your company by itself – only numbers such as how many users there are. If you need help, you let support in under **System → Support access**: 1. Press **Let support in…** 2. Choose **for how long** (1 hour to 7 days; 1 hour, the shortest, is preselected) and **what support may do**. 3. Write what it is about and press **Give access**. | Level | Support can | | ---------------------------- | -------------------------------------------------------------------- | | **Look only** | See the start page, Design and Traceability. Nothing can be changed. | | **Look and change settings** | Also change Design, articles, labels, sites and stations. | Support can **never** manage people and roles, see badges, build at a station, release revisions, change quality decisions or export data – whatever the level. - The access ends by itself when the time has run out. **End now** closes it at once. - Everything support changes is in your change log, with support as the one who did it. That the access was given and ended is there too. - Only an administrator who manages people can give or end the access. Everyone in the company can see whether it is open. - Support does not count as a user in the licence and is not shown in the list of people. - Access can be given even when the company is paused. ## Export **System → Export** (requires the permission to export the company's data, which the Admin role has) takes out everything the company has put into the system as a zip file (several when there is a lot of data). The files can be read without NoGaps, so the export works as your own archive. At the top it says how many units and events the company has. At **Build records**, choose whether they are written **for every unit**, **for units created in a period** (from – to and including) or not at all. The tables are always included in full. Press **Make an export** and keep the tab open until the file is downloaded. **Cancel** stops an export that is running. | In the file | Contents | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ | | **README.txt** | Explains the contents and how to find a unit. | | **data/** | One CSV file per table: articles, revisions, structure, flows, instructions, units, lots, the whole event log, the change log, people and roles. | | **build-records/** | One build record per unit, as a page that opens in the browser and can be printed. **index.csv** lists serial number, article and file name. | | **files/** | Instruction pictures and label photos, as they are. | **Large exports.** The export is built in the browser. With a lot of data (tens of thousands of units) it is saved as several zip files, `…-part-01.zip`, `…-part-02.zip` and so on, downloaded one at a time while the export runs. The browser may ask whether the page may download several files – answer yes. Unpack them all into the same folder. README.txt is in the last one. The page says beforehand roughly how long it takes: a year's production at 1,000 units a day takes about a quarter of an hour for the tables and a couple of hours more for build records for every unit. Choose a period or leave the build records out if you do not need them all – everything in them is in the tables too. - In a large export, large tables are split into files of 50,000 rows (`events-001.csv`, `events-002.csv` …), the build records are in a folder per day and the list is called `index-001.csv`, `index-002.csv` … - **Finding a unit without the system:** open `build-records/index.csv` in Excel, search for the serial number and open the file on that row. - **Not included:** badge codes (they work as signatures), passwords and the AI key. - **Every export is saved in the change log**, with who made it. - The export also works when the company is paused or the agreement has ended. **After an ended agreement the data is kept for one year** – make an export and save the file before then. The last day is in the yellow row at the top. - The CSV files have semicolons between the columns when the app is in Swedish and commas in English, so that they open correctly in Excel. README.txt says which applies. ## Production **System → Production** (requires the permission for sites and settings) decides how the stations work in the whole company. A change is saved at once and checked by the database at every scan. - **The station follows the unit:** no station has to be chosen at the tablet. A scanned unit or label takes the operator to the station where the unit is next (or where it starts), with the same sign-in. See The station follows the unit. - **Require the right revision on the label:** a label that opens or starts a unit must carry the revision, not only article number and serial number. When starting, the revision must exist on the article and be approved (or use up). For a unit that already exists it must be the unit's own revision. Otherwise the station stops with the reason, for example _The label says revision 2, but the unit is revision 3_. A serial number scanned on its own (without a label) is not affected. - **Traffic light for the groups:** seen from the department and the site, a group is green from _Green from_ % of its plan so far in the shift (standard 95) and red below _Red below_ % (standard 80), yellow in between. See The department and the site. - **Only those who set targets comment on the hours:** off (standard), everyone who works in the group may write why an hour was missed on the group's board – those with the group as home group, those signed in at one of the group's stations and those who set targets. On: only those who may set targets. See Hour by hour. ## AI AI is only used when someone asks for it: when setting up labels (**Analyse with AI**) and when building dashboards (**Build with AI**, see Own dashboards). Never at the station. The key is entered under **System → AI** and can never be read again. - **Model** applies to labels. Dashboards always use a low-cost model (Claude Haiku). - **Monthly limit (USD)**: when the month's estimated cost reaches the limit, the AI features stop until next month. Empty or 0 means no limit. - The month's usage and a cost estimate are shown. The cost is counted with each model's list price. Ask the help does not use the company's key. NoGaps pays for it, and only the number of questions asked is shown here. ## Agents **System → Agents**: the program NoGaps Gate on a computer in the factory, which reaches equipment in your network (today label printers). Agents are added, paired and revoked here. See Agents in the factory. ## Labels **System → Labels**: the company's standard formats, all formats, test labels and the list of labels that could not be read. See Labels. # Import from ERP **System → Import from ERP** reads a level list from the ERP (today Monitor) and sets up articles, revisions and the structure for you. It gives you a head start: the structure becomes **drafts in Design** that you carry on with – flow, scanning, instructions – and release as usual. The import releases nothing. The feature is an option turned on under System → Features and needs the permission _Import articles and structure from the ERP_ (Admin and Process engineer have it). The import has five steps: **File → Products → Articles → Structure → Import**. You can go back and forth between the steps before you import. ## The file Take out the **level list** in Monitor for the articles you want and export it to CSV. Two columns are needed besides the usual ones: - **Nivå – Nummer** (00, 01, 02 …). Without it there is no telling what sits in what, and the page says so. - **Revision**. Without it the articles are imported without revisions. Drop the file in the box or press **Choose file…**. The file is read in the browser and is not saved. When it has been read the box turns green with a tick and the file name, and below it the page shows how many rows, products, articles and levels it found. If the file cannot be read the box turns red and the page says what is missing. **Choose another file…** changes the file. **Try with example data** shows how it works with a made-up vehicle computer. ## Products Every top level in the file is listed. Tops with names that start the same are suggested as **variants of one product** (_CCpilot V1090 Basic_ and _CCpilot V1090 Extended_ → the family _CCpilot V1090_). In Design the variants become columns in the same matrix. - **Rename** a family by clicking its name. - **Move a variant** to another family, or give it one of its own, in the list on the right. - **Untick** products you do not want. - Tops that cannot be built (phantom revision articles, inactive, without structure) are under **Show tops that cannot be built**. ## Articles Here you see everything in the chosen products, as a **tree** or a **list**. - **▾ and ▸** collapse and expand a row. A collapsed row shows how many rows are under it, e.g. _6 of 10 left out ▸_; press it to expand. **Expand all** shows the whole tree again. - **Untick** what you do not want. An unticked row takes everything under it along. Rows that come along have a blue line on the left; those that do not are grey. - **A tick only applies to the row.** The rows above it come along (the row needs somewhere to sit), but what is under it does not change. So you can take a manufactured level without its parts. To have the parts too, press **+ Contents** on the row; what is under comes back according to the suggestions. - **Clear all** and then tick what you actually want, if that is easier than leaving things out. **Select all** brings everything, also what is suggested left out. While you search, the buttons only apply to the hits (**Select the hits**, **Clear the hits**). - The chips say what happens to the article: **New** (created), **New revision** (exists, gets the revision), **Exists** (already in the register) and **Differs** (exists with another name – it is not changed). - **The same article several times** under the same parent (different reference designators) is added together into one row with the sum, marked _2 rows_. - **The list** shows each article once. There you can change the **kind** (purchased, manufactured, software, consumable). The page suggests the kind from the ERP's article type; a phantom article with a version number as revision is suggested as software, and a purchased one with a decimal quantity as a consumable. ## Leave out The buttons under **Leave out** are suggestions for what is most likely not wanted. The number says how many rows each one concerns. Everyone builds their structures in their own way, so you decide: turn them on and off, and tick or untick single rows in the tree. | Button | What it does | At first | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | | **Phantom levels** | A phantom article is a kit in Monitor. It is never built and cannot have an instruction, so its material moves into the level above (times the phantom's quantity). The row shows _from …_. | On | | **Phantoms without structure** | Phantom articles with nothing under them, such as software images. Software is often worth keeping for traceability. | Off | | **Material in purchased** | What is under a purchased article, such as a cable made by a subcontractor. The article itself is kept. | On | | **Component lists** | Long lists of purchased components (more rows than you set), such as on a PCBA. The board itself is kept. | On | | **Consumables** | Rows with a decimal quantity, such as glue or thermal paste. | Off | | **Phasing out or obsolete** | Articles that are phasing out or obsolete in the ERP. | Off | **Back to the suggestions** removes your own ticks, also those from Select all and Clear all. ## Structure The suggestion for how the structure becomes in Design. Each level that is **built** becomes a family with positions and a matrix: the product at the top and then the sub-assemblies (an article is built here when something with a whole-number quantity sits under it). Positions are matched across the variants first by the same article, then by similar names and the same kind. **—** means the variant has nothing in the position. Click an underlined article to go to the sub-assembly. - A sub-assembly used in several products becomes **one** family (_Used in_ shows where). - **Exists:** the articles are already built in one family in NoGaps. That family is used as it is and is not changed. - **Left out:** some of the articles are already built in other families. That family is not set up. - The names of the positions come from the ERP and can be cut short. Rename them, choose what is scanned and build the flow in Design afterwards. ## Import The summary shows how many articles, revisions, families and positions are set up, and warns about articles that differ from the register or are phasing out. Press **Import**. It all happens in one go: either everything comes along or nothing. - **Existing articles are not changed** (name, kind, lifecycle), but get revisions they lack. - **New revisions** are approved if you may approve revisions (Quality). Otherwise they get the status _not assessed_, and Ready for release says they need approval. - **Structure as drafts in Design** can be turned off if you only want the articles. The structure can be imported later from the same file; what is already there is kept. - The same file twice creates nothing new. After the import, **Open Design** opens the products, where the drafts are waiting. # Agents in the factory An **agent** (NoGaps Gate) is a small program you install on a computer in the factory. Through it NoGaps reaches equipment in your network. Today that is **label printers**: the agent fetches the labels from NoGaps and sends them to network printers, so that a station can print from a tablet without a computer of its own. Later, results from e.g. screwdrivers, machines and test equipment are meant to go the same way. The agents are under **System → Agents** (needs the permission to change settings, and the feature _Label printing_). One agent is enough for all the equipment at a site. ## Good to know for your IT - The agent **only calls out**, with HTTPS on port 443 to NoGaps. Nothing is opened towards your network. - It is **no tunnel**. It can only send a label to a printer that you have set up in NoGaps yourselves. - It only connects to addresses and ports in **the agent's own list** (the file _config.json_ on the agent's computer). From the start that is your internal networks on port 9100. The list is only changed on the computer, never from NoGaps. - In Windows it runs as a **service** with the low account _Local Service_, not as an administrator. - The agent's key is never shown in NoGaps. It can be **revoked** at any time. ## Install in Windows The computer must always be on and reach both the internet and the equipment. The installation needs an administrator. You fetch the installer (_nogaps-gate.msi_) with **Download for Windows** on the page. If there is no such button, you get the file from NoGaps. 1. Add the agent in NoGaps, see Add and pair. You get a code. 2. Run _nogaps-gate.msi_ on the computer. Click **Next**, type the code in the box **Pairing code** and click through to **Finish**. 3. In NoGaps the box with the code changes to _✓ … is paired_, and the agent says **Connected** within a minute. The program has no window. It runs as the service **NoGaps Gate**, which starts with the computer and is started again by itself if it stops. | Where | What | | ------------------------------ | ---------------------------------------------------------------------- | | `C:\Program Files\NoGaps Gate` | The program | | `C:\ProgramData\NoGaps Gate` | The settings (_config.json_), the key (_key_) and the log (_gate.log_) | | Services in Windows | _NoGaps Gate_, starts automatically | The folder with the settings can only be read by administrators and by the service. **Silent installation** (for rolling out with e.g. Intune or a group policy): ``` msiexec /i nogaps-gate.msi /qn GATE_CODE=ABCD-EFGH ``` **Pair later or again:** leave the code empty in the installation, or make a **New code** in NoGaps, and run this in a command prompt as an administrator. The service starts using the new key by itself. ``` "C:\Program Files\NoGaps Gate\nogaps-gate.exe" pair --server https://… --code ABCD-EFGH ``` The address after `--server` is in the command NoGaps shows below the code. **Uninstall** under _Apps_ in Windows. The folder `C:\ProgramData\NoGaps Gate` with the key stays: **revoke** the agent in NoGaps and remove the folder. ## Linux and Raspberry Pi The program is a single file, _nogaps-gate_. Put it on the computer and run the command NoGaps shows below the code (**Linux, or an agent that is already installed** → **Copy the command**). It says _Paired as …_. Then start the agent with `nogaps-gate run`, or let your IT set it up as a service. ## Add and pair 1. **System → Agents**: type a name, e.g. _Agent Alfta_, choose the site and click **+ Agent**. 2. A box shows a **code** (e.g. _ABCD-EFGH_). The code is valid for 10 minutes and can be used once. 3. Type the code in the installer on the computer (Windows) or run the command (Linux). 4. The box changes to _✓ … is paired_, and the agent says **Connected** with the computer's name and the agent's version. 5. Set up what is to go through the agent. A printer is set up under Label printing → Printers with the kind **Agent (network printer)**. Try it with Print an example. Below each agent you see which printers go through it. ## The state The state is shown at each agent: - _Connected_: the agent has been heard from in the last half minute. - _No contact since …_: the program is stopped or has no network. Labels that go through the agent become an error at the station after a minute, see Printing through an agent. - _Not paired yet_: the agent has been added but the code has not been used. - _Revoked_: the agent has been turned off from here. The tile **Agents** under System shows how many are connected. ## Move, revoke and remove - **New code** makes a new code, e.g. when the agent is moved to another computer. The old installation stops working at once. - **Revoke** (click twice) turns the agent off at once. What goes through it stays. With **New code** it can be paired again. - **✕** (click twice) removes the agent. The printers that used it stay, without an agent. # Integrations (API) **System → Integrations** lets the company's own systems – ERP, test systems, reporting tools – **read** units, build records and events from NoGaps through an API. A test program can also **report test results**, so that the test step completes by itself, and NoGaps can **tell** a system when something happens, with webhooks. Each system gets an **API key** of its own, which you create here and can revoke at any time. The feature **Integrations (API)** is turned on under System → Features and requires the permission _Create and revoke API keys_ (Admin has it). The same permission covers webhooks. The API reads. The only thing it can change is to report a test result, and only with a key that may. ## API keys A key is a long password for a system, not for a person. Give **each system a key of its own**, so you can see which one reads and revoke one without disturbing the others. **Create:** fill in **New key** and press **Create key**. - **Name** – which system the key is for, e.g. _Monitor ERP_. - **Site** (shown when the company has several) – choose a site if the system should only see that one. Otherwise _All sites_. - **Valid through** – an optional end date, e.g. for a consultant trying things for a month. - **May see people's names** – without the tick the system learns _that_ someone did something but not who (only an id). Tick it only if the system needs the names. - **May report test results** – for a test program that is to report passed or failed, see Test results from a test program. Without the tick the key can only read. The key is shown in a green box **once only**. Press **Copy** and put it into the system that is to use it, or hand it to whoever builds the connection in a safe way (not in an ordinary e-mail). NoGaps does not keep the key in clear text, so it cannot be shown again: if it is lost, create a new one and revoke the old. **The list** shows for each key how it begins (so it can be recognised), what it may do, when it was created, when it was last used and how many requests it has made. A key that is no longer used can be revoked. **Revoke:** press **Revoke** and then **Sure? Revoke**. The key stops working at once and cannot be opened again. Revoked and expired keys remain under **Show revoked and expired**. That keys were created and revoked is in the change log. If the feature is turned off, all keys stop working but are kept, and work again when it is turned on. A paused company can still be read, but test results cannot be reported. ## Test results from a test program A step of the kind _Result from a test program_ (see Measurement) can complete without the operator pressing anything: the test program sends _serial number, passed or failed_ and preferably a link to the report. 1. Create a key with the tick **May report test results** and name it after the test system, e.g. _PT-200_. Hand the key to whoever looks after the test program, together with the description. 2. At the station the step says _Waiting for the result from the test program …_. When the result arrives, the station moves on by itself within a few seconds. 3. **Passed:** the step is completed, just as if the operator had pressed **Passed**. **Failed:** the unit is blocked, just as when the operator presses **Failed**, until someone with the right permission releases the block. In the build record the result stands with the key's name instead of a person, _from the test program …_ and the link **Open the report** if a link was sent. If no result arrives (the test program is down, the network is gone) the operator can still press **Passed** or **Failed**. A result is only accepted while the unit stands at the test step: if the steps before it are not done, or the unit is blocked, the test program gets an error back and nothing is saved. ## Webhooks With a webhook **NoGaps tells you** instead of the system asking: when something happens, a message is sent to an address you give. It suits the ERP that should know when a unit is finished, or someone who should be alerted about a failed test. **Create:** fill in under **New webhook** and press **Create webhook**. - **Name** – what the messages are for, e.g. _ERP: finished units_. - **Address (https)** – where the messages are sent. It must start with `https://` and be a host name that is reached from the internet: not an IP address and not an address in your own network. - **Site** (shown when the company has several) – choose a site if only its units should give messages. - **Events** – **Unit finished** (the unit is released after the last step), **Unit blocked** (a failed step or test has blocked it) and **Test failed** (a test step failed, by the operator or a test program). A failed test thus gives both _Test failed_ and _Unit blocked_ if both are chosen. **The secret** is shown in a green box **only once**. Press **Copy the secret** and hand it to whoever builds the receiver: with it the receiver checks that the message really comes from NoGaps, see Receiving a webhook. If it has been lost, remove the webhook and create a new one. **The list** shows for each webhook the address, the events and how it went the last time: _Delivered_ or _Failed_ with the reason. - **Send test** sends a test message (`ping`) at once, so that you see that the address answers. - **Pause** stops the messages without removing the webhook; **Resume** starts it again. What happens during the pause is not sent afterwards. - **Remove** and then **Sure? Remove** removes the webhook and its log. **Sent messages** shows the latest 50: time, webhook, event, serial number, status, number of tries and the answer. **Delivered** means that the receiver answered that it took the message. If it does not answer, or answers with an error, it says **Trying again** and a time: NoGaps tries again after 1 minute, 5 minutes, 30 minutes, 2 hours, 6 hours and 24 hours. If none of the seven tries works it says **Failed**, and then you can press **Send again** when the receiver works. Press **Refresh** to see the latest status. Messages are kept for 30 days. A company can have at most ten webhooks. If the feature is turned off nothing is sent. That webhooks have been created, paused and removed is in the change log. ## Try the API Under **Try the API** you can see what a system gets. Paste a key (a newly created one is already in the box), choose what to fetch and press **Fetch**. The answer is shown below: **Answer 200** and the data when it went well, otherwise an error code, e.g. **Answer 401** for a revoked key. The key is only sent to the API and is not saved on the page. Choose **Send a test result** to try what a test program does: type the serial number, choose **Passed** or **Failed**, add a link if you like and press **Send**. It is a real result: the unit's test step is completed or the unit is blocked. **Answer 201** means it was saved; **Answer 409** that the unit does not stand at such a step right now. ## For whoever builds the connection **Address:** shown on the page under _For whoever builds the connection_, ending in `/functions/v1/api/v1`. All requests are `GET` over HTTPS, except test results which are sent with `POST`, and answer with JSON. A machine-readable description (OpenAPI) is on the page as **OpenAPI file**. **The key** is sent with every request, as `Authorization: Bearer ngk_…` or `X-API-Key: ngk_…`: ``` curl -H "Authorization: Bearer ngk_…" "https://…/functions/v1/api/v1/units?serial=26-12345" ``` | Address | Gives | | ----------------------- | ------------------------------------------------------------------------------------------------------------------- | | `/v1` | Whose key it is. Good for checking that the address and the key work. | | `/v1/units` | Units, oldest first. Filters: `serial`, `article` (article number), `status`, `since` (created at or after). | | `/v1/units/{id}` | One unit, with what is mounted in it (`components`) and where it is mounted itself (`used_in`). | | `/v1/units/{id}/events` | The unit's build record: everything that has happened to it, in order. | | `/v1/events` | Events about units, in the order they came in. Filters: `type` (several with commas), `unit_id`, `serial`, `since`. | | `POST /v1/test-results` | Reports a test result, see below. Requires a key that may report test results. | **A unit** has among other things `id`, `serial`, `status` (`in_progress`, `released`, `blocked`, `quarantine`, `scrapped`), `created_at`, `released_at`, `article_number`, `article_revision`, `product`, `customer` and `site`. `{id}` in the addresses is the unit's `id`, not the serial number: look it up with `/v1/units?serial=…`. **An event** has `id`, `type`, `occurred_at` (when it happened), `recorded_at` (when it came in), `serial`, `article_number`, `station`, `operation`, `step`, `reason` and `data` with details that depend on the type. Common types: `unit.created`, `step.completed`, `component.mounted`, `measurement.recorded`, `test.result`, `signature.given`, `unit.released` and `unit.status_changed` (blocked, quarantine, scrapped: see `data.status`). Calls about a unit are included, with their note. Events that are not about a unit (comments on the board, sign-ins) are not given out. **Pages:** the lists give at most `limit` rows (100 if nothing is given, at most 500) plus `next_cursor` and `has_more`. Send `next_cursor` as `cursor` to go on from where the previous answer ended. `has_more` is `true` when there is more to fetch straight away. **Following what happens:** fetch `/v1/events`, save `next_cursor` after each answer and ask again with it, at once if `has_more` is `true` and otherwise e.g. once a minute. If nothing new has come you get the same `next_cursor` back. Every event has an `id` that never changes: cope with the same event arriving twice, and fetch a unit's whole build record with `/v1/units/{id}/events` when everything must be there. **Reporting a test result:** `POST /v1/test-results` with `Content-Type: application/json`: ``` curl -X POST -H "Authorization: Bearer ngk_…" -H "Content-Type: application/json" \ -d '{"serial": "26-12345", "passed": true, "report_url": "https://test.example.com/runs/8841", "id": "run-8841"}' \ "https://…/functions/v1/api/v1/test-results" ``` - `serial` (required) – the unit's serial number. - `passed` (required) – `true` for passed, `false` for failed. - `report_url` – a link to the report (`http` or `https`). Shown in the build record. - `id` – the test run's own id in the test system. Always send it: if the same `id` comes again with the same key the API answers `200` with `"duplicate": true` and saves nothing, so it is safe to try again after an interruption. - `program` – the test program's name as it stands in the step. Only needed if the unit has several open test-program steps at once. - `article` – article number. Only needed if several units have the same serial number. - `tested_at` – when the test was run. Kept as information; the event gets the time it came in. The answer `201` has `event_id`, `passed`, `step_completed`, `released` (the unit was released by this, as its last step), `step` and `unit`. The unit must stand at a step of the kind _Result from a test program_; otherwise the API answers `409` and saves nothing. A failed result blocks the unit (`unit.status` becomes `blocked`). **Times** are UTC in the format `2026-11-11T09:30:00.000000Z`. **Errors** answer with a status code and `{"error": {"code": "…", "message": "…"}}`: | Status | Code | Means | | ------ | ------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | 400 | `bad_limit`, `bad_parameter`, `bad_id` | A parameter is wrong. | | 400 | `bad_json`, `bad_body`, `bad_serial`, `bad_passed`, `bad_report_url`, `bad_tested_at` | The test result is wrongly formed; `message` says what. | | 401 | `missing_key`, `invalid_key` | The key is missing, unknown, revoked or expired. | | 403 | `integrations_off`, `organization_closed` | The feature is turned off, or the company is closed. | | 403 | `scope_missing`, `read_only` | The key may not report test results, or the company is paused. | | 404 | `not_found`, `unit_not_found` | The address or the unit does not exist (or belongs to another site than the key's). | | 405 | `method_not_allowed` | Only `GET` works (and `POST` to `/v1/test-results`). | | 409 | `no_test_step`, `step_not_ready` | The unit does not stand at a test-program step, or the steps before it are not done. | | 409 | `unit_blocked`, `unit_quarantine`, `unit_scrapped` | The unit is blocked, in quarantine or scrapped. | | 409 | `ambiguous_serial`, `ambiguous_step` | Several units have the serial number (send `article`), or several test-program steps are open (send `program`). | | 429 | `rate_limited` | More than 600 requests in a minute with the same key. Wait and try again. | Within `v1` new fields and addresses may be added, but fields are not removed or renamed. Build the connection so that unknown fields are skipped. ## Receiving a webhook This is for whoever builds the receiver. NoGaps sends a `POST` with JSON to the address, and follows [Standard Webhooks](https://www.standardwebhooks.com/), so ready-made libraries for it (e.g. `standardwebhooks` for Node, Python, Go, Java, C# and more) can check the signature for you. ``` POST /your/address Content-Type: application/json webhook-id: 42f36df3-c5f9-4b9d-af70-2a071e3cdb26 webhook-timestamp: 1794436667 webhook-signature: v1,K5oZfzN95Z9UVu1EsfQmfVNQhnkZ2pj9o9NDN/H/pI4= {"id": "42f36df3-…", "type": "unit.completed", "created_at": "2026-11-11T22:37:47.514410Z", "data": {"event": {…}, "unit": {…}}} ``` - `type` is `unit.completed`, `unit.blocked`, `test.failed` or `ping` (the test message, where `data` only has `message` and `webhook`). - `data.event` is the event and `data.unit` the unit as it stands after the event, with the same fields as in the API. For `unit.completed`, `data.unit.status` is thus `released`, and for `unit.blocked` and `test.failed` it is `blocked`. Person names are never sent, only `actor_id`. - For `test.failed` from a test program the link to the report is in `data.event.data.report_url`, if one was sent. **Answer quickly with 2xx** (e.g. `200` or `204`) when the message is received, within 10 seconds: put it in a queue and do the work afterwards. Anything else – another answer, no answer – counts as failed and is tried again by the schedule above. **The same message can come several times** (e.g. if your answer did not arrive in time). `webhook-id` is the same at every try: save the ids you have received and skip the ones you have already seen. Messages can also come in another order than the events happened; use `data.event.occurred_at` if the order matters. If the whole picture is needed, fetch the unit through the API with `data.unit.id`. **Check the signature** before you trust the content. The signature is HMAC-SHA256 over the text `webhook-id.webhook-timestamp.body` (the three parts with a dot between, where _body_ is exactly the bytes that came, not a reformatted JSON), with the secret as the key: what comes after `whsec_`, decoded from base64. The result is base64-encoded after `v1,` in `webhook-signature`. Also refuse messages whose `webhook-timestamp` (seconds since 1970) is more than five minutes old. ```js import { createHmac, timingSafeEqual } from 'node:crypto'; // secret: "whsec_…" from NoGaps. body: the text exactly as it came. function fromNoGaps(secret, headers, body) { const key = Buffer.from(secret.slice('whsec_'.length), 'base64'); const signed = `${headers['webhook-id']}.${headers['webhook-timestamp']}.${body}`; const expected = Buffer.from('v1,' + createHmac('sha256', key).update(signed).digest('base64')); const fresh = Math.abs(Date.now() / 1000 - Number(headers['webhook-timestamp'])) < 300; return ( fresh && String(headers['webhook-signature']) .split(' ') .some((s) => s.length === expected.length && timingSafeEqual(Buffer.from(s), expected)) ); } ``` **Try without a receiver of your own:** the address that ends with `/functions/v1/api/v1/echo` takes any `POST` without a key, keeps nothing and answers `200`. Point a webhook at it and press **Send test** to see what a successful delivery looks like in the log. # Glossary | Word | Means | | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | **Article** | An article number: a product variant, a sub-assembly, a bought part, software or a consumable. | | **Revision** | A version of an article (A, B, 02 …) with a status: approved, use up, blocked or not assessed. | | **Top article** | What is sold and has its own serial – the columns of the matrix. | | **Sub-assembly** | Something you build yourselves that goes into a product, with its own articles, flow and revision. Also called a _level_ when the top is counted too. | | **Position** | A place in the structure (_Motor_, _Screws_). | | **Matrix** | Article numbers per position and top article. | | **Property** (option) | What sets the articles apart (Size 25/40). Used in conditions, inherited downwards. | | **Structure / flow** | What the product consists of / how it is built (operations and stations). | | **03 · /5** | Product revision 03 (the article's), instruction revision 5 (running number per level). | | **Draft / released** | Being worked on / valid in production and locked. | | **Ready for release** | The check that shows what is left. | | **Operation** | A piece of work at a station, with steps. | | **Step** | Scan, instruction, measurement, signature or wait. | | **Condition** | Which articles a step applies to. | | **Unit** | An individual with a serial number. | | **Released** (unit) | A unit where all steps are done. | | **Lot** | A quantity of material with the same lot number. | | **Label format** | How a label is read (separator, parts, revision). | | **Build record** | Everything that happened to a unit. | | **Force** | End a waiting time early, with a reason. | | **Escalate** | A call nobody acknowledged in time. | | **WIP** | Work in progress: started, not finished. | # Questions and troubleshooting ## Something is shown in a red box at the bottom That is an error from the database, usually that something is not allowed. Common ones: _This is released and locked_ – start a new revision. _The article is already built in another sub-assembly or product_ – choose another article. Copy the text if you report it. ## I cannot change the structure or the flow It is released. Click **Change (new revision)** (structure) or **Change the flow (new revision)** (flow) for the level you want to change. An article added after the release is filled in without a new revision. If it says _You are looking at the released revision_ at the top: switch to the draft in the revision menu at the top right. ## I see no button to release Releasing requires the permission to release (e.g. Quality). A process engineer prepares, quality releases. ## A part in the matrix is grey and cannot be chosen It is already built in another sub-assembly (_built in …_). An article can only be built in one sub-assembly or product. ## Ready for release says _no approved revision_ The part's revision is _not assessed_. Quality approves it in **Design → Article register**. ## The station says the label cannot be read Set up the format in the structure (**Show labels**) or in System → Labels. The label is in the list _Stopped as unknown label_. If it says the format _is not approved yet_, there is a draft that matches the label: approve it under System → Labels. See Labels. ## The unit does not start from the label The flow must be released and begin at the station you are at – the message says where it is started. The label must have both article and serial number. ## The camera does not start The page must be opened over https (nogaps.se) and the browser must be allowed to use the camera. Reload and answer **Allow**. ## How do I report a problem? Write what you did, what you expected and what happened, and add a screenshot if you can. Give the product, step and article.