The VISA serial Read takes some time to read values from the port after some time of running the VI

[samtha]

Hi there,

I really tried my best to understand the problem my VI is giving but in vain pls somebody help me out, my VI operation is to vary the speed of the device and read the corresponding values through UART, now initially after running the VI the values are read fast that is the serial transmission and reception is fast enough then after some time the transmission from the VI is fast but the reception is very slow this happens during the real time and when i tested my VI with hyperterminal it is giving me overrun error please help me with all these two issues....... i am posting my VI please tell me if the code is ok or do i have to make any changes.

If there are any questions regarding the problem please ask me.........thank you......

[smercurio_fc]

Can't look at a block diagram that's password-protected.

I also don't understand your comment "I tested my vi with hyperterminal". How exactly did you do that, since the serial port can only be open by one application at a time? Are you referring to HyperTerminal running on another computer?

[samtha]

Sorry for that, here i am attaching my VI that is unlocked please check it out and yes i am referring to the hyperterminal running on another computer............

[smercurio_fc]

The main issue I see as far as the communication part is concerned is that in the little loop where you are checking for the available bytes on the serial port it seems the premise was to stop that loop once you got 17 bytes. However, that's not how it's coded. The loop will stop regardless of how many bytes are on the serial port. This is because you are sending out a True out of the case structure from the check that the number of bytes is greater or equal to 17.

There are numerous other issues with your code:

• You have many unnecessary case structures. For example, the case structure I just cited above. It can be replaced with a wire. In other cases you can use the Invert function. For others (like in "SV_Data Parsing_BLDC",  the case structure can be replaced by a wire for the update of the Boolean indicator, and the use of a Select function for the numeric indicator. Using case structures like this just hides code.
• Unnecessary structures. For example, in the "SV_Data Parsing_BLDC" the while loop is completely unnecessary. Another: the initialization of the array for the shift registers. Another: The reading while loop contains an inner while loop and a case structure. The inner while loop does not need to be there. The case structure for parsing the data can be driven directly based on whether you've got enough bytes.
• Too many stops. How many Stop controls does it take to stop a loop? Apparently, for you it's three, and even then you can't stop it since they're all hidden! You only need one. Make the Boolean control called "Stop VI" visible and change the mechanical action to "Switch When Released". Be sure to initialize its value to False in your little initialization structure. 
• Unnecessary data. In your loop where you're collecting data into lots of arrays. Apparently, this seems to be purely for writing out to file, since there's no table on the front panel to display all the data. All of the shift registers can be eliminated, and you can use the Write to Spreadsheet File VI. It has an "append" input. You can wire a 1D array to it that is your new set of data (i.e., your new row of values). Call the Write to Spreadsheet File at the beginning of the program to write out your header, and then just call it when you get your new set of data.
• Why do you specify the name of the file twice? You have a path control for specifying the filename and a separate string control for specifying the name itself. Just use the one path control.
• The VISA Timeout only needs to be set once. 
• Rather than using individual outputs for the parsing VI use a cluster. This allows you to use a less dense connector so you don't have to wire to miniscule terminals.

Whew! That's it for now.

[smercurio_fc]

Oh yeah, forgot one:

• Unnecessary numeric conversions: there is no need to convert the number of serial bytes count to a DBL just to use it in the comparison functions. Those functions are polymorphic, so they will adapt to the datatype. If you wire two U32 values the output will be a U32. If you wire two different datatypes then the "larger" datatype "wins".  Please check the LabVIEW documentation on polymorphism.

[samtha]

Hi smercurio_fc,

Thank you for the suggestions i am making all the changes you mentioned, i will now check it and let you know if there are any problems.

[samtha]

Hi smercurio_fc,

I have done some changes in the VI, the issue i have seen is without the file input output operation the VI seems to work fine as soon i start writing the data into the excel sheet the VI seems to hang up and it is giving me overrun error (-1073807252) can you pls help me on this.............

[smercurio_fc]

You didn't quite follow all the comments I had made, and you actually made things worse with the VI that writes to file by introducing a loop and an uninitialized shift register. You must like loops for some reason, because you seem to be using them everywhere, even in places where they don't belong. When looking at the code further I saw other issues:

• You were closing VISA sessions for some reason when you should not be. For instance, in the VI that is the popup for configuration you were reinitializing the serial port and then closing it, guaranteeing that if you ran it, you'd be closing the VISA session.
• Instead of messing around with the VI Server to open the configuration VI simply set it up as a dialog and call it.
• You're still amassing data instead of just writing out the current set of data. This slows down your file I/O considerably.
• Instead of using the Select case to convert a Boolean to a numeric value of 0/1, use the Boolean to 0,1 function.

I updated your code. Please see the changes I made.