Ugly is a mild word for that!
I do not have the Motion toolkit and apparently the error comes from one of those VIs. Try to narrow it down to a specific subVI. The error message should give an idea of the source of the error. Since the error handlers are the last VIs to run, it is difficult to tell when the error first occurs. I would place a bunch of error out indicators at various places in the code near where you suspect the error source. It may also be helpful to place indicators on other data lines near that code to see what is going on. Probes may also be used.
As far as the code itself, it violates almost all the good LabVIEW coding guidelines.
1. Having multiple event structures is almost always a bad idea. Having the same event in both is very bad. Having an event for a control with no label works, but it is extremely difficult to tell what the event does. How would you ever figure it out if several controls had no labels?
2. Sequence structures disrupt dataflow and have many other problems. They are rarely needed. The stacked sequence structure has no place in LV programs.
3. Local variables are slow, make copies of the data, and may lead to race conditions. There is really only one situation where they are appropriate and that does not appear to occur in your program. Use wires.
4. A state machine is often a good alternative to code which was originally written using sequence structures.
5. A diagram should be no larger than one screen. Create subVIs to perform repeated tasks such as the code linked to Relax 1, 2, and 3.
6. The use of parallel loops to separate things like data acquisition, motion, and saving to file is good. Look at the Produce/Consumer templates and design patterns for examples.
Lynn
