06-17-2022 08:44 AM
Hi,
Is it possible to communicate with an E-TC module (Ethernet) via Labview UDP or TCP protocol? The problem I am experiencing is that the device becomes unavailable for another user when using Labview with the universal Measurement Computing library (ULx for NI Labview)
Thanks for your help,
06-17-2022 11:50 AM
That may be by design. Imagine you are controlling a several thousand dollar experiment and some other user starts up a test program that happens to have some old configuration that still connects to the same device and BAM your entire measurement is gone or if you actively control IO on the machine it suddenly turns the motor to 5000 rpm instead of the 10 you want in your experiment.
If I would design such hardware I definitely only would allow one connection to it at any time, other than some seperate monitor only port.
06-17-2022 12:32 PM
Yes that could be by design. However, my device is a read only device that has 8 sockets to connect thermocouples on it. I only want to show the reading of thermocouples.
Thank you,
06-18-2022 09:24 AM
This is probably something you need to ask MCC. You are not really telling us exactly what you are doing (TCP and UDP are very different! For example TCP is connection based while UDP is not!)
It all depends how things are implemented under the hood. Is there an API where you can use your own lowlevel UDP?
06-20-2022 07:22 AM
I finally got an anwser from MCC. "Unfortunately no, UDP or TCP protocols are not directly supported. Access to the E-TC to LabVIEW etc. is only via InstaCal/Universal Library on Windows or via uldaq library on Linux."
"When MCC's Ethernet devices were being developed, it was decided to lock out any other User's attempting to gain access to the device as they could change the configuration, etc. when the initial user had set it up for their needs."
06-20-2022 07:45 AM
Depending on your system, it may be practical to write a simple "server" program that actually reads values and distributes them over the LAN.
06-20-2022 07:54 AM - edited 06-20-2022 07:55 AM
Your best bet is indeed pincpanter's solution. Although the TCP and UDP protocol are not officially documented, the Linux driver they published does of course provide all the information about the protocol: https://github.com/mccdaq/uldaq/blob/master/src/net/NetDaqDevice.cpp
But since the lockout is on the hardware (easy to do by only allowing one active connection at any time), it will not help to access that protocol. The limitation is in the hardware itself and by design.