Configuring LogicLab 4 Projects for New LD Features

New LogicLab 4 features become selectable after a legacy .ppjs project is saved as .plcprj and reopened. That conversion changes the project container, but it does not convert Ladder Diagram programs created with the LogicLab 3 editor to the new LD editing style. Commission the project by checking the format, target, LD behavior, variable declarations, and selected function-block instance in that order.

Where does the project-opening path stop?

Follow the project data path first: LogicLab 4 opens the project container, loads the target configuration, and then selects the editor behavior stored for each program. A legacy project can therefore open and compile while the option for new functionality remains unavailable.

The first check is the project extension shown by the open project. Do not start troubleshooting individual ladder objects until the file is confirmed as .plcprj.

Which project format should be selected?

The two extensions control different project-format paths. Legacy LogicLab 3 projects use .ppjs; the new format is .plcprj. LogicLab 4 permits the latter to use its new project features.

The .plcprj format is compatible with all targets described here. For targets before XTarget 12.0, LogicLab 4 uses configuration files from older LogicLab versions; this is why those selections still create .ppjs projects by default. The default extension reflects the configuration path, not a target incompatibility.

Check that the converted file still names the required target and can be opened normally. A changed extension alone is not the final commissioning result; the target association must remain correct.

How is a legacy project converted without changing its target?

1. Open the existing .ppjs project in LogicLab 4.
2. Record the selected target so the same target can be checked after conversion.
3. Use Save As and select the .plcprj extension.
4. Close the project. Reopen the newly saved .plcprj file rather than continuing in an uncertain in-memory state.
5. Open the project options and activate the required new functionality.
6. Build the project and review each reported name or ladder-structure error before changing logic.

For a new project that must use a target other than XTarget 12.0, first let LogicLab create its default .ppjs file. Then apply the same Save As and reopen sequence. Changing the project format is the conversion step; selecting a different target is neither required nor a substitute for it.

The check is a clean reopen of the .plcprj file with the original target still selected and the project-level feature controls available.

Why do old Ladder Diagrams still lack the new controls?

Project-container conversion does not rewrite an LD program created with the old editor. Those programs continue to use the old Ladder style, so new controls such as the newer insertion-point functions remain unavailable inside them. A native LogicLab 4 LD program can expose the new controls even when a converted legacy LD in the same engineering workflow does not.

If full use of the new LD editor is the design requirement, create the program in the LogicLab 4 style and transfer logic deliberately. Do not treat saving the outer project as a conversion of every internal graphical program.

The check is visual and functional: insertion-point commands must operate in a native LogicLab 4 LD, while a legacy LD is expected to retain the older editing model.

How should coils be handled in converted LD networks?

Every logical LD branch needs at least one terminating coil. On affected legacy networks, particularly networks that also contain function blocks, the first coil created may resist deletion while later parallel coils can be removed. Attempts to attach another coil to a function block away from the main network have also caused the IDE to crash.

Use a disposable Boolean termination rather than forcing a structural edit that the legacy diagram cannot represent safely:

1. Identify each logical branch that lacks a valid terminating coil.
2. Declare a placeholder variable of type BOOL.
3. Place that variable as the termination coil on branches that need a structural endpoint but no application output.
4. Retain the first coil if the legacy editor will not delete it; rename or redirect it to the placeholder rather than repeatedly attempting the failing edit.
5. Build after each network change so the edit that introduces an error remains identifiable.
6. Save, close, and reopen the project to confirm that the diagram persists without editor damage.

The placeholder coil satisfies the LD branch structure; it should not be reused as an application command whose state has another meaning. Give it a name that marks it as a nonfunctional termination according to the project naming convention.

The check is a successful build with every branch visibly terminated and no need to attach a secondary coil directly to a function-block object.

Why does renaming an FB instance produce a build error?

The graphical diagram and variable list do not currently perform automatic refactoring. Renaming a function-block instance on the LD does not rename its declaration in the variable list, and changing the declaration does not rename the object on the diagram. The two text identifiers then address different symbols, so compilation fails until they match.

The requested refactoring capability was recorded as enhancement ticket #LL1546. Until that function exists in the installed environment, treat every instance rename as a two-location transaction:

1. Record the original instance name and the intended new name.
2. Rename the instance on the graphical diagram.
3. Open the applicable variable list and apply the identical name to the declaration.
4. Search the project for the original identifier and resolve every remaining intended reference.
5. Build immediately and use the compiler location to find any missed declaration or use.

This is not limited to function blocks: a variable created from an LD can appear in the variable list, yet later edits on either side can lose name alignment. Avoid making a batch of graphical renames before updating declarations because the resulting compiler list will no longer identify one isolated change.

The check is a project search with no unintended occurrence of the old identifier, followed by a build with no unresolved or mismatched variable name.

How is the correct FB instance selected during debug?

A function-block definition can execute through multiple instances. Opening its source only identifies the shared implementation; useful live values require an instance context. LogicLab 4 supplies that context when the debug request reaches an internal function-block variable or an instantiated graphical object.

Use the watch path when individual internal values are the main diagnostic target. Use the graphical path when power flow or related object states inside an LD or another graphical function-block source must be observed together. If two programs call the same FB definition, select the required instance at the prompt; otherwise the shared source view alone does not identify which execution context is being inspected.

End-to-end verification starts from the converted .plcprj file: confirm the original target, activate the required project features, build with synchronized instance names, enter debug, double-click the required FB object, select its instance, and verify that the graphical values change with that instance while another instance follows its own inputs.

FAQ