{"id":3951,"date":"2026-10-26T14:40:59","date_gmt":"2026-10-27T02:40:59","guid":{"rendered":"https:\/\/footworklab.net\/?p=3951"},"modified":"2026-10-26T14:40:59","modified_gmt":"2026-10-27T02:40:59","slug":"foot-scanner-machine-three-subsystems","status":"publish","type":"post","link":"https:\/\/footworklab.net\/fr\/news\/3951\/","title":{"rendered":"A Foot Scanner Machine Is Three Subsystems in One Cabinet: What Each One Contributes"},"content":{"rendered":"
\n

About the author<\/strong> \u2014 FOOTWORK LAB is a manufacturer of foot assessment equipment and custom orthotic insoles, based in Ruichang, Jiangxi Province, China. Founded in 2014, with its own production plant since 2018. Certified to European Union and ISO quality system standards. See the factory<\/a> or view certification<\/a>.<\/p>\n<\/div>\n

A foot scanner machine is sold as one product and fails as three, which is why two buyers can describe the same unit as excellent and disappointing without either of them being wrong.<\/strong> The cabinet contains a capture layer, a computation layer and a reporting layer, and each has its own failure modes, its own upgrade path and its own questions worth asking before a purchase.<\/p>\n

Most comparison documents flatten the three into a feature list, and a feature list cannot tell you which layer will let you down. A clinic that loses confidence in a machine usually loses it at the reporting stage \u2014 the records exist but cannot be shown to anyone \u2014 while a workshop usually loses time at the capture stage, where a stubborn sensor turns a ten-minute appointment into twenty.<\/p>\n

This article takes the three layers apart in the order a buyer meets them, then shows how to read a listing, a demonstration and a quotation with the layers separated. We build plantar pressure systems, so the description of each layer follows the way our own units are put together rather than a generic architecture.<\/p>\n

Capture, computation, reporting<\/h2>\n

The capture layer is everything that touches the physical world: the surface the client stands or walks on, the sensors under it, the cameras that record posture, and the calibration that makes their output comparable over time. Its quality is measured in repeatability, not in resolution alone \u2014 a stable record that can be reproduced next visit is worth more than a dense one that cannot.<\/p>\n

The computation layer turns a raw signal into something structured: regions, zones, timings, phases, symmetry, a comparison with a previous record. This is software, and software is where suppliers differ most, because the same capture hardware can sit under two very different analysis packages depending on who wrote the code.<\/p>\n

The reporting layer is the part the client actually sees: a screen during the appointment, a printed or exported summary afterwards. It is the layer most often neglected in procurement and most often decisive in practice, because a report that cannot be explained in the room becomes a document nobody opens again.<\/p>\n

Separating the three is not pedantry. It tells you which questions belong to the supplier’s hardware team, which to its software team, and which to the person who will actually stand in front of the client next Tuesday.<\/p>\n

It is also worth noting which layer a supplier’s own staff understand best. Ask a salesperson a reporting question and a technical question in the same call and listen to which answer arrives with detail and which arrives with a brochure reference. The asymmetry is usually an accurate map of where the product was designed and where it was assembled.<\/p>\n

The capture layer: sensors, cameras and the surface underfoot<\/h2>\n

Pressure capture depends on a sensing surface, its calibration and the way load is transferred to it. Two machines with similar surfaces can behave differently the moment a client walks rather than stands, because walking introduces timing, and timing exposes sampling behaviour that static capture never tests.<\/p>\n

Posture capture depends on cameras and their geometry. A single viewpoint records a projection; multiple viewpoints reconstruct a volume. The practical question is not which is more advanced but whether the resulting image is stable enough to compare across visits \u2014 lighting, distance and client position all move the result, and a protocol is what keeps them still.<\/p>\n

The third element of the capture layer is the physical setting: the plate’s surround, the walkway if there is one, the height of the surface relative to the floor. Clients modify their walking when a surface looks unfamiliar, and a machine that cannot be approached naturally records a slightly different person from the one who walked in.<\/p>\n

Ask about calibration in plain terms: how often, by whom, with what reference, and what happens to records taken before and after. A supplier who can describe the process has usually thought about comparability; one who answers with an adjective has usually not.<\/p>\n

There is also a maintenance dimension to the capture layer that listings rarely mention. Surfaces wear, sensor elements fail, and camera mounts move. A machine that cannot report its own condition will be discovered to be out of specification by a client rather than by an operator, and that discovery is the expensive kind.<\/p>\n

\"F2
FOOTWORK LAB F2 plantar pressure system. Product photography of our own output \u2014 specifications are confirmed in writing before an order.<\/figcaption><\/figure>\n

The computation layer: what software does with a raw signal<\/h2>\n

Raw pressure data is a grid of numbers changing over time. Turning it into regions, peaks, paths and phases is a series of choices \u2014 where boundaries are drawn, how much smoothing is applied, which frames count as a step. Two packages can disagree about the same foot without either being wrong, because they made different choices.<\/p>\n

For a buyer, the useful question is whether those choices are visible. A package that shows its regions and lets you adjust them is a tool; a package that hides them behind a single score is an oracle. Clinics generally want the first, because the conversation with the client needs the intermediate steps, not just the verdict.<\/p>\n

The second useful question is what the software remembers. Records that are stored with their context \u2014 client, date, shoe, protocol \u2014 can be compared; records that are stored as images cannot. This is the difference between a five-year asset and a five-month novelty, and it is decided in the software, not in the cabinet.<\/p>\n

The third is ownership of the roadmap. A supplier who writes its own analysis software can tell you what is coming and can act on a request. A supplier who resells someone else’s software can only forward the message, and the answer arrives late or not at all.<\/p>\n

It is worth asking whether the analysis can be exported as data rather than as an image. A table of regional values can be compared, plotted and archived; a picture can only be looked at. The difference matters when a clinic wants to show change over a year without re-running every capture.<\/p>\n

The reporting layer: the only part the client sees<\/h2>\n

A report has three audiences: the professional who interprets it, the client who receives it, and the colleague who reads it six months later. A layout that serves one usually underserves the others, and the compromise is a design decision worth examining before purchase.<\/p>\n

For the client, clarity beats completeness. One image with a clear footprint and a short explanation is more useful than four screens of numbers, because the client is trying to understand a sentence about their feet, not audit the measurement. Reports that over-deliver on data and under-deliver on language end up unread.<\/p>\n

For the professional, the report needs the raw material to reason with: zones, comparisons, timing where relevant. For the colleague reading later, it needs identifiers \u2014 date, protocol, shoe, the conditions of capture \u2014 because a record without context cannot be compared and is therefore only an illustration.<\/p>\n

Ask to see a report from a real session, not a demonstration file. Demonstration files are chosen for how they look; real ones show whether the layout survives an awkward capture, and whether the language holds up when the finding is unremarkable.<\/p>\n

Language is the last detail of the reporting layer and the first thing a client notices. A report written in the wrong language, or in a register that sounds like a laboratory, becomes something handed over rather than discussed, and a report that is handed over is rarely read twice.<\/p>\n

\"F2
FOOTWORK LAB F2 plantar pressure system. Product photography of our own output \u2014 specifications are confirmed in writing before an order.<\/figcaption><\/figure>\n

Reading a listing with the three layers in mind<\/h2>\n

A typical listing mixes the layers in one paragraph, which is why it reads as a wall of claims. Sort every sentence into capture, computation or reporting as you read, and the document reorganises itself: hardware statements cluster at the top, software claims in the middle, and output formats at the end, often with the least detail.<\/p>\n

Then notice what is missing. Listings rarely describe calibration, rarely describe how records are stored, and rarely describe what happens when a capture fails. Those three absences are more informative than any feature, because they are the parts a buyer discovers only after delivery.<\/p>\n

The next pass is about fit rather than quality. A strong capture layer with a weak reporting layer suits a research setting where the operator will do the analysis; a modest capture layer with an excellent reporting layer suits a retail or clinic setting where the conversation matters more than the data depth. Neither is better; they are different products.<\/p>\n

Finally, price the layers separately in your own notes. When two quotations differ, knowing which layer the difference sits in turns a negotiation into a decision, and prevents the common outcome where a buyer pays for capture depth and never uses it.<\/p>\n

It also helps to write down which layer each of your questions belongs to before a call. Suppliers answer questions in the order they are asked, and a buyer who leads with reporting questions learns sooner whether the software is theirs or someone else’s.<\/p>\n

Where demonstrations hide the seams<\/h2>\n

A demonstration is a controlled performance: the room is set, the operator is expert, the client is cooperative. The layers never conflict because nothing is stressed. That is precisely why a demonstration should be designed to stress them, and why the buyer should bring the awkward case rather than accept the easy one.<\/p>\n

Bring a client who shifts position, wear the shoes your clients actually wear, and ask for the record to be produced twice. Compare the two records: if the machine and the protocol are stable, the difference will be small and explainable; if not, you have found the seam between capture and computation before you have paid for it.<\/p>\n

Then ask for an export. Take a record out of the system in whatever format the supplier offers and open it on a computer that has none of the supplier’s software. What survives is what belongs to you; what does not survive is a dependency, and dependencies should be priced.<\/p>\n

And ask who to call when a capture fails at four in the afternoon. Ours is a support group with an engineer reachable directly and remote assistance available, because the failure that matters is the one that happens during an appointment. Whatever the answer, make sure it has a time attached to it rather than a promise.<\/p>\n

Insist on seeing the machine with a client rather than a colleague. Colleagues stand still and cooperate; clients shift, ask questions and arrive in the shoes they wore to work. The difference between those two performances is the whole reason a demonstration exists.<\/p>\n

\"F2
FOOTWORK LAB F2 plantar pressure system. Product photography of our own output \u2014 specifications are confirmed in writing before an order.<\/figcaption><\/figure>\n

Questions that map to each layer<\/h2>\n

For capture: how is the surface calibrated, how often, and what protocol keeps records comparable across operators? What happens when a client stands on the edge of the plate or moves mid-capture? Is the physical setting something the room can accommodate without rebuilding?<\/p>\n

For computation: which choices does the software make on your behalf, and can they be inspected or changed? Where are records stored, how are they named, and how are they found again a year later? Can a record leave the system in a format another program can open?<\/p>\n

For reporting: may I see a report from a real session, including an unremarkable one? Which fields are printed, and can the language be set for the market you sell into? Who controls the template when the clinic wants to change it?<\/p>\n

Six questions per layer is enough to separate a considered supplier from an assembled one, and the answers are more useful than any comparison table. The machine is one purchase; the three layers are three relationships, and only one of them ends at delivery.<\/p>\n

The last question belongs to the buyer rather than the supplier: which layer will your staff actually use? A clinic with a fifteen-minute slot will use the reporting layer and skim the computation layer; a lab will do the opposite. Buying for the layer that will be used is the cheapest form of specification discipline.<\/p>\n

Frequently asked questions<\/h2>\n
\n

What does a foot scanner machine actually measure?<\/h3>\n

It records pressure distribution under the foot and, in many systems, posture or alignment via cameras. The output is a measurement: a map, a series of frames, a set of images. Interpretation stays with the professional who reads it.<\/p>\n

Is a machine with more sensors automatically better?<\/h3>\n

No. Repeatability and calibration matter more than sensor count. A stable record that can be reproduced on the next visit is more useful than a dense record that cannot be compared.<\/p>\n

Can I use one machine for both static and dynamic capture?<\/h3>\n

Often yes, but the workflow differs: dynamic capture needs a walking path and practice passes, static capture needs a repeatable standing position. Ask to see both performed in the room you will actually use.<\/p>\n

Do reports come in a format I can share with clients?<\/h3>\n

That is a reporting-layer question and worth asking directly. Ask for an export you can open without the supplier’s software, and confirm whether the report language can be set for your market.<\/p>\n

How often does calibration need to be repeated?<\/h3>\n

It depends on the sensing surface and how heavily the machine is used. Ask the supplier to describe the process, the reference used, and what happens to records taken before and after a calibration change.<\/p>\n

What support is included after delivery?<\/h3>\n

With our systems, a dedicated WhatsApp group with an engineer, remote assistance, and software updates delivered over the air to connected units. Machines carry a twelve-month warranty against non-human damage.<\/p>\n

Can the system be upgraded later?<\/h3>\n

That depends on which layer the upgrade touches. Software and reporting changes can often be delivered remotely; capture-layer changes usually mean hardware. Ask which layers the supplier controls before you plan an upgrade path.<\/p>\n<\/div>\n

What we would do next<\/h2>\n

Before the next demonstration, write the three layers on a page and put two questions under each. Bring the awkward client, ask for a record twice, and ask for an export. The product pages for our F2 and FMP systems describe how the capture, computation and reporting layers are assembled in our own units.<\/p>\n

If the decision is between a fixed plate and a walking platform, the comparison article on pressure plates and gait treadmills continues the same reasoning one layer up.<\/p>\n

This article is intended for professional and educational reference. It is not medical advice. Foot assessment equipment produces measurements and images; clinical interpretation and any decision about care remain the responsibility of a qualified professional. Certification scope is limited to the documentation we hold: European Union certification and ISO quality system certification.<\/em><\/p>\n

\n

Related reading<\/h2>\n