LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

python shared memory object

Solved!
Go to solution
Solution
Accepted by hallo77

@hallo77 wrote:

Thank you so much for your generosity in answering my questions. It does seem complicated, and it would take a long time to study it. I'll consider other options now. But this idea, if there is more time and energy in the future, I still want to have a try to break through myself. Thank you very much for your reply!


Why so stuck on shared memory? Unless you need something highly performant than just go the TCP route. In the end it will be much easier to implement and much more flexible. Yes, LabVIEW can act as both a client and a server. In fact, a single LabVIEW application can have multiple clients and servers running at the same time. The systems I am working on are rather large and complex and use a publish/subscribe messaging system. The larger applications I work on have dozens of servers and clients all running asynchronously.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 21 of 24
(392 Views)

No, I admit that TCP is a good choice. It's just that I think I want to structure the data sending and receiving area between Python and labview to make the logic a little easier. Because the amount of data I want to transfer is not very large, using TCP will not be a bit overqualified. But I still prefer to use this method. Thank you very much!

0 Kudos
Message 22 of 24
(381 Views)
Solution
Accepted by hallo77

And yet another option would be to use a real message queueing system to handle the transfers of data without any knowledge of TCP or UDP programming. ZeroMQ has an API and examples for LabVIEW, and the pyzmq module comes with Anaconda or can be downloaded from PyPI. There is a Python example here, but I would recommend reading the guide.

 

Using a basic PUB/SUB architecture, you can achieve what you want very easily. Moreover, the PUB and SUB need not be on the same computer and the code would not change a bit (just update an IP address). ZeroMQ takes a bit of reading to understand, but it is well worth it versus that same time stuggling to get your own TCP server/client working robustly. But perhaps your application is simple enough that it is not necessary to be very robust if you are only ever on localhost.

_______________________________________________________________
"Computers are useless. They can only give you answers." - Pablo Picasso
Message 23 of 24
(348 Views)

Thank you!It is a great idea.I would have a try.Thank you very much for your new ideas.

0 Kudos
Message 24 of 24
(342 Views)