Hello all,
I have serached the net up and down for an answer for my problem, but didn't
find any answer.
I have an appliation, which communicates with a serial device over the
intranet and an Comserver-adapter, using TApdwinsockport. The applications

Andreas,
  (snip)

It sounds like your comserver adapter is not working very well.
  You could enable dispatch logging in the TApdWinsockPort. When an error
  occurs you can close the port (which dumps the log to disk) then you can
  verify what your application is actually sending.

Paul,
    Paul Breneman wrote:
    (snip)

I cant believe this. The comserver adapater is sold so many times and is
    something like an industriel standard here in Germany.
    (snip)

I will try this. How do i enable dispatch logging? Do I use logging or

Hi Paul,
    I have now enabled Logging and here are the results. The relevant
    parts are marked. Does it mean, that if there is an entry in the log,
    that this is sent out? Thank you for your help.
    Andreas

Additional Information:
      I can't see the first of the marked entry in Comwatch at that time. There i
      can see the command 2 seconds later, immediatly before (a few ms) the second
      command. The command does not get send. I think there is a error in the
      chain putchar, writecom, writebuf and writesocket.

Andreas,
        (snip)


Is your application setting in a loop after you send the first command
        shown here?
        The TApdWinsockPort component does work differently in serial and
        winsock modes. There are additional threads for serial operation. If

Paul,
          (snip)

yes, i am using loops to process incoming data. Just like
          FCom.Putblock()
          repeat
          application.processmessages;

Andreas,
            (snip)

Since you have application.processmessages in your loop, the loop itself
            should not be the problem.
            Is this loop in an AsyncPro event handler or in a routine that is called
            from an AsyncPro event handler? The fact that the output is delayed by

Andreas,
            (snip)

I would just like to make a few comments about using a loop in your
            application. When I first started using AsyncPro I put a lot of similar
            loops into my applications. It is the natural way to handle things but
            it is not the Windows event-oriented way. I'd like to give you two

Just another small clarification...
              Paul Breneman wrote:
              (snip)

The ExBlock example won't work if you need to use TApdWinsockPort and
              winsock operation (the ExThread example approach should work for this).
              --

Andreas Kanthak schrieb:
      (snip)
Dear Andreas,
      having a look at the log file I found something interesting:
      all commands are processed within microseconds, just the one where YOu
      are encountering problems ends up nowhere. I want to say, it is not

Dear Andreas,
        more:
        You are getting a double answer (&H....) from the ME for the command
        before the crucial command (?Hn...) , is that OK?
        Regards

Hi Michael,
          Michael K?hler wrote:
          (snip)

Thank you for the hint. I will check this.
          Andreas
          

Michael,
        (snip)

Please could you explain me. where do you seeing the problem?
        All of the commands are in use for several years now.
        The same measuring routine does its job, when connected only serial.
        (snip)

Do you use measurement equipment? What kind of?

Paul,
              thank you for your continuous support.
              This is a draft. I hope this will give you a correct view:
              procedure TTransfer.TriggerAvail(CP: TObject; Count: Word);
              var

Andreas,
                (snip)

I don't see any problems with the code you showed. My only question
                would be how did the application come to the point of calling
                MySendData? Did you initiate this from a timer event or a button click?
                Per your earlier log file your initial communication worked, but it was

Paul Breneman wrote:
                  (snip)

MySendData is called through a Timer thread in a very difficult way and is
                  protected with critical sections but not over synchronize. In fact the timer
                  thread does not call MySendData directly, it calls a timing control which
                  decides if the MySendData is to be called (for example every 10 seconds).

Andreas,
                    (snip)

It sounds to me like TApdWinsockPort is being blocked (since it does not
                    create three separate threads in winsock mode). You'll probably need to
                    rework your logic since what worked in serial mode doesn't work for winsock.
                    --