11-04-2015 05:45 PM
I've noticed some strange behavior and I'm curious if I'm the only one or if maybe this is expected behavior.
I have a moderately sized application running on cRIO-9068 that uses AF as the primary design pattern. When I reach certain milestones in development, I will build the app into an rtexe and deploy it as the startup app for testing purposes. After testing and more code iterations, I will connect to the target (through the project) and run the app interactively so I can probe and debug new code.
Here’s the problem, the interactive deployment (while the target is running the rtexe) fails. It always will timeout waiting for target to respond. Most of the time it is at the end of deployment when it is deploying Project Settings. I had to change my workflow in order to work around this problem. Now I always disable the startup app, reboot the target, wait, connect to target, and run interactively. Oh and, consecutive interactive deployments also timeout unless I restart the target.
Is this expected behavior? I’ve assumed that LabVIEW was unable to successfully abort the running Actors. That seemed like a reasonable cause, but I would like to confirm. If this behavior is because of something in my application I would like to fix it.
Thanks,
Kevin
11-05-2015 09:55 AM
Kevin,
A few things. A deployment while an rtexe is running doesn't sound like best practice. Stop the rtexe. Then deploy.
When running interactively, it sounds like the program is not fully stopping. So, the restart kills it all the way. Do you have a way to stop your interactive version? For instance a launch root actor and then a while loop with a case structure wired to a stop button. False is a wait ms and true is a Send Normal Stop. If the program isn't stopped I believe this is expected behavior.
Casey
Phoenix, LLC
CLA, LabVIEW Champion
Check Out the Software Engineering Processes, Architecture, and Design track at NIWeek. 2018 I guarantee you will learn things you can use daily! I will be presenting!
11-05-2015 12:38 PM
Thanks Casey - You're probably right about it not being best practice. It's just never been a problem, and I've expected LabVIEW to clean up the target prior to the deployment because it offers a dialog that says something like "click OK to Abort the running program and continue deployment".
So it got me wondering if there is something unique about AF (like having concurrent process) that keeps LabVIEW from cleaning things up for me.