FAQ

| Print out this category

FAQ
No.1
Q: In what case does a communication test with UGW fail?
A: The following cases can be considered in the becoming “NG!“ case.
1. Name resolution was failed due to an incorrect host name or DNS server has been halted.
2. Network cable is blocked off.
3. Proxy server settings is not correct.
No.2
Q: I want to know the interval of data transmitting from E-RDS to the UGW, and what data size is sent to the UGW?
A: The schedule of data transmitting, the start time are determined by settings in the UGW side. The timing is once per 16 hours by default, and counter data volume could be maximum 250 bytes.
No.3
Q: Does error-retry carry out at the time of a communication error with the UGW?
A: Retry of SOAP communication is performed as follows.
In the case of an error in SOAP communication (i.e. a trouble at UGW side) at transmission of the alarm code list and the service mode counter (postAlert) due to change of device status, the data failed in transmission equivalent to 3 retries is to be stored in the HDD. In the case of anther transmission error (the 4th error), the oldest data of the stored data is deleted and the newly-generated retry data is stored in the HDD.
In the case of SOAP transmission errors as described below, the unsent (and remaining) data is sent again depending on the storage status of CPCA data:
At transmission of a jam log and service mode counter (postJamLog) when the jam log was obtained from the device.
At transmission of a service call log and service mode counter (postServiceCallLog) when the service log was obtained from the device.
At transmission of an alarm log and service mode counter (postAlarmLog) when the alarm log was obtained from the device.
In the case of a SOAP transmission error at transmission of a service mode menu list (postServiceModeMenu) due to change of the setting value in the service mode menu, the service mode data is obtained at every retry to be sent.
In the case of a SOAP transmission error at transmission of browser information (postBrowserInfo) due to change of the license status of the device’s web browser option, the browser information is stored in the retry information to send the stored data again.
In the case that the device is rebooted while the retry information is specified, however, another browser information is obtained to be sent.
NOTE:
The retry data will be sent at interval of 5*n minutes. (n: retries, 5, 10, 15 minutes…up to 30 minutes)
No.4
Q: How many log-data can be stored?
A: Up to 30 log data can be saved. The data size of error information is maximum 128 characters.
No.5
Q: Although Microsoft ISA as a proxy server is introduced, the authentication check is failed. Can E-RDS adopt with Microsoft ISA?
A: E-RDS must comply with “Basic” while “Integrated” authentication is used for Microsoft ISA (as default); therefore, authentication with E-RDS is available if you change the setting to “Basic” authentication on the server.
No.6
Q: Can I turn the device power off during the e-Maintenance/ imageWARE Remote system operation?
A: While operating the e-Maintenance/ imageWARE Remote system, the power of the device must be ON. If power OFF is needed, do not leave the device power OFF for long time.
It will become “Device is busy, try later” errors if the power supply of network equipment such as HUB is made prolonged OFF.
No.7
Q: Although a Service call error may not be notified to UGW, the reason is what?
A: If a service technician in charge turns off the power supply of a device immediately after error occurred once, It may be unable to notify to UGW because data processing does not take a time from the controller of the device to NIC though, the data will be saved on the RAM.
If the power supply is blocked off while starting up, the data will be inevitably deleted.
No.8
Q: How does E-RDS operate while the device is placed in the sleep mode?
A: While being in Real Deep Sleep, and if data to be sent is in E-RDS, the system wakes up asleep, then starts to send the data to the UGW. The system also waits for completion of data transmission and let the device to shift to asleep status again.
However, transition time to the Real Deep Sleep depends on the device, and the transition to sleep won’t be done if the next data transmission will be done within 10 minutes.
No.9
Q: Is E-RDS compatible with Section counter (Department counter)?
A: No, E-RDS does not support Section counter.
No.10
Q: Is there any setting to be made on the device side to enable the service mode menu transmission function? Moreover, what is Service mode menu set as the object of transmission?
A: No steps peculiar to Transmitting Service mode menu. As for the data that applies to transmission of the service mode, see the “Service mode menu Transmission”.
No.11
Q: What service browser data is transmitted to UGW by E-RDS in what timing?
A: The service browser data to be transmitted and the transmission timing are shown below.

Transmission timing | Detailed procedure | Transmission information | Error occurs
When the service browser is enabled from the disabled state [OFF] | 1) Specify the service browser setting in the service mode menu. 2) Send browser information to UGW. 3) Once obtaining OK response from UGW, enable the service browser mode [ACTIVE]. (To use the setting, it is necessary to reboot the device) | Service browser mode: [Register] WEB browser option: [ON] or [OFF] according to the license status | Retransmission is not performed. ("Disabling [OFF]" continues to be set.)

No.12
Q: Can I make another service call request when I have already requested a service call?
A: No, you cannot make another service call request if you have already made a service call request.
Touch the [Cancel] button to cancel the service call which you’d made. Or the service technician performs a service call completion process.
No.13
Q: Is the “Requesting” status cancelled when the device is rebooted?
A: The requesting status is not cancelled even if the device is rebooted. The information of the notified service call request (the time that the request was made, the service call request description) is also retained during the “Requesting” status.