Hi Robert,
generally it looks like better than the 1st sample but there are some things which are possible to improve.
First of all, you create two queues with the same name and the same datatype (sollwert), but with another tabbing order within the cluster. (tabbing order is very important for clusters)
However, in this case you will get an error because you want to create two queues which have the same name but different datatypes.
The argument regarding the phase of the signal is in case of queues and timed loops not directly correct, because queues will be used for synchronization with data exchange
In LabVIEW are two mechanisms for synchronization with data exchange (queues, notifiers) and three mechanisms for simple synchronization (occurrences, semaphores, rendezvous). However, in your case it would be better to disable the attribute "Maintain Original Phase" in all timed loops with the deqeue element function.
The other thing is, I think it makes no sense to read out of the same queue (regarding your old program) in two different subVIs. If your final application needs this, it is ok but to my mind it makes not really sense.
One cool thing you did is that you have limited the queue size to 50. On the one hand it is very well but on the other hand, this thing could make big problems. Because the queue does not overwrite the oldest sample as the real time fifo do, therefore you have to include a special management for this kind of situation if you do not want that the application stops in this case.
Furthermore, I saw in your block diagram documentation that you want to realize a software emergency stop. For this case, I would suggest, to give those timed loops which are involved the highest priorities.
BR,
ThSa
Message Edited by ThSa on 08-24-2006 04:15 PM