Debugging an application

1. Use the "Inspector" and select the property "condition". If the "condition" of all objects is "_new: o.k.", then the constructor has executed without error (assuming the error wire is properly connected between all VIs).
2. Use the "Inspector" and have a look a the "event error" and "perioc error".
3. Use the "ClassUtilites.TestClass" (can also be compiled to the binary as "support file" and opened via the "File->Open" in the CS_start) and send a "Ping" to all objects that have inherited from the BaseProcess class. If the "Ping" works, then you know that the CLASSNAME.ProcCases method of the class CLASSNAME is at least properly executing.
4. In any case it might be useful to use the "ClassUtilites.TestClass" tool and check the attribute data of the malfunctioning objects for the parent classes, CSObj, CAEObj and BaseProcess. Have all commands been configured (look at the CAEObj attribute data)? Do all references look good (bad references have values like 0x00000000)?
5. When using pre-compiled binaries consider the following. LabVIEW code is significantly faster when being compiled into a binary. This means that the timing and the order of execution in multi-threaded environment might change slightly. This is important, if something has not been programmed in a thread safe way (= you have so called race conditions).
6. I do highly recommend not to ignore problems with compiled binaries by just using the whole CS in the development system. The timing might change later, due to another faster/slower PC or due to other processes in the Windows (remember Windows is not a real-time system and you have no guaranteed timing anyway).
7. Users of CS 3.10 on LabVIEW 8.20 might consider compiling the binary with debug options enabled and to debug the binary during runtime.