Panic mode has given one of the best practical solutions for you - trim down the executing code as he suggests (using enable bits for JSR's) to make it easier to debug.
------------------------------
Something to look for though: On many Logix processors (I haven't used the 1200 so don't know for sure on that one) there are "TEST" operation modes - some where you step through one line of code (look for "Test Single Step" in the help files), and others where you step through one scan of code (look for "Continuous Scan Test" in the help files).
Another option: If most of your code is working, the "Test" or "UnTest" edits can be useful for observing the effect of a new change without making it permanent. Unfortunately, I'm fairly certain that the MicroLogix 1200 does not have this functionality - I don't think any of the MicroLogix processors support on-line editing. You can get something like this functionality by using Panic mode's suggestion here too though - add an extra "enable logic" bit at the start of a rung. You can toggle this bit to "test" or "untest" any edits.
All that said - SAFETY FIRST! I don't know where you are in the debug of your code - don't run any test that you don't KNOW is safe.
Two methods for debugging without using the real-world I/O are to:
Purchase the RSEmulate 500 package and test. Critics will tell you (they have good reason) that it is fairly expensive, doesn't have all the functionality that you might want (like on-line editing), and has a somewhat clunky interface.
Write code so that the real world inputs and outputs are not used - use binary or integer files instead and watch it run. When you are happy with the execution, you can then map your inputs and outputs (ie: real world input triggers your "binary" or "integer" input / your "binary" or "integer" outputs trigger your real world outputs) to make the real process run.
Good luck,
Marc