Cross-talk between data socket channels

[pbuerki]

Hi,

Has anybody observed something similar;

I have a LabVIEW program controlling a vacuum system. The user interface contains a number of indicators that are data socket subscribers. The data are generated and broadcasted from subvis. Now, when one data socket channel, e.g., dstp://localhost/Autosampler Valve 1 broadcasts a value, I regularly observe that one of the other indicators (with a different data socket channel, i.e., dstp://localhost/Autosampler Valve 1x, x=0-9) also responds and changes its value as well. It is not always the same channel. I tried to write a test vi that reproduces this, but there everything works just fine (no cross talk).

I appreciate your help.

Peter

[Andy F.]

Peter,

I have never seen this behavior before with Datasocket.  Each address should not have anything to do with one another, so I can't think of a reason why you would see one channel following any others.  I might suggest trying to bind one of the controls to the front panel and see if you see the same information.  Are you configuring the indicator addresses programatically or are they hard coded?  As you know a small test VI would be ideal, so certainly repost that if you ever get it working.  Are you able to wire these values instead of using Datasocket?  Let me know!

Thanks!
Andy F.

[pbuerki]

Hi Andy,

Thanks for your reply.

I have trimmed the LabVIEW program down as much as possible and deleting all hardware-related parts. The attached Datasocket Troubleshooting.vi reproduces the oberved cross-talk between some of the data socket channels. The original program operates an automated vacuum system switching pneumatic valves, reading pressure transducers, etc. The controls on the user interface represent some of the valves of the system, TRUE (green) corresponding to the Valve OPEN state, and FALSE (red) to the Valve CLOSED state. I could reproduce the error by clicking on the valves in the following sequences

Cross-talk between Valve 1 and Valve 10: Left click on 10>10>1>1

Cross-talk between Valve 1 and Valve 11: Left click on 11>11>1>1

Cross-talk between Valve 1 and Valve 12: Left click on 12>12>1>1

Note that the hardware is not affected by this cross-talk, i.e., the physical valve 10 (or 11, 12, respectively) does not open/close when valve 1 is actuated. But it gets very confusing (and potentially dangerous) when the user interface shows a different status of the vacuum system than the hardware.

No cross-talking has been observed between any of the other controls in this example. However, in a similar program, I have also observed cross-talk between channels 2 and 2x and channels 3 and 3x (x=0-9).

BTW, I have LabVIEW version 7.

I am looking forward to hearing from you.

Peter

[Andy F.]

Peter,

I opened your VI and was missing a couple of the files to actually execute the VI.  If you could include the Add Queue Element and Actuate Valve (Eagle) Dummy VIs, I will be more than happy to check into this for you.  Thanks!

Andy F.

Message Edited by Andy F. on 10-04-2006 08:28 AM

[pbuerki]

Sorry. I thought these files were included. Here is the complete zip file. Please let me know, if it takes longer to troubleshoot this. Thanks for your help.

Peter

[Andy F.]

Peter,

I was able to see your behavior in LabVIEW 7.1 and earlier.  That is a very interesting error indeed.  I wasn't able to find any information about this error happening before, so I tested it in LabVIEW 8 and after some furious clicking I wasn't able to see any crosstalk at all.  Would it be possible to upgrade versions of LabVIEW?  I checked out the code and it didn't seem to be doing anything it should not have been doing.  So I started experimenting with the subVI with the DataSocket in it.  I believe that I was able to get the cross talk to stop by opening a DS connection reference each time.  I also had to remove the spaces in the DS URL to keep the VI from crashing.  I would try using the VI attached and see if you are still having problems.  Let me know!

Thanks!
Andy F.

[pbuerki]

Thank you, Andy, for looking into this. I tested the vi that you sent me, and I also have the impression that your changes fixed the problem. I will let you know in case that the issue occurs again. Thank you very much for your help.

Peter