A dashboard you tuned on one smart camera — widget positions, result labels, pass and fail colors — is worth an hour of work, and the next station wants the same screen. Rebuilding it by hand drifts: the second camera's widgets never quite match. The layout is not trapped in the device; it is a file in the camera's own storage, and copying it takes minutes over FTP. This guide walks the copy end to end: reach the file on the first camera, download it, upload it to the same path on the second, reload, verify, and fix the four failures that usually turn up.
What actually gets copied when you clone a dashboard?
The dashboard is rendered from a layout file stored in the camera's flash file system — on the common pattern /tffs0/http/user/hmi/layout.json — so cloning is a file copy, not a rebuild and not a parameter export.
On most on-device cameras, the page you see in the browser is served from a small web server inside the camera, and the screen geometry is a single text file. layout.json holds widget positions, labels, colors and the bindings to result variables. It holds display data only: the inspection job, its tools and its parameters sit in other files and travel separately. Some vendors also ship a documented export or clone function; when yours has one, use it, because it converts between layout formats when firmware changes. Where it does not, the file copy in the next two sections is the way fleets do it.
Scope check: if the screen you want to match lives in the PLC's HMI rather than on the camera's own page, that is a different job — what actually displays from a smart camera in a PLC HMI covers it. PC-based cells replicate the same idea at larger scale; the vision software dashboard guide shows monitoring screens that watch many cameras at once.
How do you reach the layout file on the first camera?
Put your PC on the camera's subnet, open an FTP client such as FileZilla, and log in with the FTP account the camera's manual documents — the host is the camera's IP address, and the layout waits under the web root of the flash file system.
- Give the PC an address in the camera's subnet. With the camera at 192.168.23.11, a PC at 192.168.23.50 and netmask 255.255.255.0 works for a direct cable.
- In the FTP client, enter the camera's IP as the host, add the FTP user name and password from the manual, and connect.
- In the Remote site field, type the flash root — /tffs0 on the common pattern — then step into /tffs0/http/user/hmi.
- Download layout.json into a folder named for the station, for example dashboards/station-1/.
- Open the downloaded file in a text editor. You should see JSON text and widget names you recognize; if it looks like binary or a settings blob, you are in the wrong directory.
How do you put the same layout on the second camera?
Connect to the second camera the same way, upload your saved layout.json into the identical directory, then restart the viewer or hard-refresh the browser — the second camera now renders the first camera's screen with no widget re-entry.
- FTP into the second camera and navigate to the same path as before, /tffs0/http/user/hmi on the pattern.
- Download that camera's current layout.json first and keep it as the rollback copy, named with the unit's serial number.
- Upload your master layout.json over it with the client set to binary transfer mode; ASCII mode rewrites line endings and can corrupt characters in the file.
- Restart the dashboard viewer as the manual describes, or press Ctrl+F5 in the browser for a cache-free reload.
- Park the same test part in front of both cameras and compare the two screens side by side.
After a fresh upload the camera may drop its first frames while its ready handshake settles; the ready-gate fix for smart cameras that miss first images explains that window, so verify with a part that arrives after the camera reports ready.
What must match between the two cameras?
Model, firmware version and image resolution must match: widget geometry is stored against the sensor's pixel grid, and a widget at x = 2,400 tuned on a 2592×1944 (5 MP) image lands 960 px past the right edge of a 1440×1080 (1.6 MP) image.
Identical sensors are the safe rule. A 5 MP sensor typically resolves 2592×1944 pixels (2592 × 1944 = 5,038,848, which is what 5 MP means) and a 1.6 MP sensor 1440×1080 (1,555,200 pixels). A widget parked at x = 2,400 px sits at 2400 / 2592 = 0.926 of the template's width — and at 2400 − 1440 = 960 px beyond the smaller image's right edge. Vertically the same arithmetic runs: y = 1,800 px is 1800 / 1944 = 0.926 down the template and 1800 − 1080 = 720 px below the bottom of a 1080-line image.
A widget stored as a fraction of width and height survives any resolution; one stored in raw pixels survives only a sensor of the same width. If your vendor's editor stores pixels, keep layouts inside one resolution class — the camera finder filters the shop's smart cameras by resolution so you can see which fleet members share a class.
Firmware is the second gate. A layout written by newer firmware can carry fields that an older reader skips or rejects, so keep both cameras on the same firmware version and put that version in the master file's name, for example layout_station1_v3.json.
How do you verify the copy took?
Load the second camera's dashboard in a fresh browser window and compare it widget for widget against the first with the same part in view; matching positions, labels and live values prove the file, the path and the reload all landed.
- File size and timestamp: the uploaded layout.json in the FTP listing must match the master's size in bytes.
- Screen match: widget count, positions, labels and colors identical on both cameras.
- Live bindings: a known test part shows the same values on both dashboards.
- Motion test: move the part and confirm camera 2's values follow. Static text matching proves nothing; moving values prove the bindings came across.
- Inspection intact: both cameras still run their own jobs and pass a good and a bad part.
Why does a copied layout come up wrong or blank?
Test four causes in order — wrong path, firmware or schema mismatch, corrupted transfer, stale browser cache — and the fault usually shows up inside ten minutes.
- Wrong path. The upload landed in a sibling directory. Check the FTP listing: the file's size in bytes must equal the master's.
- Firmware or schema mismatch. Newer firmware writes fields older firmware ignores or rejects. Align both cameras to the same firmware version, then copy again.
- Corrupted transfer. ASCII mode mangles bytes. Re-upload in binary and compare file sizes.
- Browser cache. Hard refresh with Ctrl+F5, open a private window, or restart the viewer service.
- Read-only file system. Some cameras mount configuration areas read-only until you enter a maintenance or service mode; switch modes as the manual directs, upload, then leave maintenance mode.
When the vendor publishes a documented export and import for dashboards, prefer that pair over raw file copy — it converts between layout formats instead of failing on them.
Which cameras should you standardize a dashboard across?
Standardize on one smart camera model and one firmware line per cell so every unit accepts the same file; the shop lists compact vision sensors and GigE smart cameras that run the inspection on the device, which is the class this workflow suits.
On-device inspection means the dashboard, the job and the file system all live in the camera, which is why a file copy works at all. Pick one template sensor per fleet size:
- Interface
- Fast Ethernet
- Resolution
- 5 MP
- Interface
- Fast Ethernet
- Resolution
- Up to 3 MP
- Interface
- GigE
- Resolution
- Up to 3 MP
The MV-SC3050XC-16M-ATN-H is a 5 MP color vision sensor with a 1/1.45" sensor format, global shutter and an M12 mount. The MV-SCB007EC-12S-WBN pairs 1.6 MP color resolution with a fixed 12 mm lens and manual focus. The LS-SMC-0063 reads 1.6 MP at 60 fps through a 16 mm lens over GigE.
For stations that need more pixels, the MV-SC5060XM-08M-WBN smart camera runs 6 MP mono over GigE through an 8 mm lens in an M12 mount.
- Interface
- GigE
- Resolution
- 6-10 MP
- Sensor format
- 1/2.4"
- Shutter
- Rolling
A shared screen is only half of fleet consistency; camera settings travel too. The runtime exposure control guide shows how to push exposure changes across a fleet without restarting drivers.
Rolling out a new cell? Choose the sensor class in the smart cameras category, then start the camera configurator if the station needs a lens, light and trigger as well. More fleet-level reading sits on the systems topic page.
Questions
Does the layout file carry the inspection program too?
No. layout.json describes only what the dashboard shows: widget positions, labels and which result variables they bind to. The inspection job, its tools and its parameters live in other files, and most vendors export them through their own backup or user-set function. Copy the two separately — dashboard first so the screen is right, then the job — and run a known good and bad part through both cameras before you call production ready.
Can I edit the layout file in a text editor?
Yes, when the file is plain JSON as layout.json is. Download the original first, change one thing at a time, and keep the structure valid — one missing comma stops the dashboard loading. Positions in image pixels move with resolution changes, so switch to fractions of image width and height if you plan to reuse the file across different sensors.
How do I roll a bad layout back?
Download the target camera's current layout.json before you overwrite anything and store it under a name that carries the unit's serial number. If an upload misbehaves, put that file back at the same path, reload the viewer, and the camera returns to its previous screen. One folder per line holding the master plus per-camera rollback copies is enough discipline for most fleets.
Should FTP stay switched on in production?
Treat it as a maintenance door. Use it on the engineering VLAN while you commission, then disable the camera's FTP service or restrict it at the switch. If the vendor's own software can push layout and job files, prefer that channel — it authenticates through your tool account and leaves fewer services listening on a production device.