МЭК 80670-5-104

← →
Sonoleo © (2009-07-29 10:28) [0]

Уважаемые дельфисты! Отзовитесь, кто реализовывал клиента по ТСР/IP с сервером по протоколу МЭК104? Могу приложить кусочки текста клиента. У меня коннект с тестовым сервером появляется, но на любой мой запрос типа:
Type U[FCT=TESTFR_ACT], (68 04 43 00 00 00); Type U[FCT=STARTDT_ACT], (68 04 07 00 00 00) - выдаёт
28.07.2009 16:50:18 ====== Запуск ======
28.07.2009 16:50:26 IEC: Connection request from address 127.0.0.1, port 8710
28.07.2009 16:50:26 IEC: wrong format request. Можете подсказать в чём причина?

← →
Palladin © (2009-07-29 10:53) [1]

причина в wrong format request

← →
Sonoleo © (2009-07-29 11:22) [2]

перевод понятен, а причина?
Форматы я привёл - (68 04 43 00 00 00). Это 16-ный формат тестового запроса по APCI. Стартовый 68H, длина APDU - 04. управляющая функция TESTFR_ACT - 43H (расшифровка: 01 00 00 11). Пользовался тестовым клиентом и он показывал точно такой же формат запроса. Пробовал передавать поток строкой и массивом байт - не помогает.

← →
Palladin © (2009-07-29 11:38) [3]

> а причина?

это и есть причина

> Форматы я привёл

и что с того? ты же не привел ни код посыла, ничего не привел... я тоже могу спросить в чем причина: я отсылаю на http сервер запрос по формату "GET /" а мне ошибку пишет? что ты мне на это ответишь? или ты считаешь что если привел стандарт формата значит и код уже не нужен?

вот странные люди...

← →
Sonoleo © (2009-07-29 12:07) [4]

мож я и странный (тупой), даю текст:
//====================================
procedure Mess(var S : string; b1,b2,b3,b4,b5,b6,b7,b8,b9,b10,b11,b12,b13,b14,b15,b16 : char);
begin
// $TX Type U[FCT=TESTFR_ACT] ============ управление без нумерации
// 68 04 43 00 00 00
// $TX Type U[FCT=TESTFR_CON] ============ управление без нумерации
// 68 04 83 00 00 00
// $TX Type U[FCT=STARTDT_ACT] =========== управление без нумерации
// 68 04 07 00 00 00
// #RX Type U[FCT=STARTDT_CON] =========== управление без нумерации
// 68 04 0B 00 00 00
// $TX Type I[LEN= 10, ACK=0, SEQ=0] ===== передача информации с нумерацией
// 68 0E 00 00 00 00 64 01 06 01 01 00 00 00 00 14
// $RX Type I[LEN= 10, ACK=1, SEQ=0] ===== передача информации с нумерацией
// 68 82 02 00 02 00 24 08 14 00 01 00 01 00 00 33
S := "";
S := S+Char(b1); // СТАРТ 68H определяет точку начала внутри потока данных
S := S+Char(b2);
S := S+Char(b3); S := S+Char(b4); // по умолчанию Type U[FCT=STOPDT_ACT]
S := S+Char(b5); S := S+Char(b6); S := S+Char(b7); S := S+Char(b8);
S := S+Char(b9); S := S+Char(b10); S := S+Char(b11); S := S+Char(b12);
S := S+Char(b13); S := S+Char(b14); S := S+Char(b15); S := S+Char(b16);
end;
//=============================================
procedure TForm2.Button1Click(Sender: TObject);
var
SResponse: string;
Buff : array[1..255] of byte;
begin
TCPClient.Port := 2404;
with TCPClient do
begin
Connect;
while Connected do
begin
try
Mess(SResponse,char($68),char($04),char($43),char($0),char($0),char($0),char($0) ,char($0),
char($0),char($0),char($0),char($0),char($0),char($0),char($0),char($0));
WriteLn(SResponse); // № 1 - посылка Type U[FCT=TESTFR_ACT]
finally
Disconnect;
BStream.Free;
end;
end;
end;
end;
Тестируюсь с программой "Пример КП МЭК104", открытая в ООО "ЕНТЭЛС", 2008 www.entels.ru. Они выставили исходники оболочки на Билдере, главное скрыто в DLL"ках. На мои вопросы пока не отвечают.

