4. Follow the on-screen OS Download Instructions
Pros/Cons
This is a good way to recover a CR1000 that has gone into an unresponsive state.
Often, an operating system can be loaded even if you are unable to communicate
with the CR1000 through other means.
Loading an operating system through this method will do the following:
1. Restore all CR1000 settings to factory defaults
2. Delete data in final storage
3. Delete data from and remove the USR drive
4. Delete program files stored on the datalogger
7.7.2.1.2 OS Update with DevConfig
This method is very similar to sending an OS as a program, with the exception
that you have to manually prepare the datalogger to accept the new OS.
How
1. Connect to the CR1000 with Connect or DevConfig
2. Collect data
3. Transfer a default.CR1
(p. 116) program file to the CR1000 CPU: drive
4. Stop the current program and select the option to delete associated data (this
will free up SRAM memory allocated for data storage)
5. Collect files from the USR: drive (if applicable)
6. Delete the USR: drive (if applicable)
7. Send the new .obj OS file to the CR1000
8. Restart the previous program (default.CR1 will be running after OS compiles)
Pros/Cons
This method is preferred because the user must manually configure the datalogger
to receive an OS and thus should be cognizant of what is happening (loss of data,
program being stopped, etc.).
Loading an operating system through this method will do the following:
1. Preserve all CR1000 settings
2. Delete all data in final storage
3. Delete USR: drive
4. Stop current program deletes data and clears run options
5. Deletes data generated using the CardOut() or TableFile() instructions
7.7.2.1.3 OS Update with DevConfig
A send program command is a feature of DevConfig and other datalogger support
software
(p. 654). Location of this command in the software is listed in table
Program Send Command Locations
119
To Next Page
Loading...
Need help?
General
