webvisu.jar is a single obfuscated viewer applet; the a.class and b.class files are its renamed classes, not a widget kit. CODESYS compiles your screens into element records the viewer draws, so you change buttons in the visualization editor and download the project. On a V3 runtime the browser client is HTML5 and needs no Java plugin at all.
You open webvisu.jar expecting a toolkit and find two files, a.class and b.class. That is the whole mystery solved: the jar is one viewer applet with obfuscated names. It carries no buttons, lamps or bars of its own. Your screens are not code at all. The visualization editor compiles them into element records (type, position, colours, text, variable links), and the viewer draws whatever the runtime sends it. So there is nothing to find, copy or reuse inside the jar. The levers you actually hold are the editor, the download, and the choice between the old Java applet client and the V3 HTML5 client. This page covers what the jar is, why buttons live in data, a worked element count for a screen at 6 ft, why the page can come up blank in a modern browser, and where PLCHandler fits if you want a client of your own.
What is inside webvisu.jar?
One viewer applet, obfuscated so its classes carry the short names a.class and b.class, and nothing else. There is no library of button, lamp or bar applets in the jar, and no separate file to copy into your own web page.
The two class files are one program that an obfuscator has renamed. Shortening class names to single letters is how an obfuscator writes compiled code. Those two files hold the drawing code for every element kind the visualization supports. The controller's web server hands the jar to the browser when the page opens, so there is nothing to install on the client PC. The only version worth tracking is the runtime version on the target.
Two rules follow. Do not decompile or extract the classes to harvest button code: the names are deliberately meaningless, and the code does something only when it is fed the data stream from the runtime. Do not move a jar between controllers either. One copied from a target running a different runtime version can start cleanly and still fail to read the visualization data, which is a fault that looks like nothing you did.
Why are there no applets for buttons, bars and lamps?
Because the visualization editor compiles every screen into element records (element type, position, size, colours, text and the variable each element is bound to). One viewer program draws whatever those records describe, so a button exists as data, never as an applet.
That design is why the jar never changes when your screen does. The button you draw in the editor becomes an entry in the screen's data, and so does its behaviour: which variable it writes, which method runs when it is pressed. The pressed action is project configuration too; calling a method from an HMI button with ST code shows what such an action looks like on the program side.
The workflow that follows is short: change the screen in the visualization editor, log in, download the project to the controller, reload the browser page. No Java tool, no compiler and no jar edit sits anywhere in that loop.
Example: a 32-element status screen read from 6 ft
Take a line-status screen for 4 stations, shown on a 1920 × 1080 panel, with operators standing about 6 ft away. Whether the screen carries 12 buttons, 10 lamps, 6 numeric fields and 4 text labels, or 300 elements, the browser loads the same two-class viewer. The runtime sends 32 element records for it to draw.
Here is the count, built from a standard editor palette:
| Element | Count | What its record carries |
|---|---|---|
| Push buttons (start, stop, acknowledge across 4 stations) | 12 | Position, size, colours, caption, the variable written |
| Lamps | 10 | Position, bound boolean, colour states |
| Numeric fields (cycle counters) | 6 | Position, format, bound variable |
| Static text labels | 4 | Position, text, font colour |
12 + 10 + 6 + 4 = 32 elements, so the controller holds 32 element records plus one reference naming the start visualization. The viewer that draws all of them is still the same two-class jar. Add a 33rd element tomorrow and the record count becomes 33 while the applet count stays at 1.
The 6 ft viewing distance sets the caption size. At the planning figure of 30 ft per inch of letter height, 6 ft calls for capitals of at least 0.2 in; the safer 20 ft per inch pushes that to 0.3 in. Size the button captions accordingly in the editor, because that is a data change, not a jar change.
The numbers worth checking are therefore the element count in the editor and the date of the last download, never a file listing inside the jar.
Why does the applet page stay blank in my browser?
Because the applet never starts: the major desktop browsers removed the Java plugin years ago. No current browser has run applets since 2017, so a modern PC shows an empty frame before your screen's elements are even requested.
Work down this order and stop at the first line that fails:
- The page HTML will not load at all. The fault is upstream of Java: check the controller's IP address and routing, then whether the runtime's web visualization option is enabled.
- The HTML loads but the applet frame stays empty. The browser has no plugin, and none of the current ones can load it. This is the normal result on any recent PC, not a fault in your project.
- A kept legacy browser reports a security or class-loading error. Read the Java console: unsigned applet content is blocked by default, so add a site exception for the controller's address instead of dropping the global security level.
- The viewer starts but reports missing data. The elements and bindings are the problem; take the checks in the next section.
Identify the generation before you plan around it: the programming system's Help > About dialog names the version. A V2.3-generation project runs the Java path. Its practical home is one dedicated PC with the old browser and plugin combination, cabled on its own with no route into the office network, because a PC carrying an old browser and an old plugin is exactly the machine you do not want exposed. A V3-generation project serves HTML5 with no jar and no plugin, so a blank page there is a settings fault, not a Java one.
Which settings decide what the viewer draws?
Three, in practice: the web visualization option enabled on the target, a start visualization selected, and a project download after your most recent edit. Miss any of the three and the browser shows an empty viewer or the previous version of the screen.
Match what you see to the cause:
- Empty viewer while the page HTML loads: the web visualization option is off, or no start visualization is set. In a V2.3 project that option sits with the target settings; in a V3 project it sits in the WebVisu object's settings.
- The old screen appears after an edit: the project was not downloaded since the change. Log in, download, reload. If the compiled visualization file refuses to transfer after a compile, work through fixing a WebVisu file that will not send after compile.
- Static graphics draw but the values stand frozen: the application is stopped or a variable link is broken. Check the run state first, then the variable names in the element configuration.
- One element missing, only on the web page: that element is not supported in the web visualization, so replace it with one that is; the programming system help lists which those are.
- Live bitmaps or images misbehave: setting NumCachedImages to 0 for live WebVisu bitmap updates covers exactly that case.
Is PLCHandler free, and where do you get it?
No: PLCHandler is a licensed programming interface obtained through the vendor's sales and distribution channel. The scope of what your licence allows comes in the terms you receive with it, not as a community download.
Its documented job is narrow and useful: the API lets an external client, such as a visualization or a service panel, read and write the controller's IEC 61131-3 variables and reach its online services. It is not a widget kit. It hands your program values; your program draws the buttons.
| You want | Path | What you maintain |
|---|---|---|
| The editor's screens in a browser | Built-in WebVisu, HTML5 on a V3 runtime | The project alone |
| Your own page layout and widgets | A server-side client speaking PLCHandler or a runtime protocol such as OPC UA or Modbus TCP, where licensed and enabled | The server side and its security |
| A desktop service tool that reads tags | PLCHandler | The client program |
For a web page you design yourself, the usual shape is a server-side component that talks to the controller and serves plain HTML and JavaScript to the browser; a guide to custom HTML5 PLC visualization with OPC UA and Modbus integration walks that pattern end to end. A V3 WebVisu can also host custom HTML5 controls written in JavaScript inside its own pages, which covers a widget the standard palette lacks without standing up a separate server.
What changes on the shop floor once you stop hunting for applets?
The work moves to the editor and the download: the machine screen becomes part of the project file under your revision control, a change goes out with a download and a page reload, and nobody maintains a jar.
Recommendation: Run the built-in HTML5 WebVisu wherever the runtime is V3-generation, and treat Java as a legacy condition, not a tool: keep one isolated PC for a V2.3 applet target only while a migration to V3 is scheduled, and build your own client with PLCHandler or a licensed runtime protocol only when the built-in screens genuinely cannot show operators what they need.
The decision, case by case:
- V3 project: edit in the visualization editor, download, open the browser URL. No plugin on any PC and nothing to look for in a jar.
- V2.3 project, applet page still needed: one PC, legacy browser plus plugin, a site exception for the controller's address, no route into the office network.
- Own layout and widgets: a server-side client over PLCHandler or a licensed runtime protocol, kept separate from the viewer.
- A board the PLC project should not own at all, such as a noticeboard or an andon board: that is a signage job. Live factory data display: signage or dashboard? sorts out the split, and our panel-mount signage displays are built to run such a board offline from their own media.
Questions
Can I edit the classes inside webvisu.jar to customize my buttons?
Editing them gets you nothing that reaches the page: the controller's web server serves its own jar to every browser that opens the visualization, so a modified copy on your PC never loads. The short names are obfuscator output, and the jar belongs with the runtime version that serves it. Change buttons in the visualization editor, where they are ordinary project data.
Can I copy webvisu.jar from another controller to get my page working?
A jar copied from a controller running a different runtime version can start and still fail to read the visualization data, which looks like an empty viewer with no error pointing at the cause. Take the jar from the target that serves the page, and label any spare copy with that target's runtime version.
Does the HTML5 WebVisu client work on a tablet browser?
On a V3-generation runtime, yes: the browser client is HTML5 and needs no plugin, so a tablet on the plant network can open the same page the shop PC uses. The Java applet path has no mobile equivalent, because mobile browsers never shipped the Java plugin. A tablet also carries the same buttons the shop PC sees, so decide deliberately which stations get write access.
Can one screen show data from several PLCs?
That is the job of a separate CODESYS HMI deployment, not of the web page: an HMI visualization connects to and displays data from multiple runtime instances at once. The browser page in this article is how a single runtime serves its own screens. Plan them as different projects, because the HMI deployment carries its own configuration.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.