← →
Dennis I. Komarov © (2009-07-29 12:31) [5]

Еще один любитель стрингов...

Бери сниф и смотри все что прога-пример отправляет

← →
Palladin © (2009-07-29 12:33) [6]

а не нужно делать WriteLn, у тебя в строке встречается символ #0, что означает конец строки... делай SendBuff или как его там... просто send, не помню точного названия

← →
Sonoleo © (2009-07-29 12:52) [7]

Вы думаете, что я впервые на велосипед сел? Были варианты ...
//====================================
procedure Bytes(var B : array of byte; b1,b2,b3,b4,b5,b6,b7,b8,b9,b10,b11,b12,b13,b14,b15,b16 : byte);
begin
// $TX Type U[FCT=TESTFR_ACT] ============ управление без нумерации
// 68 04 43 00 00 00
// $TX Type U[FCT=TESTFR_CON] ============ управление без нумерации
// 68 04 83 00 00 00
// $TX Type U[FCT=STARTDT_ACT] =========== управление без нумерации
// 68 04 07 00 00 00
// #RX Type U[FCT=STARTDT_CON] =========== управление без нумерации
// 68 04 0B 00 00 00
B[0] := b1; // СТАРТ 68H определяет точку начала внутри потока данных
B[1] := b2;
B[2] := b3; B[3] := b4; // по умолчанию Type U[FCT=STOPDT_ACT]
B[4] := b5; B[5] := b6; B[6] := b7; B[7] := b8;
B[8] := b9; B[9] := b10; B[10] := b11; B[11] := b12;
B[12] := b13; B[13] := b14; B[14] := b15; B[15] := b16;
end;
//=============================================
var
Buff : array[1..255] of byte;//integer;
...
Bytes(Buff,$68,$04,$43,$0, $0, $0, $0, $0, $0, $0, $0, $0, $0, $0, $0,$0);
WriteBuffer(Buff,4,false); // № 1 - посылка Type U[FCT=TESTFR_ACT]

В дельфийской строке в первом байте длина строки, WriteBuffer это от Indy. Результат прежний. В WriteBuffer был и false и true. Не помогло.
Dennis - а сниф - это что по русски?

← →
Palladin © (2009-07-29 12:58) [8]

WriteBuffer(Buff,4,false)

почему 4 байта?

← →
Dennis I. Komarov © (2009-07-29 13:01) [9]

> Dennis - а сниф - это что по русски?

Прога, которая покажет все что происходит внутри TCP при связи проги-примера с сервером.
http://ru.wikipedia.org/wiki/Sniffer

З.Ы.
А на кой тут индеец, если есть стандартный TTCPClient?

← →
Sonoleo © (2009-07-29 13:51) [10]

Type U[FCT=TESTFR_ACT], (68 04 43 00 00 00); - это процедура испытания (тестирования). Открытые соединения могут периодически проверяться путем посылки тестового APDU (TESTFR=act), который подтверждается приемной станцией с помощью (TESTFR=con). Это кадр типа U в формате:
--------------------------
СТАРТ 68H - 1 байт = 68
Длина APDU (максимум 253) - 2-ой байт = 04
Поле управления байт 1 = 43
Поле управления байт 2 = 00
Поле управления байт 3 = 00
Поле управления байт 4 = 00
--------------------------
мой тестовый (как и стартовый) кадр не распознается сервером в таком формате.
Есть клиент немецкий тестовик DemoWinPP104, еще CybServer870-5-104M, который работает и выдает подробный протокол, начиная с команды на сервер STARTDT_ACT и STARTDT_CON. А у меня ошибка в формате.

P.S. Некоторые программисты считают, что такой протокол - "высший пилотаж"

← →
Sonoleo © (2009-07-29 13:54) [11]

