This project has moved. For the latest updates, please go here.

SEL Fast Message Problems

Oct 13, 2013 at 10:42 PM
Hi,

I am trying to connect an SEL-734 using SEL fast message. I can connect to it using PMU connection tester and get some data, but it errors out in ~30 seconds due to "exception threshold". When I try and connect it to OpenPDC I get a single error, followed by a time out:

[SELUNIT-2] Attempting connection...
[SELUNIT-2] Initiating SEL Fast message TCp based connection...
[SELUNIT-2] Connection Established.
[SELUNIT-2] Statistics Reset for all devices associated with the connection.
[SELUNIT-2] Bad data stream, expected header bytes 0xA546 as first bytes in SEL Fast Message frame, got 0xFFFB
[SELUNIT-2] No Data Received in 5.0 seconds, restarting connect cycle...

I know there are data frames because I can see them in PMU connection tester as well as in wireshark.

here are some of the PMU connection tester errors I get:
Attempting connection to "ID 1 using SEL Fast Message over Tcp" at 10/13/2013 5:14:27 PM using SEL Fast Message
Connected to device "ID 1 using SEL Fast Message over Tcp" at 10/13/2013 5:14:27 PM using SEL Fast Message
Exception: Bad data stream, expected header bytes 0xA546 as first bytes in SEL Fast Message frame, got 0xFFFB
Exception: Invalid binary image detected - check sum of DataFrame did not match
Exception: Count must be positive and count must refer to a location within the string/array/collection.
Parameter name: count
Exception: Bad data stream, expected header bytes 0xA546 as first bytes in SEL Fast Message frame, got 0xFFA5
Exception: Bad data stream, expected header bytes 0xA546 as first bytes in SEL Fast Message frame, got 0xFFA5
Exception: Invalid binary image detected - check sum of DataFrame did not match
Exception: Count must be positive and count must refer to a location within the string/array/collection.
Parameter name: count
Exception: Bad data stream, expected header bytes 0xA546 as first bytes in SEL Fast Message frame, got 0xFFA5
Exception: Count must be positive and count must refer to a location within the string/array/collection.
Parameter name: count
Exception: Invalid binary image detected - check sum of DataFrame did not match
Exception: Bad data stream, expected header bytes 0xA546 as first bytes in SEL Fast Message frame, got 0xFFA5
Exception: Count must be positive and count must refer to a location within the string/array/collection.
Parameter name: count
Exception: Bad data stream, expected header bytes 0xA546 as first bytes in SEL Fast Message frame, got 0xFFA5

Please help!

Thank You!
Coordinator
Oct 14, 2013 at 1:19 PM
Try changing the SEL device ID code to zero - there was a bug in the openPDC where it didn't set the right ID code for SEL fast message frames using the wizard.

This has been fixed in later versions.

Thanks!
Ritchie
Oct 14, 2013 at 2:36 PM
I am using OpenPDC version 1.5.243.0

I tried changing the ID to 0 and it is still throwing the same error. But now in addition it also sometimes says "Data channel receive exception: The I/O operation has been aborted because of either a thread exit or an application request".

I have written a python script that acts as an intermediary and logs the messages in both directions and it seems that all the messages are normal.

My lab test device has no GPS signal, could it be that there is a problem with the timestamps being too far off? If so is there a way to fix that without getting GPS?
Coordinator
Oct 22, 2013 at 8:06 PM
Don't think GPS would be the issue. I have only connected to SEL Fast Message over Serial and I do not see these errors. I have a 421 I connect to and it doesn't have an attached clock.

Assuming you just have a single socket connection (i.e., TCP only not TCP command channel combined with UDP data channel).

Can you provide the connection string for the device?

Thanks,
Ritchie
Oct 22, 2013 at 8:26 PM
Ritchie,

Thank you for your help!

I think I have actually traced the bug back to a firmware issue with the 421. The error only occurs when connected over tcp/ip, not serial and I have found messages that do not seem to conform to the SEL-FM standard. I wrote a python script to make the connection, filter those messages and send the stream back out over the local port and I can now connect to the device without issue.

I plan on following up with SEL on the problem, I can update you on the issue once I have gotten a reply from them if you like, otherwise consider the issue close.

This is the connection string:
transportprotocol=Tcp;server=129.118.19.173;port=23;interface=0.0.0.0;islistener=False;; messagePeriod=TwentyPerSecond
Coordinator
Oct 22, 2013 at 9:38 PM
OK - thanks for following up. I am here at NASPI in Chicago, I'll ask some of the SEL folks while I'm here...

Ritchie
Coordinator
Oct 23, 2013 at 1:07 PM
Do you happen to know if the issue is with both the 734 and 421 - or just one of those? It may help get your issue to the right person...

Thanks,
Ritchie
Oct 24, 2013 at 1:47 PM
The 734 is all I have tested. SEL has informed me that it is not a firmware bug, it is intentional behavior that occurs because SEL-FM travels over telnet when transmitted over TCP/IP. Telnet uses 0xFF as a command character so they double transmit the 0xFF so that telnet clients will let it pass. He said some devices support a "raw_tcp" mode that does not do this, but the 734 is not one of those devices.
Marked as answer by ritchiecarroll on 11/1/2013 at 11:37 AM