Yes, that's exactly what I get.....the first time.
Do what would you make of the fact that it appears to work if I run the macro again a few seconds later (i.e., just push the button again after the first iteration failed)? I can only think of a couple possibilities: (1) a quirk in the Nevo IF function causes it to "pick up where it left off" after the command fails, or (2) sending a request to the Pioneer TV in STANDBY mode doesn't get a response, but somehow "primes" it to communicate for a few seconds.
I don't have HyperTerminal in Win7 and I haven't looked for an alternative. Everything I'm trying to do involves serial control of Pioneer plasmas with a Nevo remote, so all my testing has been through the remote (and an NC-50).
I'm just using a couple test pages, so there's really no job file to speak of, and the only codes required are Pioneer's serial codes.
After further testing, I believe the strange performance I'm seeing with the IF command is due to undocumented quirks in Pioneer's serial protocol. The timing of the commands and, more importantly, the behavior of the panels in STANDBY mode aren't addressed, and they seem to be key here.
Here's an example of a little macro I came up with that works consistently to check the Pioneer's power state and power it up from STANDBY:
SEND [PIP Status] Pioneer 151 DELAY 400ms IF [Input Status] Pioneer 151 returns [Input Status = 4] ⇒ THEN
⇒ ELSE ....Send [Power On] Pioneer 151
The initial command only seems to "activate" the display for communication...it never generates any response and it can be any kind of status request. I had to play around a lot with both that initial delay and the global serial delay for the Pioneer device. If the delay after the "wake-up" command is <400ms, the macro stalls, and the device delay must be at least 250ms.
So this whole macro takes about 2.5sec to turn on the panel from STANDBY. I'm still playing with it a bit to see if I can cut that down. Seems picky, I know, but the impetus for this effort came from the Pioneers' very long delay from power-up, which results in unnecessarily time-consuming start-up macros when the panel's already on.
Can you elaborate a little on how that would work? If you think it's easier and faster (and hopefully more reliable) than what I'm trying to do, I'll certainly give it a shot.
Specifically, I'm wondering how a widget could get/use feedback from the display faster, when the heart of the issue is that this panel just doesn't seem to offer any direct way to ascertain power status when it's in STANDBY.
Brody - I see what you are trying to accomplish. Possibly you are trying the "alternate" if-then-else programming for another reason/purpose?
However, I thought the Pioneer FD-150/151 series had discrete off codes?
I have a pronto ccf file directly from Pioneer which has codes for Power Toggle, On and off. I have not investigated the actual hex to see if it is different but the ccf file came from Pioneer's site directly and they are usually quite accurate.
Want to try and paste this into NSP and see if it works natively?
Hi Dave...thanks for the response. The Pioneers do indeed have discrete on/off commands. They also have a very long (~14 sec) power-up sequence before they accept the next command. So it's just the typical scenario where you want to know the power status of the panel and avoid that long delay whenever the panel is already on.
But the two easy approaches, a direct status request or using a voltage/video sensor, aren't possible with these panels. You can't directly query the panel when it's in STANDBY, and there are no outputs for the sensors.
So currently, "dumb" start-up macros for all sources have to incorporate this long delay. I was looking to construct IF commands that might circumvent this inconvenience by assessing the panels' power status indirectly.
I'm about 80% there. It's still no substitute for the speed and simplicity of a direct status request, but it'll be an improvement.
why not just use variables and track the power status yourself? i used to use xantech sensors and nevo voltage sensors on every tv before NSP3.0 came out, but with the new global flags, i found them to be a waste of money.
I actually just started playing with that option. Ultimately, I'll go with whatever proves to be fastest and most reliable.
if you can keep the customers hands off the original remote, and the power button on the TV itself, and they don't lose power in a thunderstorm, then it will be perfectly reliable. It is also extremely easy to program.
Well, those are big ifs....! ;) I don't really like that the global flag approach relies on programming to keep track of the power state rather than just acquiring it directly. While it seems pretty workable and reliable in "normal" usage, some setups might take a lot of troubleshooting (for me anyway ;)) to try and cover all bases.
One of the applications here is a real challenge- the user does a lot of rapid switching between sources, doesn't always use the same approach to do it, and often manually turns components on & off (though not the panel itself). He will literally load 4-5 movies in different players so he can jump from scene to scene....when he changes a disc, he sometimes uses the power buttons to close loading trays. (And then uses the start-up macro to turn the player back on.) To change inputs, he might use the processor's input page, the Home Page macro (meant to start-up from scratch), or just manually turn the knob while he's up changing discs.
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.