Problems using TCPIP sockets with Labview 8.5 and vxWorks Workbend 2.6

[vball5]

Hi,

I'm currently trying to use TCPIP sockets to connect my target board,
which has vxWorks running on it, to the host computer, which has
Labview running on it. Right now, the target board is the client and
the host computer is the server.

I send a "1" from the target board to Labview, which Labview receives
fine. When I try to return the same "1" back to the target board, I
get a read error. Does anyone know why this may be occurring?

I have also tried UDP sockets, and the same thing occurs. I can send
one way, but not the other.

Thanks.

[MikeS81]

Hi vball5,

is your vxWorks program designed to recieve TCPIP data? Where do you get the error? If it is on LabView, which error do you get?

Mike

[vball5]

On Jul 18, 12:40 am, MikeS81 <x...@no.email> wrote:
> Hi vball5,
> is your vxWorks program designed to recieve TCPIP data? Where do you get the error? If it is on LabView, which error do you get?
> Mike

Hi Mike,

The vxWorks program is designed to receive TCPIP data. The way you
set it up is pretty similar to the windows API socket functions. So,
pretty much I just specified I wanted to use TCPIP sockets.

I don't get an error in Labview. What happens is once Labview has
completed sending the data across, it closes the socket.. and once the
socket in Labview closes, then my vxWorks program spits out a read
error. I tried leaving the Labview program open, but then the vxWorks
program never seems to read the data. The vxWorks program returns a
-1 if there is an error reading the data, and this -1 is what I get
for the read error.

[Stephen_S.]

Hi vball5,

I would suggest that you try to run a loop-back test to make sure that LabVIEW is able to write and read correctly. If you set the IP address you are communicating with to 127.0.0.1 and write and read a value, you should be able to verify the communication abilities of your LabVIEW install.

Do you have more information about error -1 and what specifically it means for the vxWorks board, or what could be causing it from that side?

If you want to really investigate the communication between the devices, you can use a program called Wireshark, available at www.wireshark.org to analyze the write and read on a packet by packet basis. Instructions for how to use the program are available here.

Regards,
Stephen S.

[vball5]

Ok. I will try a loopback test again. We tried it once upon a time,
but some devices changed, so I will try it again.

Also, the error I get from the read is errno 54, which is connection
reset by peer. Does Labview automatically reset the connection at the
end of a TCPIP transfer? Or is that something in the code (I didn't
write the Labview side). Thanks.

I will also look at the Wireshark output to see the results are.

[Stephen_S.]

Hi vball5,

LabVIEW should not be closing the connection that you are using unless you specifically tell it to. Otherwise there may be firewall issues that are preventing the data from sending correctly. If you have multiple ethernet cards, there may be an issue with which one is sending or receiving data, and you could try removing the card that you are not using and trying again after restarting the system.

Regards,
Stephen S.