Page 9 of 9 FirstFirst ... 789
Results 81 to 88 of 88

Thread: 508 problems

  1. #81
    Join Date
    Jan 2004
    Location
    The Netherlands
    Posts
    2,140

    Default

    hmm...

    I've now got problems with another serial plugin (worked fine in 507)

    Code:
     
    local device = serial.Classes.Queued:New({
      Name = "Kettler Treadmill",
      Description = "Kettler Boston XL Treadmill",
      BaudRate = 9600,
      Parity = 0,
      StopBits = 0, -- 0 = 1 stopbit.
      DataBits = 8,
      FlowControl = 'N',
      GlobalName = 'Kettler',
      IntraCharacterDelay = 0, --delay between characters
      CallbackType = serial.CB_TERMINATED,
      ReceiveTerminator = '\r\n',
      SendTerminator = '\r\n',
      IncompleteResponseTimeout = 2000,
      NoreponseTimeout = 2000,
      LogLevel = False,
     
      Initialize = function (self)
        self.MyMutex = thread.newmutex ()
        self.Serial:RxClear()
        return serial.Classes.Queued.Initialize (self)
      end,
     
      RequestStatus = function (self)
        self.MyMutex:lock ()
        self:SendCommand ("ST")
        while self.ResponsePending do
          win.Sleep(50)
        end
        local reply = self.Reply
        self.MyMutex:unlock ()
        return handlestatusdata (reply)
      end,
     
      ReceiveResponse = function ( self, data, code )
        if math.band (code,serial.RXCHAR) > 0 then
          self.Reply = data;
        else
          self.Reply = nil;
        end;
        serial.Classes.Queued.ReceiveResponse (self,data,code)
      end,
    }
    )
    serial.AddDevice (device)
    receiving small messages works ok
    ACK 10 13 works ok,
    the data I see is just ACK (without lf\cr as expected)

    but bigger messages (about 40 chars) now cause incomplete response timeouts (increasing the timeout has no effect)
    and the data string in ReceiveResponse is terminated with ascii 10 13...
    the lf\cr characters should not be there...

    there are no nulls in these messages

    Marcel
    Last edited by mhwlng; January 16th, 2007 at 09:36 AM.

  2. #82
    Join Date
    Jan 2004
    Location
    The Netherlands
    Posts
    2,140

    Default

    ok... I've found the problem

    apparently the ACK messages end in 13\10 and the bigger messages end in 10\13

    so it is normal that ReceiveTerminator = '\r\n' only works for the ACK messages...
    (just using ReceiveTerminator = '\r' or ReceiveTerminator = '\n' also doesn't work b.t.w)

    The strange thing is, why it was working fine in 507 ?

    anyway, I've changed to the same trick as the w800 plugin..

    CallbackType = serial.CB_FIXEDLENGTH,
    ReceiveFixedLength = 100,

    and then use the incomplete timeout...

    that seems to work ok

    Marcel

  3. #83
    Join Date
    May 2004
    Location
    Cardigan, UK
    Posts
    9,278

    Default

    Not sure I like the use of the win.Sleep in there.

    Does RequestStatus have to be synchronous?
    --Rob

  4. #84
    Join Date
    May 2004
    Location
    Cardigan, UK
    Posts
    9,278

    Default

    In 507, I think I'm right in saying that it was treating the characters of the receive terminator as alternates rather than a sequence.
    --Rob

  5. #85
    Join Date
    Jan 2004
    Location
    The Netherlands
    Posts
    2,140

    Default

    In 507, I think I'm right in saying that it was treating the characters of the receive terminator as alternates rather than a sequence.
    ah, ok. that explains it..

    Does RequestStatus have to be synchronous?
    unfortunately yes...
    I've actually got 10 or so similar functions
    do you have a better way to do this ?

    marcel
    Last edited by mhwlng; January 16th, 2007 at 09:59 AM.

  6. #86
    Join Date
    May 2004
    Location
    Cardigan, UK
    Posts
    9,278

    Default

    I'd just try to avoid making them synchronous and either trigger events when the response came in or use a publisher.

    You might be able to use coroutines, but I've not really investigated those very deeply.
    --Rob

  7. #87
    Join Date
    Jan 2004
    Location
    The Netherlands
    Posts
    2,140

    Default

    I have 10 or so functions that send a command to the device and wait for a reply (could be ack/nak/data/nothing)

    some of these functions are called from a thread, others from communication server events...

    e.g. this starts the whole thing off (heartrate controlled treadmill) :

    Code:
     
       if (Kettler:RequestReset()=="ACK") then
         win.Sleep(100);
        if (Kettler:RequestCommandMode()=="ACK") then
         gir.LogMessage('TreadMill', "Starting treadmill", 0)
         Kettler:RequestSpeed(minspeed)
         Kettler:RequestIncline(minincline)
           thread.newthread (PollData,{})
          else
            gir.LogMessage('TreadMill', "Could not switch to command mode", 1)
          end
         else
           gir.LogMessage('TreadMill', "Could not reset", 1)
         end
       else
        gir.LogMessage('TreadMill', "Error Communicating with treadmill", 1)
       end
    sometimes I need to call >4 functions in a row, one after the other, all depending on the reply of the previous function...

    using events or a state-machine in ReceiveResponse is theoretically possible, but would make it much more complex (for me at least :-) )

    I don't know anything about coroutines....

    Marcel

  8. #88
    Join Date
    May 2004
    Location
    Cardigan, UK
    Posts
    9,278

    Default

    Well, as long as it works
    --Rob

Page 9 of 9 FirstFirst ... 789

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •