While LogixNG includes tools to translate Logix to LogixNG, they are not really native LogixNG definitions. This page describes Logix features and shows how they are implemented in LogixNG. While this page is an extension to Chapter 1, it includes LogixNG features that are documented in other chapters.
This is a simple Logix conditional that sets a turnout closed when a sensor is inactive and the block is not occupied based on its occupancy sensor.
A second conditional is used to the set the turnout thrown. The On Change to False cannot be used since the occupancy sensor can cause the false state when the lever sensor is changed to inactive and occupancy sensor is active.
This LogixNG conditional does the same process. A separate conditional is not needed since the else if provides the separate state checks.
The Logix Logical Expression is the if statement. It has three
modes: AND, OR, and Mixed. When Mixed
is selected, an Antecedent field is shown. The Antecedent field will contain a formula
such as R1 and R2.
The LogixNG If socket can have a single expression item, an
And expression, an Or expression, or a Digital Formula
expression. Except the for single item expression, the others provide a series of
child sockets for additional expressions. The Digital Formula contains a blank field that
can contain a formula such as E1 && E2. This is the LogixNG equivalent of the
antecedent field for Logix Mixed mode. Note: Formulas use Java syntax.
When the Logix Trigger box is checked, any change will cause the Logix expression state to be recalculated. When unchecked, changes will not be checked until a trigger event occurs.
When a LogixNG item expression is added, a Listen checkbox is enabled. This checkbox behaves the same as the trigger checkbox.
Logix has two options that control when the Actions will be executed:
Execute Actions on change of state only and Execute
Actions whenever triggered. For example, consider an expression such as
a or b. If both are true, the expression is true. If one becomes false, the
expression is still true. If the on change option is selected, the actions
are not executed.
When the If Then Else LogixNG action is created, the dialog has a drop down selection for Execute on change or Always execute. This provides the same functionality.
Logix can have true actions, false actions or actions based on a change of state or when triggered regardless of a true or false state. The descriptive text will depend on the Execute Actions setting.
LogixNG provides a Then socket and an Else socket. It does not have the third Logix option. The Then and Else sockets can have a single action item or the Many action. The Many action provides a series of child sockets for additional actions.
There are no compelling reasons to convert existing Logixs. They will continue to run and since Logix and LogixNG use common data such as sensors and turnouts, they can co-exist. Sometimes it might make sense to create a new LogixNG to make use of its features. The following is an alternate replacement for the orignal Logix and the first LogixNG approach.
This approach uses nested If Then Else actions. The first one checks the occupancy state. If occupied, there is no need to do anything else. The second one checks the sensor lever and then sets the turnout.
One of the challenges in learning to use LogixNG is understanding event processing. The most common event is when a table entry changes state and a LogixNG has been defined with the Listen option enabled. When event occurs, all of the ConditionalNGs that listen for an event for an object are invoked. Each ConditionalNG will execute its steps until it finishes. if there is more than one, the sequence is unpredictable. Logix conditionals, however run in the listed sequence within a Logix.
In this example, the occupancy sensor does not listen for change, but the lever sensor does. When the lever sensor changes state, the ConditionalNG starts. Since the occupancy sensor might not have changed, the if-then-else is defined with always execute. If the current occupancy sensor state is inactive, then the second if-then-else is checked. This one could be either always execute or execute on change since the lever sensor change started the process.
Logix supports indirect references to table entries using @mem_name. The memory variable contains the the name of a table entry, such as a sensor name, to be used when the conditional is invoked. This makes it possible to create generic logic that will use different objects when invoked.
For LogixNG dialogs that use a table entry, the normal tab is Direct which uses a drop down list for the table. The Memory tab is used to identify a memory variable that will contain the name of an entry in the actual table. There are several other indirect methods within LogixNG.
Logix has delayed actions for sensors and turnouts.
LogicNG has a general purpose Execute delayed action. The child action can be anything, including a Many which can have a list child actions. Note: The delayed actions will occur outside of the current ConditionalNG process.
Logix has a Conditional state variable. This is used to call a conditional that has no actions but returns true or false for its set of variables. This is useful when a group of variables need to be checked from multiple Logix conditionals.
The LogixNG Module provides this capability along with multiple module types including passing parameters to a module and having values returned.
A common Logix debugging tool is to use the script action.
LogixNG has the same script action. It also has a Log data action and an IDE style debugger that can do single step and breakpoint debugging.