Our system utilises INPUT_BYTE to capture NMEA0183 ASCII stream which sends data to the NOM multiple times a second. The NOM module can either be on a RIO (EIO) rack through a CRA module, or on a M340 rack with a NOM module attached.
There is no request for the data to be sent by the NMEA0183 system, it just streams into the NOM0200 port, so the thought is the timeout in the Management Table can be 0 (0*t#100ms=t#0s). The NOM0200 port is configured to capture a message (NMEA0183 sentence) when certain stop characters are received. The INPUT_BYTE EF is triggered once (rising edge) the Management Table Activity Bit indicates it is not active.
Unfortunately, we have found this input stream will stop being transmitted from the NOM port to the INPUT_BYTE EF in the PLC logic. There is no indication of this other than the activity number freezing and received data not being updated. The Management Table does not provide any indication of an error and the NOM0200 module also does not show and error, yet the COM indicator on the module indicates data is still being received.
There are several ways this is fixed. One is to swap the HSBY ePAC between primary and standby. If that doesn't work, the only solution found is to complete a full download to both ePAC. Obviously neither of these is very practical, especially for systems that operate remotely.
Our team has been in contact with SE and been informed that the Timeout setting on the Management Table needs to be configured. I am confident our team has already tried this but we will attempt again.
So the questions for the PLC.net gurus are:
Thanks in advance for your time and effort.
There is no request for the data to be sent by the NMEA0183 system, it just streams into the NOM0200 port, so the thought is the timeout in the Management Table can be 0 (0*t#100ms=t#0s). The NOM0200 port is configured to capture a message (NMEA0183 sentence) when certain stop characters are received. The INPUT_BYTE EF is triggered once (rising edge) the Management Table Activity Bit indicates it is not active.
Unfortunately, we have found this input stream will stop being transmitted from the NOM port to the INPUT_BYTE EF in the PLC logic. There is no indication of this other than the activity number freezing and received data not being updated. The Management Table does not provide any indication of an error and the NOM0200 module also does not show and error, yet the COM indicator on the module indicates data is still being received.
There are several ways this is fixed. One is to swap the HSBY ePAC between primary and standby. If that doesn't work, the only solution found is to complete a full download to both ePAC. Obviously neither of these is very practical, especially for systems that operate remotely.
Our team has been in contact with SE and been informed that the Timeout setting on the Management Table needs to be configured. I am confident our team has already tried this but we will attempt again.
So the questions for the PLC.net gurus are:
- Have you experienced this before when utilising NOM0200 modules and what was the fix?
- Does it make sense to set a timeout, on a communication interface that does not have a request and response function; like Modbus?
- Shouldn't the Management Table be flagging some sort of error other than timeout? I say this because data is still streaming into the port (indicated by COM lights flashing), and there is no request to timeout.
- Does this make sense for the PRINT_CHAR function as well? Again, there is no expected response once the character string has been transmitted, but SE state a timeout is required.
Thanks in advance for your time and effort.