“The controller at XYZ, shut down with no reason 3 times on Monday and 4 times today. As you are aware when it crashes it loses some data and they need to take a lot of time to re-sync the system.
“The controller shows Exception access violation 0xc000004 address 0x012345. What is wrong ?”
“The controller was working until yesterday and today nothing works”
Above error descriptions do not help. More detail is needed. Remember that the person is not on-site and relies on the information you forward.
One the most difficult tasks of supporting a customer that has issues like the above, is to know what is really going on, without being there.
Usually, a system is installed, training is given, and 1-2 productions are made. Therefore, the most important question is: what has changed since those successful productions ?
Very important also is to describe well the circumstances, filter the noise.
Minimum Data required in order to analyzing the problem remotely
1) The log file
Zip the log file in D:\EditorGT\etc\logg\logg.csv
Log files can be big, hence, please write date and time when the error occurred.
2) The arguments.txt and license file
In D:\EditorGT\user/system. Make sure you do not have any trace switched on, not only here but in inkjets and readers. Traces are there to setup and see what is happening in the background but not for regular production. Trace will slow down your system !
3) The statistic file
Zip the log file in D:\EditorGT\etc\statistic\statistics.csv
4) The job file
In the GT application, go to Service/Backup/Local and select the job or configuration that gives you problems. ZIP the job (all files with the same name) in D:\EditorGT\user\backup. Example: jobname.set.cfg, jobname.set.job, jobname.set.lay.
5) Some data
Zip the data file in D:\EditorGT\data\address\filename.
It must be the data file that corresponds with the job saved in 2)
Controller Version and date (about), for example 3.52G P20: ______
Controller Tracker (Peripheral test), for example 2AM: _______
If GT-Jet (in inkjet menu): RIP, FPGA, tracker, backplane, firepulse, head.
7) Check memory
Windows likes to have sufficient memory. Press <ALT><CTRL><Delete>, go to Performance, and check the Physical Memory available. At least 30 KB should be there.
What is the available memory ?
8) Anti-Virus program
Companies like to install all kind of anti-virus programs. The problem is that these programs sometimes take a lot of memory and run whenever they want, affecting the real-time behavior of the controller. It is a controller that needs to react in microseconds, not your secretary’s PC.
Did you install an antivirus program ?
May be there is a lot of traffic in your network or LAN.
Have you tried to unplug the RJ45 cable from the LAN ?
10) New job
One can make a job/configuration from scratch, or just copy one that was working fine (Save all as) so that setup errors are avoided.
If a new job does not run, have you tried to go to an old job that run wonderfully last week ?
If the old job works, what is different with the new job ?
10) Reproduction of error
The best is if someone can tell the steps that lead to a crash.
Can you repeat the problem and tell us step by step what you do ? Is the error in the log file, what date, what time ?
11) Configuration/Job does not open correctly. Use Service/Backup, Service/Restore
Make it a routine to make a backup of the good jobs so that you can always pull it up when you need it. People change configurations, files get corrupted with power outages, etc.
Go to Service/Backup and save your configuration locally or better on a floppy ! You will always be able to restore a configuration you know worked.
12) Have a network ?
Connect it to the controller, add teamviewer or webex so that one can see what is happening from afar. If time is critical, doing remote monitoring can affect the real-time behavior of the system also.