Вот пример протокола:
29.07.2009 13:45:25:578 Пример ПК МЭК 104 Open Link (ISP870_OK)
29.07.2009 13:45:25:671 Пример ПК МЭК 104 $TX: 68 04 07 00 00 00
29.07.2009 13:45:25:671 Пример ПК МЭК 104 $TX: Type U [FCT=STARTDT_ACT]
29.07.2009 13:45:25:781 Пример ПК МЭК 104 #RX: 68 04 0B 00 00 00
29.07.2009 13:45:25:781 Пример ПК МЭК 104 #RX: Type U [FCT=STARTDT_CON]
29.07.2009 13:45:25:781 Пример ПК МЭК 104 Init Link (ISP870_OK)
29.07.2009 13:45:25:828 Пример ПК МЭК 104 $TX: 68 0E 00 00 00 00 64 01 06 01 01 00 00 00 00 14
29.07.2009 13:45:25:828 Пример ПК МЭК 104 $TX: Type I [LEN= 10, ACK=0, SEQ=0]
29.07.2009 13:45:25:828 Пример ПК МЭК 104 #RX: 68 0E 00 00 02 00 64 01 07 01 01 00 00 00 00 14
29.07.2009 13:45:25:828 Пример ПК МЭК 104 #RX: Type I [LEN= 10, ACK=1, SEQ=0]

← →
Dennis I. Komarov © (2009-07-29 14:16) [12]

Серверу до лайпочки от кого он получил данные...

← →
Palladin © (2009-07-29 14:35) [13]

> В дельфийской строке в первом байте длина строки

неправда

ты не ответил на вопрос в [8]

← →
Sonoleo © (2009-07-29 15:52) [14]

Прошу прощения, во втором байте стоит 04, а это Длина APDU (максимум 253) - 2-ой байт = 04. Всего должно быть 10 байт, а не 04. В моем примере [7] закладывается 16 байт. Я ещё разок проверил WriteBuffer(Buff,10,false);- бестолку. По сути сервер должен анализировать только первых 3 байта согласно протоколу. В третьем байте (управляющее поле) задана функция TESTFR_ACT:
8 7 | 6 5 | 4 3 | 2 | 1 |
TESTFR STOPDT STARTDT | | |
con | act | con | act | con | act | 1 | 1 | Байт 1
0 | Байт 2
0 | 0 | Байт 3
0 | Байт 4

0 1 0 0 0 0 1 1 = $43
а насчет "неправда", когда-то очень-но давно ковырялся в строке паскаля и в си. В нулевой строке паскаля сидит длина строки, а у си конец строки в конце и равен #0. В частности между ними (си и паскаль) и в этом есть.

← →
Palladin © (2009-07-29 15:59) [15]

> а насчет "неправда", когда-то очень-но давно ковырялся в
> строке паскаля и в си. В нулевой строке паскаля сидит длина
> строки, а у си конец строки в конце и равен #0. В частности
> между ними (си и паскаль) и в этом есть.

Ковырятся не надо, надо справку читать. В Делфи есть Паскалевские строки (ShortString, макс 255 символов), они содержат длинну в нулевом байте, но есть и длинные строки (String, 2гб в теории) у них более хитрая система, и уж тем более они содержат длинну строки совсем не там.

← →
Sonoleo © (2009-07-29 16:17) [16]

это не очень интересно. А как всё-таки насчет:
28.07.2009 16:50:18 ====== Запуск ======
28.07.2009 16:50:26 IEC: Connection request from address 127.0.0.1, port 8710
28.07.2009 16:50:26 IEC: wrong format request. Можете подсказать в чём причина?

> Sonoleo © (29.07.09 16:17) [16]

Так и будешь в партизанов играть?

> Можете подсказать в чём причина?

Русским по белому wrong format request

Судя по всему идей ни у кого нет. Извините!

> WriteBuffer это от Indy

Заметался, горемычный ..
То TTCPClient, то Indy ..

const
Test: array[0..5] of byte = ($68, $04, $43, $00, $00, $00);

TCPClient.BlockMode := bmBlocking;
..
TCPClient.SendBuf(Test, SizeOf(Test))

> TCPClient.BlockMode := bmBlocking;

он вроде и так по дефолту

> он вроде и так по дефолту

Может и по дефолту, не помню..
Тем проще)

← →
Дмитрий Белькевич (2009-07-30 22:40) [23]

Стоит всегда исходить из очень простого принципа. Байты везде одинаковы (с). Ставь сниффер и побайтно смотри, что не так. Это помогает в 100% случаев. Как в работе с сетью так и при работе с файлами.

МЭК 80670-5-104 Найти похожие ветки