LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW Data Communication

Hello,

 

I currently have an application where I am running a python script on a linux machine and a labview program on a windows machine. I am looking for a deterministic and very quick way to send some data from the python script to labview. I am currently achieving this by using the tcp protocol palette in labview, but I was wondering if anyone had experience with a quicker/more deterministic way to send the data.

 

Thanks,

 

Jeremy 

0 Kudos
Message 1 of 7
(2,130 Views)

You are talking about two different machines communicating with each other.... ie physical link.

There are multiple ways of complication this depending on your requirements...

The simplest would be setting an IO line that you could monitor with the other machine when it is "ready"

RS232 is also a possibility if you require actual data communication.

And then of course, TCP as  you are already doing.

 

If you are asking about a Reliable Protocol... that is a different conversation.

---------------------------------------------
Certified LabVIEW Developer (CLD)
There are two ways to tell somebody thanks: Kudos and Marked Solutions
0 Kudos
Message 2 of 7
(2,085 Views)

Thanks for the suggestions! Ideally we would like a way to transfer the data as quickly as possible and at the same rate every single time. Another approach we have experimented with is having a shared file between the two computers and having the python script write to the file and labview read from the file. This seems to work, but we want to explore all possible solutions as determinism is extremely important for this application.

0 Kudos
Message 3 of 7
(2,073 Views)

Can I ask what about TCP is not "deterministic" enough? Have you actually done checks and found delays or irregular send intervals?

 

If they're connected to each other over a LAN you should get sub-millisecond communications between them, and the things about TCP that you don't actively see (handshaking, assembling a message into packets and reassembling them at the other side, making sure all packets get there, etc.) make it pretty reliable on the Internet in general and very reliable over a LAN where you're probably going through one or two switches at most, if not directly connected.

 

I guess if you're adding WiFi to the mix it's slightly less reliable, but you didn't mention that...

 

Using a shared file is still TCP, by the way, but now it's asynchronous and it adds another 2 layers to the delivery (the file storage medium and the protocol for file sharing, SMB or whatever).

0 Kudos
Message 4 of 7
(2,068 Views)

Thanks for that info. From some preliminary testing we observed that sending the data directly using TCP took anywhere from 1 ms to 10 ms and using the file method mentioned above was even slower. Honestly it is looking like we will go with the direct TCP communication, but I was just wanting to see if anyone had any experience doing it another way.

0 Kudos
Message 5 of 7
(2,057 Views)

I don't think there's any way to guarantee deterministic behavior with regular Windows and Linux PCs but you might try UDP rather than TCP if your connection is solid.  UDP's lack of error checking makes it substantially faster which would also likely mean better timing consistency.

LabVIEW Pro Dev & Measurement Studio Pro (VS Pro) 2019 - Unfortunately now moving back to C#, .NET, Python due to forced change to subscription model by NI. 8^{
0 Kudos
Message 6 of 7
(2,051 Views)

Have you considered adding a private network between your two PCs?  If you already have unused network ports it's easy, if not they're like 20 bucks each.  Then just add one ethernet cord between them, and set up a private 192.168 network between the two.  It should get those 10ms message speeds to go even faster.

0 Kudos
Message 7 of 7
(2,030 Views)