RT Network Communication Problem

[StephanieA]

Did this error message say something along the following lines?

"Possible reasons
Error copying files.

Source: xxx

Destination: xxx"?

If so, what file was it looking for?

This error typically occurs when LabVIEW is trying to copy a file from your hard drive into the executable you are building when a VI of that name already exists. Do you know if there are two VIs with the same name in the project you are trying to build? This error may also sometimes occur when you have the same file with different capitalizations. Does this sound like anything in your program?

If not, using the 8.x layout may not be the best option; it was just something I was interested in trying to see if that might improve the performance of your application.

[cirrusio]

Thanks, Stephanie.  That is exactly what is happening.  However, the file that it is trying to copy should be one of a kind.  That being said, I do have some name clashes due to the fact that there are some polymorphic classes that have caused some name clashes early on ("Labview prevented a name file collision...").

[cirrusio]

OK, Stephanie.  Thanks for all your help, but I think I may have inadvertently stumbled onto the problem.  This application is in ongoing development and as such some of the VIs are rough and I have not handled all of the errors appropriately.  The unhandled errors are not catastrophic (framing errors on serial IO, lack of convergence on fits, etc) and as such I have not worried about making sure they are properly handled.  And since my VIs currently default to automatically handle errors, I think that what was happening was that these errors were causing the system to hang and become unresponsive on the RT machine.  It is still unclear as to what was happening when the application was simply polling as the errors were being handled there, but since I have routed all error clusters to be handled explicitly the application seems to be chugging along fine.

I am relatively new to RT, so this behavior was not expected.  My thought is that automatic error handling would be disabled when an RT environment is targeted.  Is this not the case?

Cheers, Matt

[StephanieA · Accepted solution]

Matt,

I'm glad that you were able to find a solution that improved the performace of your application. I did verify that automatic error handling is not disabled by default when using a real-time environment.

I did a bit more research and found that there are three Properties we can change that will enhance the performance of a real-time application. To reduce memory usage and increase performance of VIs, you can disable non-essential options in the VI Properties dialog box:

• Right-click the VI in the Project Explorer window and select Properties.
• Select Execution from the Category pull-down menu
• Remove checkmarks from the Allow debugging, Enable automatic error handling, and Auto handle menus at launch checkboxes.

Your hunch was absolutely. I found if a correct strategy of error handling isn't implemented into the code, it prevents LabVIEW from suspending code execution and losing the network communication with the host. That is why using error clusters allows your program to run more efficiently. 

Do you have any additional questions or since you implemented error handling is everything running smoothly as you would expect with no additional hang ups?

[johnny_icon]

For me, error 1357 manifesed as part of a TestStand Deployment rather than an Application Builder issue . The error occurred from 2 duplicate named VIs in 2 unique classes. One character in the duplicate name was lower case while it was uppe case in the other (so they weren't truly duplicate). Correcting the case sensitivity solved my problem, and the TestStand deploymen built and ran fine.