I’m not sure if this helps, but in this example of retrieving data from an external source (a Windows Dialog in that case), all DotNet vars are defined as RunOnClient.
In your case, the NAV client plays the role of the server (TCP listener), is this correct? While the electronic scale is the TCP client. That is, the communication is only initiated by the electronic scale (i.e. when it has to send some measurement to the computer). In this case, IMHO the original error message ("… is either unavailable or your connection has been lost.") has nothing to do with the actual TCP communication you are implementing, but with NAV communication internals between NAV server and NAV Windows Client. Is this correct?
UPDATE (for the newer error message):
How about wrapping all the communication logic in a single DLL, then use a single DotNet var in C/AL. And this single one var would be “RunOnClient”.
Also, do you think there are some permission issues? Opening a TCP Listener may require more privileges? How about the firewall? Does the computer have more Network Cards? Are they all configured correctly? Though, most probably it wouldn’t matter, since perhaps the driver of the electronic scale… And right now I realise: isn’t it the driver of the scale which should be the TCP server? Why do you need a TCP listener?
What is the lifespan of the TCP listener? When do you run the C/AL code that starts it? On a Page Load of something similar?
This last paragraph only makes sense if there is an actual need of a TCP listener (and perhaps only as a last resort):
If acceptable from a deployment point of view, a Windows Service can be installed on the computer and be the TCP listener itself. Then, it would update a file on the local file system when a new measurements arrives from the electronic scale. Then, when the NAV user requires the latest measurement data (say, to fill in a field on a page), a piece of C/AL code can read the contents of that file.
[P.S.: Sorry for the many edits]