PDA

View Full Version : Flushing the queue on a serial driver



toml0006
May 23rd, 2006, 12:29 PM
How would I go about flushing a queue if it reaches a certain size on the serial.queued class? I have the serial driver for the Denon 3805 posted in the plugins download area, and it seems to have an issue with recieving commands once in a while. It will miss a response from the reciever and then queue any subsequent actions. If I reset the lua scripting console, everything is fine again. What I would like is if queue reaches a certain size (say 10) set the queue to 0 and start sending commands again.

Promixis
May 23rd, 2006, 10:18 PM
How would I go about flushing a queue if it reaches a certain size on the serial.queued class? I have the serial driver for the Denon 3805 posted in the plugins download area, and it seems to have an issue with recieving commands once in a while. It will miss a response from the reciever and then queue any subsequent actions. If I reset the lua scripting console, everything is fine again. What I would like is if queue reaches a certain size (say 10) set the queue to 0 and start sending commands again.

The missed response should not matter. ie it times out and stops waiting for a response, and sends the next command.

Are you sure this is the problem>?

toml0006
May 24th, 2006, 12:48 AM
well, the lua console will say that command is number 'x' in the queue, and it doesn't time out (at least in a reasonable amount of time <10 seconds) that I know of...

Just keeps adding commands to the queue until it reaches 100 and which point the queue is full. For example, a slider linked to the volume will very quickly fill the queue if this happens. Then I am unable to send commands to this device.

Rob H
May 24th, 2006, 04:27 AM
I've seen this myself with my Denon 2805. I just haven't quite figured out what is going wrong, but I have a feeling that it's related to the retry code. I think I may have mentioned this to you before Mike. The current retry code is broken, if a send fails for some reason, it requeues the command and increments self.RetryCount which sounds fair. However, SendQueCheck() then calls SendCommand() which sets self.RetryCount back to 0. Accordingly self.RetryCount never exceeds 1.

Mind you, this only happens if self.RetryOnError is true, which it isn't by default.

Promixis
May 24th, 2006, 06:31 AM
Rob, the retry code is broken and not tested. AFAIK, it is always OFF?

Rob H
May 24th, 2006, 06:52 AM
It certainly defaults to off, but it may have been enabled in the Denon serial device.

toml0006
May 24th, 2006, 02:20 PM
I just checked the Denon device

print (Denon.RetryOnError)

false

So thats not it...

Promixis
May 24th, 2006, 02:33 PM
Can you post the denon.lua file you are using?

toml0006
May 24th, 2006, 02:42 PM
Its the same as the one posted in the Girder Plugin Downloads section...

Promixis
May 24th, 2006, 02:47 PM
how easy can you make the errror happen?

Promixis
May 24th, 2006, 02:52 PM
I've seen this myself with my Denon 2805. I just haven't quite figured out what is going wrong, but I have a feeling that it's related to the retry code. I think I may have mentioned this to you before Mike. The current retry code is broken, if a send fails for some reason, it requeues the command and increments self.RetryCount which sounds fair. However, SendQueCheck() then calls SendCommand() which sets self.RetryCount back to 0. Accordingly self.RetryCount never exceeds 1.

Mind you, this only happens if self.RetryOnError is true, which it isn't by default.

Rob, there is some ugly coding going on in the Responses table... reassigning every event... not good. Possible threading issues.

Rob H
May 24th, 2006, 03:12 PM
Is this in the Denon plugin?

toml0006
May 24th, 2006, 03:12 PM
Yes, it is. I agree with the Responses code, its a mess; but I figured since it was posted it must be ok.

Rob H
May 24th, 2006, 03:26 PM
Sorry, I missed the last couple of messages on the previous page.

Yes, those should really be in the main body of the device, and not in the ReceiveResponse function.

toml0006
May 24th, 2006, 04:05 PM
Should that solve the problem?
I ask because I am away from my setup for a few days.

Rob H
May 24th, 2006, 04:18 PM
Not sure that it will solve the problem, but it should make the ReceiveResponse method a fair bit faster.

toml0006
June 3rd, 2006, 11:19 PM
Back to my original question, what variable contains the queue count information, and how do I reset it?

I know that when the queue reaches say 10 queued commands, there is an error somewhere and I need to reset the queue so that commands can go through again.

GadgetComa
June 12th, 2006, 09:54 PM
I'm seeing similar behavior with Girder 4.0.4.11 and the Denon plugin. I'm using it unaltered from the original version (I'd have no clue what to change anyway!). Is there some change that needs to be made to this plugin? FYI. This problem started for me when I upgraded from 4 to 4.0.4.11.

Thanks.

- Leon

Promixis
June 13th, 2006, 11:59 AM
Ok, just too clarify, both of you are having the same problem with the queue filling up?

GadgetComa
June 13th, 2006, 08:01 PM
Yes. The queue is filling up for me.

toml0006
June 14th, 2006, 11:55 AM
Me too, however it doesn't just automatically fill up all the time. It happens more often when you "flood" the driver with commands (like a volume slider sliding rapidly back and forth). I did come up with a kludge:

I just used the full syntax for the sendCommand() function: self.SendCommand(string, self.ReceiveResponses, false, true)
where false does not put the command at the head of the queue (thus queuing any previous commands - BAD) and true forces the command through.

Personally I don't like queuing my commands, because I will occasionally get delayed responses causing me to try again (think a volume slider here) until I realize that something is wrong. I would rather have whatever command I am sending right now to be sent with priority.

Rob H
June 21st, 2006, 01:47 PM
Can you guys who are having problems with the serial queue try this version of plugins\serial\init.lua - make a backup of your existing one first.

Promixis
June 26th, 2006, 11:37 AM
guys, did Rob's update help?

toml0006
June 26th, 2006, 05:36 PM
I will not know until this weekend when I go try it in the new installation... I hope so my clients are pretty annoyed right now!

GadgetComa
June 26th, 2006, 09:10 PM
Sorry for the delay. The fix seemed to help. Commands are still queueing (they never did that before), but the queue is quickly draining and none of the commands are being dropped.

Thanks for the quick fix.

- Leon

Rob H
June 27th, 2006, 04:35 AM
Great, thanks for the update.