| Page 29 of 32 |
| ||||||
|
|
|
|
|
|
| ||
| Error Message |
|
| Explanation |
|
| ||
| works | best with | long | each table is different. The driver does not know the length of the |
| |||
| timeouts. |
|
|
|
| responses. The Carrier devices take some time between receiving a poll |
| |
|
|
|
|
|
| and sending a response. The amount of time is proportional to the length |
| |
|
|
|
|
|
| of the response (and hence, to the size of the table.) If the device takes |
| |
|
|
|
|
|
| too long the driver may timeout as the default timeout is 2.0 seconds. It is |
| |
|
|
|
|
|
| strongly recommended that you set the timeout to a large value (like 30 |
| |
|
|
|
|
|
| seconds) to start with. The effect of having a large timeout is to |
| |
|
|
|
|
|
| 1) allow the driver enough time to receive the response and |
| |
|
|
|
|
|
| 2) Increase the amount of time before the driver reports the timeout if |
| |
|
|
|
|
|
| there is a genuine timeout event. |
|
|
|
|
|
|
|
| This message is printed when a response is received but the driver did |
| |
|
|
|
|
|
| not find any information in the response that it could use to store. If the |
| |
| CarrDP:#26 | FYI. | No | data | problem occurs repeatedly then take a log and call tech Support after you |
| ||
| was stored for MD=%s |
| have tried the following diagnostic steps. 1) Check connection stats – If |
| ||||
|
| bytes received per message is < 100 then it is likely that the device you |
| |||||
|
|
|
|
|
|
| ||
|
|
|
|
|
| are polling is not responding properly or that a port setting is invalid. |
| |
|
|
|
|
|
| Check the port settings. |
|
|
| CarrDP:#27 Err. Can’t open | This message should only be printed in simulation mode (QA testing). If |
| |||||
| slave.log |
|
|
|
| you see this message call Tech Support. |
|
|
| CarrDP:#28 FYI. Response | This message should only be printed in simulation mode (QA testing). If |
| |||||
| was sent | from | slave.log | you see this message call Tech Support. |
|
| ||
| (Hex file) |
|
|
|
|
|
|
|
|
|
|
|
|
| This message could be produced when the characters which signal the |
| |
|
|
|
|
|
| end of a response are missing and the next response is appended to the |
| |
|
|
|
|
|
| 1st in the input buffer. In such cases the buffer may overflow. |
| |
|
|
|
|
|
| This message is printed once and then suppressed. However each time |
| |
|
|
|
|
|
| the event occurs, the STREAMING stat is incremented by one. |
| |
| CarrDP:#29 | Err. The | input | If the stat is produced rarely then you could assume that that an |
| |||
| buffer has overflowed. |
| occasional corrupt/incomplete message has produced the error. |
| ||||
|
|
|
|
|
| If it occurs all the time, then assume that the response is too large to fit in |
| |
|
|
|
|
|
| the input buffer. |
|
|
|
|
|
|
|
| Most FST drivers have an input buffer of 3080 bytes This driver has a |
| |
|
|
|
|
|
| buffer size of 16000 bytes. The buffer size is hard coded so you will need |
| |
|
|
|
|
|
| to capture a log and send an error report to FST. |
|
|
|
|
|
|
|
| When parsing a response, the driver processes the response line by line. |
| |
|
|
|
|
|
| A single response may consist of a number of lines. Each line is |
| |
| CarrDP: #30 |
|
|
| terminated with a Carriage Return (CR). If a single CR is missing then |
| ||
|
|
|
| the driver sees two lines as a single line. In versions prior to 1.03eA the |
| |||
|
|
|
|
|
|
| ||
|
|
|
|
|
| driver used the line number as the offset, therefore values extracted from |
| |
|
|
|
|
|
| subsequent lines were stored at the incorrect offset. Now the driver |
| |
|
|
|
|
|
|
| ||
|
|
|
|
|
| ignores the corrupted line and advances the line counter by 2 continuing |
| |
| CarrDP:#31 | Err. | Line has | the parsing and storing of extracted values. The values associated with |
| |||
| missing CR. Some data not | the corrupted response line are not updated. This is reflected in the line |
| |||||
| stored |
|
|
|
| count stored at offset zero. The driver detects lines with missing CR's by |
| |
|
|
|
|
|
| checking the line length. If the driver senses that more than two or more |
| |
|
|
|
|
|
| consecutive CR's are missing then the driver abandons the parse and |
| |
|
|
|
|
|
|
| ||
| CarrDP:#32 | Err. | Many | store and prints error #32. If different parts of the response have missing |
| |||
| CR's message #31 will be printed more than once per response. There |
| ||||||
| missing | CR's. | Abandon | is no direct corrective action you can take. The errors arise from dropped |
| |||
| store... MD=%s |
|
| bytes in the response. If the error occurs frequently you will need to |
| |||
|
|
|
|
|
|
| ||
|
|
|
|
|
| check that the data transmission is not being adversely affected by noise. |
| |
FieldServer Technologies 1991 Tarob Court Milpitas, California 95035 USA Web: www.fieldserver.com Tel: (408) 262 2299 Fax: (408) 262 2269 Toll Free: (888) 509 1970 email: support@fieldserver.com