08-10-2012 06:11 AM
Hi,
We made the application working.Nothing changed in the labview program,in C# I programmed it in the asynchronous manner.
Thanks.
08-13-2012 07:26 AM
Hi,
Now we are trying to establish a full duplex communication between labview and C#.For that we have to receive some commands send from C# to labview.In the C# application they have implemented in such a way that a client can both send and receive the data frame.So Iam trying to receive those data through port 8222.But we are not able to receive the data properly.Nothing is comming.In C# application we can see that the data is sending properly.Please review the code attached below and please give necessary instructions.
08-13-2012 12:53 PM
Do you understand how TCP connections work?
Your C# program is sending the data to port 8221, so why would you expect to receive it on port 8222? On the C# side, it sends fine because you have already established a connection. On the LabVIEW side, the data is being received on port 8221 and the operating system buffers it until you read it - which you never do.
However, you can't establish two separate connections on the same port, so you'll need to re-use the same connection for both sending and receiving (this is pretty much the definition of full-duplex).
08-13-2012 11:14 PM
Hi nathand,
I mistakenly wrote full duplex communication.I meant the two and fro communication between labview and C#.In the C# code we can see that it is receiving data from labview through 8221 and sending commands to labview through 8222.So in that case what is the problem with the labview connection.Using two TCP listeners is correct??Any other problem in the connection which prevents labview from receiving the data?Data send from labview is receiving in the C# side successfully.But reverse operation is not taking place.
08-14-2012 01:51 AM
@danil33 wrote:
Hi nathand,
I mistakenly wrote full duplex communication.I meant the two and fro communication between labview and C#.In the C# code we can see that it is receiving data from labview through 8221 and sending commands to labview through 8222.So in that case what is the problem with the labview connection.Using two TCP listeners is correct??Any other problem in the connection which prevents labview from receiving the data?Data send from labview is receiving in the C# side successfully.But reverse operation is not taking place.
One thing would be that your receiving loop only reads 4 bytes and tries to treat it then as tab separated table to convert it in a table. Wouldn't you agree that 4 bytes is terribly small for an entire table?
Also tying up two server sockets in the LabVIEW application, one or each data direction, seems not only like a waste of resources (yes network sockets are starting to get a precious resource on nowadays heavily connected machines), but also an extra complication further down as you will likely have to synchronise the incoming and outgoing traffic later on. Or are your two datastreams really meant to be fully asynchonous? That sounds like a bad design decision to me!
Anyhow, you really should remember previous advices from other threads. When something doesn't seem to work in LabVIEW you can of course add 500 front panel controls and all that, but the first line of defence is to use debug breakpoints, single step execution and execution highlighting, until you get an idea where the problem might be. In your specific case with a totally indepependent listener for each direction, put each one in its own diagram. That will allow you to single step through one and let the other run continously if you should want that.
02-03-2021 07:57 AM
I know this is an old post.... Add a WinForm control using a .net container on the front panel and pass in the reference to the method using it. The control on the front panel will be updated as the method executes.
To trigger an event within the C# method from the front panel in LV , you need to setup a cancellationTokenSource and create a token in the C# method.
in addition, companies use both LV and text base languages, so there is a need to discuss the interaction here.