Welcome to the new Schneider Electric Community

It's your place to connect with experts and peers, get continuous support, and share knowledge.

  • Explore the new navigation for even easier access to your community.
  • Bookmark and use our new, easy-to-remember address (community.se.com).
  • Get ready for more content and an improved experience.

Contact SchneiderCommunity.Support@se.com if you have any questions.

Close
Invite a Co-worker
Send a co-worker an invite to the Exchange portal.Just enter their email address and we’ll connect them to register. After joining, they will belong to the same company.
Send Invite Cancel
84549members
353806posts

[Imported] Comms Statistics in ClearSCADA

EcoStruxure Geo SCADA Expert Forum

Find out how SCADA systems and networks, like EcoStruxure Geo SCADA Expert, help industrial organizations maintaining efficiency, processing data for smarter decision making with IoT, RTU and PLC devices.

sbeadle
Janeway Janeway
Janeway
0 Likes
0
259

[Imported] Comms Statistics in ClearSCADA

>>Message imported from previous forum - Category:ClearSCADA Software<<
User: mchartrand, originally posted: 2018-10-25 17:43:15 Id:258
This is a re-posting from the obsoleted (October 2018) "Schneider Electric Telemetry & SCADA" forum.

_______

**_Bigls:
Framing Errors?
Overruns?
BCH1 Errors?
BCH2 Errors?
NACK Errors?
Timeouts? I think I know this one. The RTU has not replied to the masterstation in a given timeframe.
Unknown Messages? Interfrence...
Bad Comms?
Any information would be very gratefully received_**

___________

bevanweiss:
You might need to tell us what driver you're using, as these comms statistics are driver specific.
But in general...
Framing errors would be when Start / Stop other control flags aren't present in the Layer 2 interface. So the Layer 3 and above data can't be 'framed' (separated from other L2 frames).
Overruns would be when excessive data is received, such as an L2 fragment being restricted to 292 bytes, but 300 bytes are transmitted.
BCH1 and BCH2 errors relate to error detection and correction coding (Bose - Chaudhuri - Hocquenghem = BCH), meaning that the data that was received was invalid, possibly due to interference during transmission.
Timeouts, as you say.. a message expecting a response didn't receive a response within a configured timeout period.
Unknown messages, are just messages that the receiver doesn't understand. So everythign else is valid about them, but the type code, or function code (or something else) within them just isn't understood.

____________

**_Bigls:
Bevan,
Thank you very much for the information. I reset the comms statistics after asking the initial question. Below are the comms statistics for a site that I'm having trouble with. It is a Talus T4e outstations communicating via analogue radio (4 wire: TX audio pair and RX audio pair), complete with Westermo TD23 modem. The scan has a remote FED. The outstation is in communication, but fails to take a download. The error is with timeouts. From the radio the audio has to be converted to RS232 this is done by the TD23 modem. I'm now thinking that the download is a longer conversation than the communications check and the delay inherent with the conversation is causing the timeouts.
Of the other 45 outstations on the scan this is the only Talus T4e the rest are Proteus outstations (PS1, PS5, 2000M or PX24's).
How would you extend the timeframe and do you think I'm on the right path?
Comms. Statistics Since 18/12/2017 15:47:25
Comms. Count 0 Framing Errors, 0 Overruns, 0 BCH1 Errors, 0 BCH2 Errors, 0 NACK Errors
Comms. Count 4579 Timeouts, 0 Unknown Messages, 2261 Good Messages, 10 Bad Comms, 0 Good Comms
Scan Phases 1% Min Primary, 21% Max Primary, 2% Average Primary, 0% Min Secondary, 0% Max Secondary, 0% Average Secondary
Thanks again
Steve_**

___________

bevanweiss:
Hi Steve,
It's quite possible that you're correct.
Analog radios aren't as robust as modern digital radios when it comes to the actual data transmission and receiving. They will eventually have some errors that creep in, which might be the cause of the timeouts that you are seeing (if the data is being corrupted then the outstation / master might not understand that it was originally intended for them).
I don't know enough about the Talus outstations to tell.

What driver are you using in ClearSCADA?

So the whole transmission would be
ClearSCADA - (RS232) TD23 (audio) - Analog Radio (Tx) - Analog Radio (Rx) - (audio) TD23 (RS232) - T4E
?

Do you have any settings within the Analog Radios which will prevent transmits over a certain duration? This is an issue that I've seen before with large transmissions... there can be like a 'maximum keying time' which is often like 10seconds or such. This would result in the large data transmissions being prematurely terminated by the radio, and would cause such issues.

I would overall recommend a migration to digital radios however... they will generally make things better (faster speeds, better error correction and detection, less hardware required).