Embed an external WebVisu in your CODESYS WebVisu

How do you display an external WebVisu inside your own WebVisu?

Use the Web Browser visualization element. It draws a boxed area on your page and loads the external WebVisu address inside it. It carried the external view inside the existing interface on CODESYS V3.5.15.0, and it replaces the hand-written iframe you were looking for.

The visualization editor has no iframe element in its palette. Its control for web content is the Web Browser element, and that element is the whole answer here. Place it like any rectangle, and the area it covers shows a web page. Your frame, menus and buttons stay around the box, and the remote view lives inside it.

WebVisu renders a project visualization in a browser without HTML, CSS or JavaScript of your own. The Web Browser element adds one area of outside web content to such a page, and an external WebVisu is exactly that.

What do you need before adding the Web Browser element?

Three things: the address that already opens the external WebVisu in a browser tab, a client machine for the master page that can reach that address, and a CODESYS V3.5 project with room on the page for the box.

• The external address, exactly as it opens today on a PC that reaches the remote controller.
• The client that will display the master page, office PC or floor panel. It must reach the same address; the blank-box section below gives the test.
• Your CODESYS V3.5 project, with the visualization that will carry the box. On a release other than the one this was confirmed on, look for the element by name in the palette.
• The remote controller, serving its own WebVisu the whole time the master page runs. The box shows what that controller serves, and nothing while it is down.

One safety point, because it decides who gets access: assume the embedded page takes input the way a browser tab does, so anyone who can open the master page can operate the remote machine. Protect the master page the way embedding a remote machine screen safely lays out.

What are the steps to embed the external WebVisu?

Six steps from open project to running page: open the target visualization, place the Web Browser element, draw its area, enter the address, set the size, then compile, download and run.

1. Open the visualization that will carry the box, in the visualization editor.
2. In the element palette, pick Web Browser and draw its rectangle on the page, the same way you place a button.
3. Open the element's properties and enter the external WebVisu address in the field that holds the page address. Use the exact string that opens the external view in a browser tab, scheme included.
4. Size the rectangle to the area the sizing section below settles: the fraction of the page you give the box is the fraction the remote text keeps.
5. Save, compile and download the project to the controller. If the send fails here, fixing a WebVisu file that will not send after compile covers the usual causes.
6. Open the master WebVisu on the client the operators use, then run the checks below.

The confirmation covered the element and the result, and named no property label, so go by the field that holds a page address.

How small can the embedded area be and still stay readable?

Readable distance shrinks by the same fraction as the box, so plan 30 ft of viewing distance per inch of capital height where the reader can dwell, and 20 ft per inch for a fast glance.

The first figure is the FHWA planning number for sign text; the second is the safer rule when an operator must catch text moving past. Line spacing at 1.7 x capital height keeps lines apart at any scale. Work the box in four lines:

1. Measure the operator distance D, in feet.
2. Minimum capital height on the physical screen: D ÷ 20 for a glance, D ÷ 30 where the reader can dwell, in inches.
3. Convert that height to pixels with the panel's pixel pitch; a 22 in panel at 1920 x 1080 has a pitch near 0.01 in per pixel.
4. The box scale s must give remote capital height at design size x s at or above the minimum from line 2. If the layout cannot give that scale, raise the remote text; the operator distance will not move.

What does the sizing look like in a worked example?

A packing line runs the master WebVisu full screen at 1920 x 1080 on a 22 in panel, the operator stands 10 ft away, and the second machine's view goes into a 960 x 540 box in the corner.

• Minimum capital height: 10 ft ÷ 20 ft per inch = 0.5 in on the panel.
• Panel geometry: 22 in diagonal in 16:9 gives 19.2 in of width across 1920 px, so one pixel is 19.2 ÷ 1920 = 0.01 in. The remote view was drawn with 50 px capitals, which is 50 x 0.01 = 0.5 in at full screen. Full screen meets the rule exactly.
• The box: 960 x 540 is half of 1920 x 1080 in each direction, so the scale is 0.5. Capitals render at 50 px x 0.5 = 25 px, which is 0.25 in. Readable distance: 0.25 in x 20 ft per inch = 5 ft. The operator stands at 10 ft, so the half-size box fails.
• Fix it in the remote view: redraw the status text at 100 px. In the same half box that renders as 100 px x 0.5 = 50 px = 0.5 in, and 0.5 in x 20 ft per inch = 10 ft, exactly the operator distance. Line pitch at 1.7 x capital height: 1.7 x 100 px = 170 px in the drawing, 85 px on screen.
• Same box on a maintenance panel at the machine, read from 3 ft: the rule needs 3 ÷ 20 = 0.15 in, and the box delivers 0.25 in, good for 5 ft. Passes with the original 50 px text.

Decision for each case: at 10 ft, the remote text grows to 100 px or the view gets the full screen; at 3 ft, the half-size box stands as drawn. If the combined page feeds a shared floor screen, the placement rules in andon boards: where a small screen fits settle where that screen hangs.

Recommendation: embed with the Web Browser element whenever a second WebVisu must share the page, and size the box before drawing anything: at a 10 ft operator distance the half-page box needs 100 px capitals in the remote view, and at 3 ft the original 50 px text already passes.

How do you check the embedded view works?

Run the WebVisu on the operator's client and confirm three things in one pass: the external view appears inside the box, your own frame and buttons keep their places around it, and the remote values in the box update live.

• Position: your menus and frame hold their coordinates, and the remote view sits inside the rectangle you drew.
• Liveness: watch a counter, clock or cycle count in the remote view move, which proves the box carries live content.
• Input: press one harmless control inside the box and watch its feedback, on the machine itself if you can see it.
• Images that must refresh live inside a WebVisu follow the caching rules in NumCachedImages 0 for live WebVisu bitmap updates.

Why does the embedded box stay blank on the shop floor?

Open the same address in a browser on the machine that displays the master page. If it fails there too, the problem is reachability. If it loads there, the string inside the element is wrong.

• Address fails on that client too: reachability. Check the route and any firewall between that client and the remote controller, and retest with the numeric form of the address if the entry uses a name. The same diagnosis applies to any package that embeds web content: test the address in a plain browser on the displaying machine, then work outward through the route.
• Address loads on that client: the entry in the element is the fault. Reopen the properties and compare the string character by character with the working one, scheme included.
• External view fills the window and your frame is gone: the address is being opened as the page itself instead of inside the element. Your own visualization must be what the client starts, and the external address belongs only in the Web Browser element.
• Editor window goes dark while you place the element: fixing an embedded browser editor black screen covers that fault before you touch the project.

Questions