USB switch used in consumer loop giving errors

[Moseq]

Hello All,

I have created producer with multiple consumers to measure pressure data. I put the USB switch with VISA into Consumer loop, thought that if DAQ is determining time rate in whole application, consumer and switch loop WILL run in parallel. That is correct, those loops are running for x thousand cycles in parallel, but after that VISA gets an error in VISA Write, Switch consumer loop is slowing down significantly and physical USB switch is not working (communication is closed in case of error in VISA Write). I tried different variations, tried to increase timeout in VISA Open, slowing down producer loop to have enough data in queue, etc and I am out of ideas. The only thing that lasted is to put all functions Switch consumer loop into Producer loop to have no issues with queue. Another thing is maybe create 2nd producer with this switch, but how I can sync both producer loops then when 1st producer with DAQ is determining time?

Thank you for your time,

Moseq

[Bob_Schor]

I don't have 16 monitors arranged in a 4 x 4 configuration, so I cannot easily view your enormous Block Diagram!  If you used sub-VIs appropriately, you should be able to fit this onto a single Laptop screen.

I am concerned about a "Producer with multiple Consumers" -- sounds like a Design Flaw, but as I cannot easily see your Design, I'm not sure what you are doing (nor where you are doing it).

It would help (me) to have a slightly better description of what you are doing, as well as what hardware you are using.  What is the "USB Switch", and what does it do?  What (in broad terms) is supposed to be happening in the Producer Loop?  What happens in the Consumer Looop?  Why are there multiple Consumer Loops?  [Generally, Consumers run faster, on average, than Producers ...].

Bob Schor

[RTSLVU]

Everything Bob said times ten, I could not even find the VISA part you were having trouble with in the few minutes I spent looking at your code.

Good luck with that...

BTW: A couple minutes is all anyone should need to get a basic understanding properly written LabVIEW code 

[Moseq]

Hello All,

thanks for advises, I am honestly self-made LabView user without proper training technics so basically I suck at using proper functionalities. Maybe you can help me find some good tutorials or propose books etc which I can find useful.

Back to topic, this is "USB Switch", its a physical USB relay - link here: Relay Link 

It is communicating with LabView here by his constant address. What this "consumer" loop is supposed to do is that "Producer loop" from above is sending a time by queue to "Switch loop" and "Switch loop" is using it to where set USB Relay Controller Board into different states. As said previously all parallel loops connected by queues are working smoothly until they reach more than a x hundred cycles, then the error occurs after VISA Write and USB Relay Control Board is not responding. What is more, time is being set by USB-6210 card which is generating Finite Samples - 10 sample rate. 

Question  besides crap looking code is: Shall I put this VISA into "Producer loop" with DAQ acquistion and it would be enough or I can leave it like that and I am just doing smth bad here.

Thanks in advance,

Moseq

[RavensFan]

You are converting an array of doubles to a string.    Are you sure that is what you want to do?  All of those should be U8 integers since the function is U8 array to string.

That may not be the problem, but I get suspicious when wrong data types are used.

Do you need the VISA Clear?

I also wonder about your use of the shift register on the error wire.  If you get some random error, that will perpetuate on all further iterations of the while loop. and the VISA Write and VISA Clear will no longer execute as they use the standard error functionality of skipping execution if there is an incoming error.  You don't have any indicators or probes on that error wire or any other error handling to let you know if an error does occur and take any action to fix it.

I also see you have some hollow blue tunnels which mean they are set to output the default value of zero if a case where the tunnel is unwired executes.  Could that be happening?  It would  possible break the flow of your inner state machine.