Conversation

Error with TApdWinsockPort

(overview of excerpts from articles in conversation)

Newsgroup: turbocontrol.apro.general

# Lines
wrote on 02-Mar-2005:

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
35
  
Paul Breneman replied on 02-Mar-2005:

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.
20
    
Andreas Kanthak replied on 03-Mar-2005:

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
35
    
Andreas Kanthak replied on 03-Mar-2005:

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
314
      
Andreas Kanthak replied on 03-Mar-2005:

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.
70
        
Paul Breneman replied on 04-Mar-2005:

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
26
          
Andreas Kanthak replied on 04-Mar-2005:

Paul,
          (snip)

yes, i am using loops to process incoming data. Just like
          FCom.Putblock()
          repeat
          application.processmessages;
23
            
Paul Breneman replied on 04-Mar-2005:

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
24
            
Paul Breneman replied on 04-Mar-2005:

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
54
              
Paul Breneman replied on 04-Mar-2005:

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).
              --
15
      
=?ISO-8859-15?Q?Michael_K=F6hler?= replied on 07-Mar-2005:

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
71
        
=?ISO-8859-15?Q?Michael_K=F6hler?= replied on 07-Mar-2005:

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
8
          
Andreas Kanthak replied on 07-Mar-2005:

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

Thank you for the hint. I will check this.
          Andreas
          
15
        
Andreas Kanthak replied on 07-Mar-2005:

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?
35
              
Andreas Kanthak replied on 04-Mar-2005:

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
64
                
Paul Breneman replied on 04-Mar-2005:

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
19
                  
Andreas Kanthak replied on 04-Mar-2005:

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).
35
                    
Paul Breneman replied on 04-Mar-2005:

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.
                    --
23
FYI: Phrase searches are enclosed in either single or double quotes
 
 
Originally created by
Tamarack Associates
Fri, 29 Mar 2024 08:00:09 UTC
Copyright © 2009-2024
HREF Tools Corp.