LabVIEW
tcp listen.vi error during debug
@Vasilich2004 wrote:
Simple TCP.lvproj example works fine in normal mode. When debug is used then tcp listen.vi has timeout error.
i see this in LabVIEW 2024 32 bit and 2025 64 bit.
Wildly guessing that your definition of "debug mode" is execution highlighting. Here' timing is very different and the code runs very slowly.
Can you clarify?
Your client may use a shorter timeout and expect the server to accept the connection within a certain time and either answer a specific request within a certain time or actually send a certain message first.
Without knowing what client you have that is supposed to connect to your server and what timeout it uses we can just guess.
@Vasilich2004 wrote:
By the way I can't image how to use such vi in real system when 2 applications aren't synchronized in different way.
These examples are not meant to be ready made applications, but to show the principle of how to use the functions. Error handling is minimal to not confuse the user looking at the example.
A proper application, especially when doing network connections, should have a fairly extensive error handling and proper error handling does not mean to just throw your hands into the air and quit on any error.
Depending on what error occurs and where, you are supposed to do different things. Any error including timeout error on trying to open a connection should ideally simply close the connection and try to reopen it, after a somewhat random delay.
Any error except timeout, "should" usually do the same but it depends on your specific application. Timeout on trying to read a response "should" usually simply retry reading the data, but again it can depend on your application.
With these basic rules you can create a fairly stable system, but to get a fully working and stable system a lot of fine tuning and debugging is usually needed.
@Vasilich2004 wrote:
actually, that reminded old time when coax cable was used for network and all computers shared single line. it isn't absolutely the same example but as minimum close
Actually, your earlier problem has nothing to do with that.
While the UTP cables nowadays may seem like you have individual wires between your network device and the host, that is definitely often not so. There is a wire from your computer to a hub, switch or router and from there to 1 or more other systems but logically if your intermediate device is not a router, the connections are all sharing the same network subnet. They may not be the same physical cable but are still sharing the same logical network subnet and are working according to the same principals as with those old coaxial cables.
But that has nothing to do with the fact that the timing of your software changes when you run it in debugging single step highlighting mode and that your other end of the software (your client connecting to the listener) has to behave with the same extended delays that your listener under debug mode causes. Otherwise your client is just running away and concluding that there is no listener present before your single stepped listener software had a chance to create one.
