using error clusters with sequencers

[dht]

Hi all - as a new comer to LV can anyone suggest the best way to pass the error flow through several frames of a sequencer. I've tried using sequencer locals - but it gets very messy if you need to add a frame. If you create a local from the error in cluster , then is acceptable to convert this from read to write , so that it effectively becomes an error out cluster? and can be read and wrote to in each frame. Or are there other issues?.
thanks dht

[GerdW]

Hello dht,

if you can make the dataflow dependent on your error cluster, then you don't need a sequence at all!
See the Labview manual on "dataflow concept".

Best regards,
GerdW

[dht]

hi GERDW ,.. thanks for your answer
Yes I agree , but the complexity of test measurements ( Im using the visa libraries and upwards of 30-40 calls to visa vi's) either means several frames of sequencer , or several sub vi's. Since the Sub vi' s would not be particularly re-useable I do not want to take this root. What Im trying to establish is the best way to use visa type read /writes over several frames of sequencer, whilst maintaining the error info flow.

thanks dht

[Dennis_Knutson]

Creating sbuVIs would certainly be a valid way to save diagram space and it seems that's all you're using the sequence structure for. But, if you really don't want to do that, much better than a sequence structure would be a state machine. There are a couple shipping examples that show how you do this but basically, it's a case structure inside a while loop. You have a mechanism such as a queue or enum define the next state to execute. In the case of the enum, inside each case, the next state is wired to a shift register input (right side of diagram). The shift register output (left side) is wired to the case statement's selector input. Things like error connections are also wired to a shift register so that you can pass the value from one state to the next. A state machine has all of the advantages of a sequence structure and not of the drawbacks (and there are many).