Debugging a CVS application from a PC sometimes causes changes to the startup setup of the CVS

[Jaques]

When I program a CVS with a startup application, I would have expected that this setup

will remain in place until I explicitly change the startup application.  For example, when I use the

CVS for debugging, I would have expected that the debugging process would not change

the way the CVS boots up, and I could always just reboot the CVS to return to a known

state.

I'm finding some debugging sessions will change the CVS so that rebooting will lead it

through a series of 3 reboots and finally self-entering into safe mode, so that I have to

erase all files from the CVS and copy in a filetree saved from before debugging started.

Is there a procedure I can follow during debugging to ensure that the CVS will boot up

normally afterwards?

[Irene B]

Hi Jaques,

From what I understand, you have an executable that runs whenever the CVS starts up.  To debug a CVS application, you run your LabVIEW RT program on your PC that is targeting the CVS.  I have several questions about your situation:

• Would you please clarify what your startup application does normally?
• What kind of modifications are made while debugging that cause the CVS to change its startup behavior?  It seems that some changes do not cause the CVS to reboot abnormally while other changes do not.  
• You mentioned that after erasing the CVS files, you copy the files saved from before debugging.  Are you ever able to copy over an altered file?  Perhaps the altered code is corrupted or the changes you are making are not compilable/compatible with the CVS.
• Has this behavior always occurred or only started happening recently?
• What software versions are you using (such as for the NI-IMAQ for IEEE 1394 driver, LabVIEW RT, Vision Builder AI, etc.)?

Thanks,
Irene Chow
National Instruments
Applications Engineer