Can SMLogix debug a Matrix 1020 project on a Matrix 1021?

A Matrix 1020 project downloaded into a Matrix 1021 raises a warning in SMLogix and a kernel-stop message on the controller, and the program then runs. A Matrix 1320 project downloaded into the same 1021 is harsher. The controller reports an abnormal kernel stop and writes it to the system alarm list, yet online debugging still works. A mismatched bench unit will run FBD logic and communications. It will not run physical I/O. The permanent method is to retarget the project to the hardware you have, test it, and switch it back before the final download.

Read the download messages before you trust the bench unit

The kernel executes the FBD program. When the kernel is stopped, the FBD program is stopped too, and nothing on the sheet updates. A kernel stop during a download is expected, because the runtime has to halt to replace the program. An abnormal kernel stop logged to system alarms is different. It means the runtime found a configuration it could not map onto the hardware. Across model families such as 1320 to 1021, that usually means I/O, display, or peripheral definitions that do not exist on the receiving unit.

Check: after the download, open online debug and watch a value that changes every scan, such as a counter or timer output. If it moves, the kernel stop message was confined to the load and the FBD is executing. If it is frozen, the kernel did not restart. Do not go further until it does.

Skip the quick fix of loading whatever Matrix is on the shelf

The usual night-shift shortcut is to push the target project into the nearest Matrix and accept the warning. It works just well enough to mislead you:

• All physical I/O is dead. Any logic that depends on a real input is never exercised.
• FBD execution and communications are stable in practice. Crashes have not been seen, but they are not ruled out. The runtime is operating outside the configuration it was built for.
• An abnormal kernel stop goes into the system alarm history each time you download. That history is useless for later fault-finding on that unit.
• A result that passes on a mismatched unit proves nothing about I/O mapping, scaling, or terminal assignment on the real model.

Use the mismatched download as a temporary restore only. It is fine for checking one block of logic or a Modbus exchange when nothing else is available. For anything you plan to ship, do the retarget procedure below.

Stop point: do not use the mismatched download in either of these cases. First, if the kernel stops at any time other than the download. Second, if the FBD does not resume after the load. In both cases the bench result is not valid.

Break every I/O point out onto the sheet

The retarget method works only if hardware I/O sits at the edge of the program and is not buried inside the logic. Build the project for the target model first. The example below uses a 1020.

1. Create or open the project with the controller type set to the target model, for example Matrix 1020.
2. Place every physical input and output that the application uses as its own element on the FBD sheet.
3. Wire each hardware input into the logic through a single connection point. Take each hardware output from a single connection point. Avoid scattering references to the same terminal across several blocks.
4. Record which terminal feeds which signal. You will need this list when you switch the type back.

Check: count the I/O elements on the sheet and compare the total with the terminal list of the target model. Every signal the application uses must appear once, at the boundary of the logic.

Retarget the project to the controller you actually have

In SMLogix, change the project's controller type to the model on your bench, for example a 1321. When the type changes, any I/O that does not exist on the new model is converted to Modbus variables. The logic stays intact. Only the binding changes, from a hardware terminal to a variable that the runtime can hold without hardware behind it. That is why the kernel no longer has anything to reject.

1. Save a copy of the project under a bench-specific name before you change anything.
2. Change the controller type to the bench model.
3. Review the converted points. Confirm that each former hardware I/O is now a variable and is still wired to the same place in the logic.
4. Compile and download to the bench unit.

Check: the download completes without the model-mismatch warning, and no abnormal kernel stop appears in the system alarms. If an abnormal stop still appears on a correctly matched type, the problem is inside the project and not the hardware mismatch. Stop and see the escalation note at the end.

Drive the logic from variables instead of terminals

You can skip the type change and replace the I/O by hand. Disconnect the real inputs and outputs and substitute variables. On a small project this takes a couple of minutes. It is the same result reached manually, and it suits engineers who keep one bench Matrix of a different model and always debug on it.

Once inputs are variables, you drive them yourself:

• Write input values from the SMLogix online debugger where the value is editable.
• Alternatively, write the converted points from a Modbus master or SCADA test tool, because the type change turned them into Modbus variables.
• Read outputs as variables, not as relay or transistor states.

Check: step each simulated input through its states and confirm that the matching output variable follows the logic. Test the Modbus or network exchange at the same time. Communications behave the same on the bench unit as on the target.

Draw the screens for the smaller display

Different Matrix models have different screen resolutions. A layout drawn for a smaller screen can always be drawn on a larger one, so a bench unit with the larger display can host the target's screens. The reverse does not work. If the target has the larger display, the bench unit cannot show the full layout.

• Target display smaller than bench: draw to the target's resolution and debug the screens on the bench.
• Target display larger than bench: debug the logic on the bench, and leave the screens for verification on the target.

Check: on the bench, confirm that every screen element sits inside the target's resolution area. Nothing should rely on the extra pixels of the larger bench display.

Switch the type back and load the production controller

This step turns the bench project into the production project. Most commissioning faults from this workflow come from skipping it or rushing it.

1. Open the bench copy and change the controller type back to the target model, for example Matrix 1020.
2. Walk your terminal list. Confirm that each signal is bound to its physical terminal again. Any point still shown as a Modbus variable must be reconnected to the correct terminal by hand.
3. Remove test writes, forced values, and bench-only Modbus test points that are not part of the application.
4. Compile. The build must be clean for the target type.
5. Download to the target Matrix. Expect the normal stop-for-download message only. There should be no model-mismatch warning and no abnormal kernel stop.
6. Clear or note the system alarm list after commissioning. Any later entry then means something real.

End-to-end check:

• The FBD is executing, with live values changing in debug.
• The system alarm list shows no abnormal kernel stop from this download.
• Each physical input changes its signal in the program when actuated at the terminal.
• Each output switches its field device when commanded.
• Screens display correctly at the target's native resolution.
• Communications to the master or SCADA read and write the expected points.

FAQ