LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

FPGA to PC connection via UDP

Solved!
Go to solution

Hi All,

 

Background

I'm currently working on a project to interface a FPGA with a PC, to transmit a UDP payload prepared on the FPGA to the PC. The FPGA prepares a payload of 18 hexadecimal bytes from 8'h00 to 8'h11 and then transmits this over a local network on port 1024, between the FPGA and a second network card in the PC, with static IPs issued to the second network card and the FPGA. The packets leave the FPGA and reach the PC (tested with wireshark) but the vi does not seem to pick up the payload and display it on the screen in the vi. The vi is based on the one shipped with labview and features only a few adjustments mostly just writing the final recorded packets to a text file.

 

Problem:

Originally when the vi was run the string length kept evaluating to zero and so it perceived it as no bytes were read from the port. I then inserted the flatten-to-string vi after the UDP read and before the string length comparison (having read something on the forum), now the string length is not evaluated to zero but to 4 instead, I also changed the display option to hex, and the same 4 hex keep coming through ' 0000 0000 0D0A 0000', but these are not the ones that were sent from the FPGA (are they an error message?) and not the ones picked up by wireshark. In summary, I appear to not be able to read the data out of the UDP payload within Labview.

 

I have tested the VI locally using the UDP send vi from labview and the (slightly) customised receiver vi and it still works. The receiver vi is attached.

 

Any suggestions would be great,

 

Thanks,

 

James.

0 Kudos
Message 1 of 10
(4,692 Views)

Simple question first: is 192.168.1.3 the IP address of the local computer, or of the FPGA? It should be the local computer, and you might try removing it entirely (at least for testing) so that it listens on all available network connections. Also, why is port number set to 61557 if you're expecting the message on port 1024?

 

You're not reading any data from the UDP connection. Flatten to String isn't helping you at all here - it's just inserting 4 empty bytes at the beginning of the string. When you flatten a string to a string, all that happens is it prepends the string length as a 4-byte value. Since it's a 0-length string, you get 4 bytes of zeros. The 0D0A is, not surprisingly, the line feed/carriage return that you concatenate onto the string.

 

Check the port number and IP address. If that doesn't fix it, post your test sender VI as well to compare. Remove Flatten to String.

 

For style reasons I'd put the "Data Received" indicator after the case structure rather than before it.

0 Kudos
Message 2 of 10
(4,673 Views)

Thanks for your suggestions, 192.168.1.3 is the address of the PC, when the vi loads for the first time it resets the port to 61557, I've now made it into a constant value 1024, I have also removed the flatten to string. I placed a probe on the data out line and error out line of the UDP read, when the vi is run with the FPGA sending packets (picked up on wireshark), the probe on data out displays a value of "", this is evaluated as zero string length and so the case structure is set to false. Also the an error 56 is displayed on the error out, if I increase the timeout on UDP read, error 56 is still displayed just after a longer wait before it times out. 

Download All
0 Kudos
Message 3 of 10
(4,655 Views)
Solution
Accepted by topic author JPhys

Can you share the wireshark log (preferably in some text-based format as I don't have wireshark installed)?

 

Are you sure there's no firewall issue? If you're running a firewall, either disable it completely for that network card or at least make sure it accepts connections on UDP Port 1024.

 

Also, put the UDP Sender VI on a different computer and see if you still receive data. If that works, compare the wireshark logs versus what's being sent by the FPGA and look for differences. If that doesn't work, then you have a networking issue such as a firewall.

0 Kudos
Message 4 of 10
(4,650 Views)

The firewall was running for the second network card, and Labview was not on the list of allowed programs, it is now and everything seems to be working fine, thanks for your help.

0 Kudos
Message 5 of 10
(4,632 Views)

Hello, i am interested by UDP in FPGA. Could you post examples, please ?

 

Ludo

0 Kudos
Message 6 of 10
(4,433 Views)

Hello James,

 

I am also facing the same problem. Please attach the subvi (no timeout error.vi) or final working UDP receiver VI. Or else kindly forward the VIs to my mail id: nagaraju.s@astramwp.com

 

Thanks & Regards,

S Nagaraju

0 Kudos
Message 7 of 10
(4,160 Views)
Hello S Nagaraju - this thread was marked solved 2.5 years ago, and the problem was a firewall, not LabVIEW. The VIs are already posted here. If you are having trouble, please post your code, explaining exactly what error occurs. You may also want to try Wireshark to look at the network traffic.
0 Kudos
Message 8 of 10
(4,131 Views)

Dear Sir,

 

The above attached receiver VI is showing error because of subvi (no timeout error.vi). Please attach that subvi also.

 

Thanks & Regards,

S Nagaraju

0 Kudos
Message 9 of 10
(4,108 Views)

The VI "no timeout error.vi" is part of the LabVIEW UDP Receiver example, and on my machine is found at C:\Program Files (x86)\National Instruments\LabVIEW 2012\examples\comm\UDP.llb\no timeout error.vi. It simply checks if the error code is 56 (timeout) and if so, clears the error.

 

Let's continue this in your other thread.

0 Kudos
Message 10 of 10
(4,073 Views)