Simply replacing them with vi's with the same code in it doesn't add much. If you named the while loop (show label, and put a comprehensive text in it) you don't gain anything.
I usually end up with parallel loops that need a bit more. I use a structure with user event, where messages are posted, and dynamic vi's can register to them. For instance, a view of the data might register to the "new data" event, send by the DAQ routine. All dynamic vi's respond to the "quit application" event. This structure enables me to do very advanced UI stuff, like complicated resizing of subvi's in sub panels.
The benifit of this (above parallel while loops) is that you can easily reuse vi's in new applications. Although I admit it's also easy to delete or copy some whileloops. Also, I can change the DAQ loop with any other vi (for instance a daq simulation), or change the data viewer for a debug view. This can be done even at runtime. Simply stop the daq vi and start the simultation vi. I can even develop any debug vi, and start it in my running application. We even do this with executables. Parts of the executable can be replaced without stopping the application. For instance, we can add or update a dynamic view, without stopping the daq and log parts.
If you have an application, I wouldn't change it. We have quit a few lagacy application (LV4 or 5, much less options for advanced architecture). We just keep them like they are.
Making an applcation with parallel loops does force you to think a bit more about the internal data structure. In one vi, you can use locals to communicate between loops. You could use globals when you put the loops in sub vi's, but you really shouldn't. You should use a buffer, or ini file or something. If you do this properly, you think about this before building. If you have a finished applcation, you might as well keep it like that. Unless you have to support it for a long time, have to add a lot to it, or if it's not working properly.
Regards,
Wiebe.
