Hal,
no matter whether you use my stuff or not: The very first thing you
should do after opening the serial port is to transmit a ++auto 0 to
hinder the interface from sending something own its own. My own internal
stuff reads as follows:
if QCCom32.Opened then
begin;
Debugform.Console.WriteString('Port has been opened'+#13+#10);
Qccom32.Flush;
sendstring:='++auto 0'+#13+#10;
sendflag:=true;
autoenabled:=False;
repeat
sleep(10);
application.ProcessMessages;
until sendflag=false;
debugform.Console.WriteString('Send ++auto 0 command'+#13+#10);
sendstring:='++ver'+#13+#10;
sendflag:=true;
repeat
sleep(10);
application.ProcessMessages;
until sendflag=false;
debugform.Console.WriteString('Send ++ver command'+#13+#10);
j:=0;
repeat
inc(j);
sleep(100);
until dataavailable or (j>=10);
if dataavailable then
begin;
PLfound:=(pos('GPIB-USB',Valuebuffer)<>0);
DataAvailable:=False;
end;
Best regards
Ulrich Bangert
> -----Ursprüngliche Nachricht-----
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Im Auftrag von Hal Murray
> Gesendet: Dienstag, 27. Februar 2007 04:32
> An: Discussion of precise time and frequency measurement
> Betreff: Re: [time-nuts] Linux code for Prologix GPIB/USB
>
>
>
> > At the end of the USB cable there is a FTDI chip that (in
> conjunction
> > with the appropiate driver) emulates a serial port. This
> serial port
> > in turn is connected to the serial port of an AVR type of
> > microcontroller. Because this microcontroller expects a certain
> > setting of serial transmission parameters you have to set them
> > correct, otherwise it will not understand your commands.
>
> Thanks. Makes sense, I guess. I was assuming they had
> reprogrammed the FTDI
> chip rather than adding another CPU. (I'm not sure why. The
> AVR is pretty
> obvious.)
>
> There is a layer of stuff I haven't sorted out yet. It's all
> tangled up in
> the GPIB device being at the far end of a serial (USB or
> RS-232) string. The
> Prologix defaults to automagiclly reading data when it
> becomes available and
> sending it up to the kernel rather than waiting for you to
> explicitly poll it.
>
> I see two cases where that might get confusing. One is when
> you send it a
> command at about the time it sends you something. You can't
> tell if the data
> you get arrived before or after your command.
>
> My normal command sequence is running in single cycle mode so
> it's easy to
> stay in lock step once you get started. So far, I haven't
> had any troubles
> getting through initialization, but I'll bet my code would
> screwup if it got
> delayed for long enough in the right places.
>
> The other case is if you are talking to several devices.
> Again, there is a
> race as you switch devices. You can't tell if the string
> arrived before or
> after you switched. I think this case can be avoided by
> switching to a
> device that doesn't exist, checking for input, then switching
> to the new
> device. It probably requires some pauses in the right place.
>
>
> > I have only very limited Linux experience and even less
> with Windows
> > emulation under Linux.
>
> You probably know more about Linux than I do about Windows.
>
> I was just looking for a subroutine package rather than a GUI/IDE.
>
>
>
>
>
>
> --
> These are my opinions, not necessarily my employer's. I hate spam.
>
>
>
>
> _______________________________________________
> time-nuts mailing list
> time-nuts@febo.com
> https://www.febo.com/cgi-> bin/mailman/listinfo/time-nuts
>
_______________________________________________
time-nuts mailing list
time-nuts@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
