I am using LabVIEW 2010 Version 10.0 (32 bit)
1. This is an issue that I notice a few versions ago but decided that since I an reporting issues that I would log this one. Within the Timed Loops, may be other places also, under "Configure Input Node" there is a parameter named "Structure Name". Even if i use the default value, if I copy a VI that basically does the same thing as I need in another VI and then modify it as needed, the "Structure Name" in the 2 VI Timed Loops remain the same. This causes one of the VI Timed loops to not function since there is already another loop with the same "Structure Name". I have worked around that by naming my "Structure Name" with the VI name and then add a 1, 2, 3, etc. if I have multiple Timed loops within the same VI.
2. I just noticed this so I do not know if this is the way it was designed or not, See my "Server Example.vi". I am using the function "Format Date/Time String" to display the time on the server. When the "UTC format" flag is False, when the software is running and I change the system time, the time displayed by the software does not change to the new time. It does keep incrementing using some internal counter. When the "UTC format" flag is True, the time my software is displaying does update when I change the system time.
3. My software is designed to have one server computer and any number of client computers. The server computer will collect trace data from multiple instruments, allow the controlling client to send command to any of the instruments, and determine the display menu data for the controlling client to choose from. In order to help timing of all of this, I have 7 ports on the server computer that the client software will connect to. Four ports are for the trace data from each of the four instruments. One port is for the commands that are transmitted by the controlling client. One port is for all of the menu data so that the clients all have the same screen. One port for random system related instructions. My issue deals with the "TCP Read" function. The messages for each port have a four character start of text type unique code so that the software can verify that they are receiving a proper message. The "TCP Read" is set for "Buffered" mode with a 1 MS timeout and four bytes to read. Normally, if the software did not get a message from the client, the "TCP Read" function will return a timeout error. The code handles this as an acceptable condition. Otherwise, the code assumes that the "TCP Read" function has four bytes of data and compares that to what it is expecting. If it is valid, it processes the rest of the message. If it is not, the software is not sure how it got out of sync, but it reads any data on the port and trashes it hoping the port will sunc up on the next message. Here is where the problem occurs, sometimes the "TCP Read" will return a "NO error" condition indicating that it has four bytes of data. However, when the software checks, the returned string has a length of zero. I have put code in to handle this condition, but do not think that is the way it is suppose to work. I have some test VIs included that simulate the environment. It may take a while, but eventually you may see the Server indicators for the number of times zero bytes were returned increment indicating the condition has occurred. My system is much more complicated and sends a lot more data, not as often as I have done in the example, but this gives you an idea of the code being used.
Those are the things that I have noticed. Perhaps they are bugs or perhaps they are just features in the event you do not want to consider them bugs.
Bill Simmons
