11/18/09 - A major update brings our collection to over 1,350 manuals for 115 brands.
11/04/09 - New features, hundreds of 2-way and RS-232 modules, plus a web browser for the MX-6000.
9/04/09 - Latest activity-based model features a color screen at an economical price.
9/03/09 - * OK, one string – you may have to learn something!
8/22/09 - As it turns out, those who do not learn from history... still won't repeat it.
|
|
 |
|
|
The following page was printed from RemoteCentral.com:
| Topic: | RU990 Jumps and delays This thread has 32 replies. Displaying posts 16 through 30. |
|
| Post 16 made on Sunday September 20, 2009 at 09:33 |
Mark4323 New Member |
Joined:
Posts: | September 2009
20 |
|
|
|
On September 18, 2009 at 09:23, makitamark said...
the file you've sent me has 16 delays of 0.6s each, so just shy of 10sec total, is that the total delay you need?
No, I need near 20 seconds. When I run it on the RU990 sometime it works - issues the jump and when the jump is finished issues the delay. Sometimes it seems to go into parallel processing where the jumps do their own thing and the delays and codes are another (if that makes sense).
|
|
| Post 17 made on Sunday September 20, 2009 at 12:17 |
Ernie Bornn-Gilman Elite Member |
Joined:
Posts: | December 2001
12,933 |
|
|
Lyndel,
do commands take some more or less standard time?
On September 15, 2009 at 08:28, Mark4323 said...
...If each jump takes .5 sec....
This phrase jumped out at me when I read this thread. I've never seen any definition of the amount of time it takes for a command, start to finish.
I'd think that Mark's macro would look pretty much like a rapid succession of page flips because the flips take very little time.
On September 15, 2009 at 08:45, Jasonvp said...
22 X 0.2 = 4.4 seconds
Increase the Delay.
Makes sense to me.
The time taken for Jumps has no relevance.
I don't understand why you say this. If it takes 0.1 seconds for a jump and for the panel to display, then that's definitely part of the time for the macro. If it takes a half second, as Mark states or posits, I don't know which, then the macro would take much longer.
Jason, are you saying that the macro will do the page flips sequentially, but the part of the remote that issues the commands will ignore the time required for page flips and will just jump past the flips, do only the delays, and then issue the command? Thinking that through, I now see what Mark means by some kind of parallel processing -- it seems to him that there's a time constant for the command, where only the delays are counted, and a different time constant for the flipping of pages, where the time for the pages to flip PLUS the delays are counted. That would result in the command being issued before all the pages have flipped, and it's not the behavior I'd expect or have seen. But I've never done twenty flips, either.
Lyndel, someone mentions that the macro times seem to vary. Can you comment on that, letting us know what conditions there are on these variations, if you know them?
Thanks.
Last edited by Ernie Bornn-Gilman on September 20, 2009 12:24.
|
I have ACTUALLY said this a thousand times: We can't help you much without the make and model of everything involved in the problem! Unless you want a vague answer. Or none. Your move. |
|
| Post 18 made on Sunday September 20, 2009 at 12:23 |
makitamark Active Member |
Joined:
Posts: | April 2004
506 |
|
|
reading other threads on this it would seem that limitatations in the Pronto's processing mean that the jumps do indeed have an effect upon the time taken to execute the total macro.
removing all the delays and just having the 18 or so page jumps still results in a 12 sec macro!
it's all to do with the amount of information on the actual pages to which you are jumping, i know the pages don't look complex but nonetheless they do require the Pronto to do some processing which does take time - 12sec in this case. not sure why the last ir command is anywhere other than right at the end of the macro though, i never found that when i tested it.
regards mark
|
|
| Post 19 made on Monday September 21, 2009 at 08:22 |
Mark4323 New Member |
Joined:
Posts: | September 2009
20 |
|
|
|
On September 20, 2009 at 12:23, makitamark said...
reading other threads on this it would seem that limitatations in the Pronto's processing mean that the jumps do indeed have an effect upon the time taken to execute the total macro.
removing all the delays and just having the 18 or so page jumps still results in a 12 sec macro!
it's all to do with the amount of information on the actual pages to which you are jumping, i know the pages don't look complex but nonetheless they do require the Pronto to do some processing which does take time - 12sec in this case. not sure why the last ir command is anywhere other than right at the end of the macro though, i never found that when i tested it.
regards mark
Usually the first time I run it on the Pronto it will be okay. Subsequent times it executes the IR code after the delays, not including the page jumps.
|
|
| Post 20 made on Monday September 21, 2009 at 10:40 |
makitamark Active Member |
Joined:
Posts: | April 2004
506 |
|
|
how about forgetting the delays alltogether and adding more page jumps until you have your full required delay?
or would the 'final' ir code be blasted out before the page jumps had completed?
i'm a little stumped on this, i've never used so many jumps, my 'please wait' pages only consist of 4 or 5 jumps.
i've always found the delays to be very accurate, even to the point of using the pronto to stop an electric proj screen at an exact spot every time (no bottom stops)
|
|
| Post 21 made on Tuesday September 22, 2009 at 08:13 |
Mark4323 New Member |
Joined:
Posts: | September 2009
20 |
|
|
|
On September 21, 2009 at 10:40, makitamark said...
how about forgetting the delays alltogether and adding more page jumps until you have your full required delay?
or would the 'final' ir code be blasted out before the page jumps had completed?
i'm a little stumped on this, i've never used so many jumps, my 'please wait' pages only consist of 4 or 5 jumps.
i've always found the delays to be very accurate, even to the point of using the pronto to stop an electric proj screen at an exact spot every time (no bottom stops)
Didn't think of that. I might try lots of page jumps. I will have to get a PVR that boots quicker!
|
|
| Post 22 made on Saturday September 26, 2009 at 18:57 |
texasbrit Founding Member |
Joined:
Posts: | December 2001
509 |
|
|
|
On September 21, 2009 at 10:40, makitamark said...
how about forgetting the delays altogether and adding more page jumps until you have your full required delay?
or would the 'final' ir code be blasted out before the page jumps had completed?
i'm a little stumped on this, i've never used so many jumps, my 'please wait' pages only consist of 4 or 5 jumps.
i've always found the delays to be very accurate, even to the point of using the pronto to stop an electric proj screen at an exact spot every time (no bottom stops)
It's not really a bug, it's because of the way the hardware/firmware works. I can make this happen every time in a test case. If I do ten jumps and ten delays, and then a beep, using jumps to fairly complex pages, and the delay is, say, 2 seconds, there is no problem. But if I reduce the delays to 0.1 seconds, the beep happens after about 1 second and the pages I jump to are still appearing. The macro is not ignoring the jumps - it seems to me what is happening is that the "display" function is running asynchronously from the macro. So when you say "jump to a page", the Pronto jumps to the page and puts the code to generate the display for that page in a buffer for the display routines to process. It does not wait for the display to paint before running the next step in the macro, it goes on to the next jump.
This is a very common issue in software development. In windows, for example, when you issue a print command, it does not go to the printer it goes to a spooler and if you modify the printer settings in the registry immediately after doing the print command, the document goes to the wrong printer.
The solution is either to have fewer longer days, or less complex pages for the jumps.
|
|
| Post 23 made on Sunday September 27, 2009 at 16:36 |
|
I have similar experiences with my system where I have a system on button which does several page jumps and finally a beep to say everything should be up. However, when the pronto is first programmed all will be fine but over a few days/weeks the page flips take longer and the final beep actually occurs midway through the sequence. The only way to get things working in the correct sequence again is to press the reset button or reprogram, there must be some kind of memory leak occuring somewhere.
|
|
| Post 24 made on Sunday September 27, 2009 at 22:53 |
Lyndel McGee RC Moderator |
Joined:
Posts: | August 2001
9,152 |
|
|
|
If you are using Database codes and not using the latest firmware, that may be the cause as there was a memory leak reported with use of DB codes that was supposed to have been fixed on latest F/W.
|
Lyndel McGee Philips Pronto Addict/Beta Tester View EscientPronto 1.0.2 Docs - [Link: mediafire.com] |
|
| Post 25 made on Monday September 28, 2009 at 13:33 |
|
Not using database codes and am running the fixed firmware :)
|
|
| Post 26 made on Monday September 28, 2009 at 23:01 |
texasbrit Founding Member |
Joined:
Posts: | December 2001
509 |
|
|
|
I am pretty sure this is not a memory leak, nothing to do with codes, it's simply that the display is painted from a buffer and the Pronto code just fills the buffer on a jump, it does not wait for the display to be painted. See my earlier post.
|
|
| Post 27 made on Monday October 5, 2009 at 04:17 |
Mark4323 New Member |
Joined:
Posts: | September 2009
20 |
|
|
So, I've just put in a lot of jumps (27!) and removed the delays. It works mostly. Sometimes the macro finishes before the PVR powers on and sometimes the other way round.
Occasionally, when I send the file to the Pronto, the issued code is issued at the beginning, or in the middle. I just have to keep reloading it until it's performing correctly. I don't know why it does this.
|
|
| Post 28 made on Saturday October 10, 2009 at 08:51 |
texasbrit Founding Member |
Joined:
Posts: | December 2001
509 |
|
|
|
On October 5, 2009 at 04:17, Mark4323 said...
So, I've just put in a lot of jumps (27!) and removed the delays. It works mostly. Sometimes the macro finishes before the PVR powers on and sometimes the other way round.
Occasionally, when I send the file to the Pronto, the issued code is issued at the beginning, or in the middle. I just have to keep reloading it until it's performing correctly. I don't know why it does this.
I think you are tackling this problem the wrong way round. based on my testing, and how the pronto seems to work, you need less jumps, less complex pages and more delays.
As an example. Suppose your code looks like:
Jump to page A
Jump to page B
Jump to page C
Jump to page D
perform an action
The Pronto will perform the jump to page A, then put the data for page A in the display buffer, and then jump to page B, without waiting for the display to write. Then it will perform the jump to C, and so on. So if the pages are complex and take a long time to be written to the display, the Pronto will get to the "perform an action" before all the pages are written to the display. I can make this happen every time with some test pages.
The solution (which I have also tested) is to make sure that after each jump there is a delay that is long enough to allow the display to be written, so the jumps don't happen faster than the display is able to write. So if you are trying to do a one-second countdown (for example) you need to either make the display pages very simple, or change to do a two-second countdown (or maybe longer - it depends on the complexity of the display pages).
Try it and post back.
|
|
| Post 29 made on Saturday October 17, 2009 at 01:36 |
Mark4323 New Member |
Joined:
Posts: | September 2009
20 |
|
|
|
I actually started out that way. I had jumps with a 4 second delay between each. That wasn't working and someone suggested to just have jumps with no delays.
|
|
| Post 30 made on Sunday October 18, 2009 at 07:30 |
texasbrit Founding Member |
Joined:
Posts: | December 2001
509 |
|
|
|
It works fine for me, I use the technique all the time.
|
|
 |
Before you can reply to a message... |
You must first register for a Remote Central user account - it's fast and free! Or, if you already have an account, please login now. |
Please read the following: Unsolicited commercial advertisements are absolutely not permitted on this forum. Other private buy & sell messages should be posted to our Marketplace. For information on how to advertise your service or product click here. Remote Central reserves the right to remove or modify any post that is deemed inappropriate.
|
|
