What the EDGEBIC Kiosk Does When the Network Drops

The EDGEBIC by User Solutions kiosk reads and writes the shared database live and has no offline mode, so if a terminal loses its connection it cannot punch until the connection returns. The honest fallback is to punch normally once the terminal is back online, or to record the missed work afterward through Manual Entry on the kiosk or the planner's Log Actuals dialog. There is no local queue that stores taps on the terminal and syncs them later. Understanding this behavior sets the right expectations for shop floor data collection on a floor with imperfect connectivity.

It is worth being precise here, because it is easy to assume a shop-floor terminal buffers everything and reconciles later. The EDGEBIC kiosk does not, and knowing exactly what it does instead lets a shop plan around it rather than be surprised by it.

The Live Shared-Database Model

The kiosk is a separate application that shares the planner's database directly, with no server in between. Every tap reads and writes that shared data live. This is what makes the loop feel instant: an operator taps Start Run and the planner's Job View shows the actual start within seconds, because both applications are looking at the same data. It is also what keeps the whole system simple, since the kiosk needs nothing running in the office to function.

The trade-off is dependence on the connection. Because there is no intermediate server and no local store, the kiosk needs a live link to the shared database to open or close a punch. When that link drops, punching pauses.

What Actually Happens on a Drop

When a terminal loses its connection, it cannot record punches until the connection is restored. Work on the machine does not stop, of course; the operator keeps running the job. What pauses is the real-time capture of state changes. If a run finishes or a pause begins during the outage, those moments were not punched as they happened.

Nothing about the work is lost, though. It simply needs to be recorded once the terminal is back, and EDGEBIC gives two honest paths to do that.

Fallback One: Punch When It Returns

The simplest recovery is to reconnect and resume punching. If the outage was brief and no state change was missed, the operator carries on tapping as normal and the record is complete. Live punches are always the preferred capture because they carry phase-level detail (setup versus run versus down) that a typed total cannot reconstruct. So the first rule on a network blip is to reconnect and punch normally as soon as you can.

Fallback Two: Manual Entry After the Fact

For work that happened while the terminal was offline, Manual Entry records it after the fact. It opens a day grid, one row per day, with the real hours and pieces, the same grid the planner uses. With auto-calculation on, typing one side (hours or pieces) derives the other from the rate. This is exactly how hours and pieces convert on the floor, applied to a typed entry rather than live taps.

A supervisor or planner can also enter the actuals through the planner's Log Actuals dialog, which is the office-side twin of Manual Entry. Either way the record ends up accurate; it just came from a considered entry rather than a live tap. And because a completion tapped this way still stamps a real actual start and end, the operation still anchors the next reschedule correctly.

What Is Not There Today

Be clear about the boundary so no one plans around a capability that does not exist. There is no offline punch queue on the terminal. The kiosk does not store taps locally during an outage and replay them when the connection returns. If you need work captured during a disconnection, you record it afterward through Manual Entry or Log Actuals, not through an automatic sync.

This honesty matters because building around an imagined offline queue would leave a shop exposed. The durable answer for a floor with chronic connectivity problems is a more reliable link to the shared database at the terminals, with Manual Entry covering the occasional gap.

Practical Guidance for a Flaky Floor

• Reconnect and punch first. For a brief blip, resume live punching; it carries the most detail.
• Use Manual Entry for what the outage forced you to miss. Type the day's real hours and pieces; the rate derives the other side.
• Let a supervisor use Log Actuals for precise times. The planner-side dialog can set the exact actual start and end when they matter.
• Do not assume a local queue. Nothing is buffered on the terminal, so capture the gap deliberately rather than waiting for a sync.
• Fix the link if drops are frequent. A reliable connection at the terminals is the real solution; Manual Entry is the safety net, not the plan.

Why This Still Serves the Plan

Even when a shift is captured partly by live taps and partly by Manual Entry, the plan gets what it needs: real actual start and end times, real daily hours, and real piece counts. Those are the inputs a reschedule works from, and they anchor downstream work to reality regardless of whether they arrived by tap or by keyboard. The loop from floor to plan closes either way; live capture just makes it richer and easier.

The Bottom Line

The EDGEBIC kiosk is a live, shared-database terminal with no offline mode and no local punch queue. When the network drops, punching pauses; the honest recovery is to reconnect and punch, or to record the missed work through Manual Entry or the planner's Log Actuals dialog. The record ends up accurate either way, and the plan still gets the real actual dates, hours, and pieces it needs for finite capacity scheduling. Knowing this lets a shop plan around connectivity honestly rather than trust a sync that is not there. See the full loop in the shop floor execution guide, or explore the platform at EDGEBIC.