Here is the HEX data.
00000000 0D 0A ..
00000000 3F ?
00000000 0D 0A ..
00000000 3A :
00000000 49 44 0D 0A ID..
00000000 6F 75 74 70 75 74 73 20 30 2D 33 20 3D 20 70 6F outputs 0-3 =
po
00000010 77 65 72 20 73 6F 75 72 63 69 6E 67 20 6F 75 74 wer sour cing
out
00000020 70 75 74 73 0D 0A 6F 75 74 70 75 74 73 20 34 2D puts..ou tputs
4-
00000030 37 20 3D 20 70 6F 77 65 72 20 73 6F 75 72 63 69 7 = powe r
sourci
00000040 6E 67 20 6F 75 74 70 75 74 73 0D 0A 6F 75 74 70 ng outpu
ts..outp
00000050 75 74 73 20 38 2D 31 31 20 3D 20 73 69 6E 6B 69 uts 8-11 =
sinki
00000060 6E 67 20 6F 75 74 70 75 74 73 0D 0A 6F 75 74 70 ng outpu
ts..outp
00000070 75 74 73 20 31 32 2D 31 35 20 3D 20 73 69 6E 6B uts 12-1 5 =
sink
00000080 69 6E 67 20 6F 75 74 70 75 74 73 0D 0A 3A ing outp uts..:
00000000 4D 47 20 40 49 4E 5B 30 30 5D 0D 0A MG @IN[0 0]..
00000000 20 31 2E 30 30 30 30 0D 0A 3A 1.0000. .:
>
>> In SmartSniff I check TCP and show Characters over 127 as .
>
> I would expect it to do that if you are viewing the data as ASCII text
> instead of hex in its raw format.
>
>> I received a : after connecting
>
> Then you will have to call ReadChar() or ReadLn() immediately after
> calling Connect(), depending on whether ':' has its own CRLF or not.
> Otherwise the initial ':' will remain in the socket until after you send
> your first command, messing up your reply handling since you will be
> processing the replies out of order.
>
>> I type ID then I receive
>> outputs 0-3 = power sourcing outputs
>> outputs 4-7 = power sourcing outputs
>> outputs 8-11 = sinking outputs
>> outputs 12-15 = sinking outputs
>
> I am assuming that there are CRLF in between each of those "output" lines?
>
>> I type MG @IN[00]
>> then I receive:
>> 1.0000
>> :
>
> Same with that. Is there a CRLF received after the "1.0000"?
>
> Without seeing the actual raw data, it seems like you will have to call
> ReadLn() in a loop until ':' or '?' are received. If the ':' and '?' are
> themselves terminated with CRLF, then the reading of the reply data is
> very straight-forward, ie:
>
> procedure TMyForm.ReadReply(AReply: TStrings = nil);
> var
> Line: String;
> begin
> if AReply <> nil then AReply.Clear;
> repeat
> Line := IdTCPClient.IOHandler.ReadLn;
> if (Line = ':') or (Line = '?') then
> begin
> // end of reply ...
> if Line = '?' then raise Exception.Create('failed');
> Exit;
> end;
> if AReply <> nil then AReply.Add(Line);
> until False;
> end;
>
> procedure TMyForm.SendCommand(ACmd: String, AReply: TStrings = nil);
> begin
> IdTCPClient.IOHandler.WriteLn(ACmd);
> ReadReply(AReply);
> end;
>
> procedure TMyForm.Button1Click(Sender: TObject);
> var
> Reply: TStringList;
> begin
>
> Reply := TStringList.Create;
> try
> IdTCPClient.Connect;
> try
> ReadReply;
> // ok to send commands now...
> SendCommand('ID', Reply);
> // process Reply...
> SendCommand('MG @IN[00]', Reply);
> // process Reply...
> finally
> IdTCPClient.Disconnect;
> end;
> finally
> Reply.Free;
> end;
> end;
>
> However, if ':' and '?' do NOT have their own CRLF, then the coding
> becomes a bit more tricky:
>
> procedure TMyForm.ReadReply(AReply: TStrings = nil);
> var
> B: Byte;
> Line: String;
> begin
> if AReply <> nil then AReply.Clear;
> with IdTCPClient.IOHandler do
> begin
> repeat
> while InputBuffer.Size = 0 do
> begin
> ReadFromSource(False);
> CheckForDisconnect(True, True);
> end;
> B := InputBuffer.PeekByte(0);
> if (B = Ord(':')) or (B = Ord('?')) then
> begin
> // end of reply, remove it from the buffer ...
> InputBuffer.Remove(0);
> if B = Ord('?') then raise Exception.Create('failed');
> Exit;
> end;
> Line := IdTCPClient.IOHandler.ReadLn;
> if AReply <> nil then AReply.Add(Line);
> until False;
> end;
> end;
>
>> Here is the copy of the Smartsniff's capture.
>
> That is not the raw data I need to see.
>
>
> Gambit
