开云体育

Thanks! I'll be trying this next week.

--- In Crestron@..., Eric Williams <ewilliams0305@> wrote:

I just setup my mms using the media player object. Works pretty well, few txt glitches and searching problems that need to worked out. The mms need a firmware update that may not show up on its configuration GUI. If not you'll need to telnet into the server and send the command "autoupdate hotfix"

Once that's complete under the source tab you see a place for an iP Id and processor IP address.

Thought I would save some folks some trouble.

Eric Williams
Head of Engineering
ABE Networks
240-604-4771

[Non-text portions of this message have been removed]

i have created a SB project where i call the Denon app from withing the Crestron code.
i can't find a back button on the Denon app - just me or am i missing something?

mark

So I put the scaling into the simpl+ module. Tested and still sent command out issuing a change on init.

I then commented out the Abuf feeding the module and no command sent at init....

It seems to be putting a 0 onto the input once the enable pin is high.
(10 sec after init as I already have a delay)

wierd....


--- In Crestron@..., Tray Schaeffer <trayschaeffer@> wrote:

+1 for what Jason just said. I would add that you should also confirm that
there is nothing in MAIN that would alter output values at program start.

Tray

-----Original Message-----
From: Jason Melvin
Sent: Friday, May 17, 2013 10:26 AM
To: Crestron@...
Subject: Re: [Crestron] Re: Simpl + Change Analog

In your case, since you already have the SIMPL+ module, I agree it makes
more sense to either add an enable line or a simple delay before enabling
the CHANGE event. You could block it by testing against the enable input or
against an internal variable.


On Fri, May 17, 2013 at 9:58 AM, constantcharge2
<constantcharge@>wrote:

**


Ok so looking at wrapper I have a Abuf on input already. that I have a 10
sec delay on before enable but inside this wrapper I have a scaler to
convert values before simpl+ module. Could this be throwing out a value at
init....
maybe I could do this in simpl+ instead....


--- In Crestron@..., Jason Melvin <jwmelvin@> wrote:

Oh, I think I get it now. From the ABUF help:
----

Analog signals (2-Series and X-Series)

Sets the analog value that will be propagated to the corresponding
output
with each rising edge of <enable>. If the input/output pair contains the
same analog value, the analog input will still be propagated.

If an analog input changes value or is re-propagated while <enable> is
high, the value will only be propagated to the corresponding output if

the

output has a different value.

----

So, ABUF will prevent a repeating loop when held enabled but SBUF

prevents

propagating when enabled. I used SBUF because when I enable the buffer,
I
don't want a signal sent. That said, I could probably tolerate analogs
propagating once the input value is correct, or could use an AOS to
determine when to propagate a real signal. Thanks for the pointers
Steve.


On Fri, May 17, 2013 at 9:32 AM, Jason Melvin <jwmelvin@> wrote:

Hm, I thought the behavior was exactly the opposite, because of the
statement in ABUF help: "If the input/output pair contains the same

analog

value, the analog input will still be propagated."

I have, however, seen a loop created with SBUF and analog signals, so

the

same signal continuously propagages and repropagates. Perhaps there is

some

subtlety that I am missing.


On Fri, May 17, 2013 at 8:57 AM, Steve Kaudle <skaudle@> wrote:

**

A buffer can certainly help, but I'd typically recommend using a ABUF

(as

opposed to the SBUF) and latching the enable only after an
honest-to-goodness change has been generated in the logic. This way

you

eliminate what is probably a superfluous Change event from running
automatically (either at boot or sometime thereafter), and you have

the

added benefit of the ABUF's ability to eliminate unwanted

repropigations

when the output already matches the input, further reducing the

number of

unwanted SIMPL+ Change events.


-----Original Message-----
From: Crestron@... [mailto:Crestron@...] On
Behalf
Of Jason Melvin
Sent: Friday, May 17, 2013 8:22 AM
To: Crestron@...
Subject: Re: [Crestron] Simpl + Change Analog

I use an SBUF in SIMPL for this, which gets enabled after ~10 sec on

boot.

That way, the initially 0 analog signals don't cause switchers to

change

sources before the old settings get recalled from memory. The SBUF

blocks

serial and analog signals that would otherwise go to devices. Also, a

BUF

signal prevents the program from triggering motion-detector logic for
contact-closure-output detectors, which have inverted logic due to
the
pullup resistor.

On Fri, May 17, 2013 at 7:20 AM, Steve Kaudle <skaudle@> wrote:

**

The only SIMPL+ 'event' that will automatically run when the
program
is initialized is the Main, so if your Change is running at bootup
it's because something is causing the analog connected to the input

to

propagate a zero at bootup (IE: the issue is in your SIMPLWindows
code).

There's nothing wrong with encapsulating the output calculation in

an

IF statement to prevent a transition of the output you don't want,

but

it won't do anything to prevent the unnecessary SIMPL+ thread from
being generated.
I'd concentrate my efforts on preventing the input analog from
propagating at bootup.

From: Crestron@... [mailto:Crestron@...] On
Behalf Of constantcharge2
Sent: Friday, May 17, 2013 2:33 AM
To: Crestron@...
Subject: [Crestron] Simpl + Change Analog


Hi All,

Have a issue that has me stumped.
using the below

Change Analog_in
{
Print("Analog_in %d &#92;n",Analog_in);
Level$ = IToHex(Analog_In);
}

When program initializes it enters this module and outputs unwanted
code eg sets hex levels to 0. (turns off amp's) Is there a way to

stop

this happening?

my only way of fixing this currently is to do a feedback loop eg

Change Analog_in
{
Print("Analog_in %d &#92;n",Analog_in);
if (Analog_in <> Current_Level)
{
Level$ = IToHex(Analog_In);
}
}

[Non-text portions of this message have been removed]

------------------------------------

*

****

Check out the Files area for useful modules, documents, and drivers.

A contact list of Crestron dealers and programmers can be found in
the
Database area.

*

****Yahoo! Groups Links

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]



------------------------------------



Check out the Files area for useful modules, documents, and drivers.

A contact list of Crestron dealers and programmers can be found in the
Database area.
Yahoo!
Groups Links

+1 for what Jason just said. I would add that you should also confirm that
there is nothing in MAIN that would alter output values at program start.

Tray

-----Original Message-----
From: Jason Melvin
Sent: Friday, May 17, 2013 10:26 AM
To: Crestron@...
Subject: Re: [Crestron] Re: Simpl + Change Analog

In your case, since you already have the SIMPL+ module, I agree it makes
more sense to either add an enable line or a simple delay before enabling
the CHANGE event. You could block it by testing against the enable input or
against an internal variable.


On Fri, May 17, 2013 at 9:58 AM, constantcharge2
<constantcharge@...>wrote:

**


Ok so looking at wrapper I have a Abuf on input already. that I have a 10
sec delay on before enable but inside this wrapper I have a scaler to
convert values before simpl+ module. Could this be throwing out a value at
init....
maybe I could do this in simpl+ instead....


--- In Crestron@..., Jason Melvin <jwmelvin@> wrote:

Oh, I think I get it now. From the ABUF help:
----

Analog signals (2-Series and X-Series)

Sets the analog value that will be propagated to the corresponding
output
with each rising edge of <enable>. If the input/output pair contains the
same analog value, the analog input will still be propagated.

If an analog input changes value or is re-propagated while <enable> is
high, the value will only be propagated to the corresponding output if

the

output has a different value.

----

So, ABUF will prevent a repeating loop when held enabled but SBUF

prevents

propagating when enabled. I used SBUF because when I enable the buffer,
I
don't want a signal sent. That said, I could probably tolerate analogs
propagating once the input value is correct, or could use an AOS to
determine when to propagate a real signal. Thanks for the pointers
Steve.


On Fri, May 17, 2013 at 9:32 AM, Jason Melvin <jwmelvin@> wrote:

Hm, I thought the behavior was exactly the opposite, because of the
statement in ABUF help: "If the input/output pair contains the same

analog

value, the analog input will still be propagated."

I have, however, seen a loop created with SBUF and analog signals, so

the

same signal continuously propagages and repropagates. Perhaps there is

some

subtlety that I am missing.


On Fri, May 17, 2013 at 8:57 AM, Steve Kaudle <skaudle@> wrote:

**

A buffer can certainly help, but I'd typically recommend using a ABUF

(as

opposed to the SBUF) and latching the enable only after an
honest-to-goodness change has been generated in the logic. This way

you

eliminate what is probably a superfluous Change event from running
automatically (either at boot or sometime thereafter), and you have

the

added benefit of the ABUF's ability to eliminate unwanted

repropigations

when the output already matches the input, further reducing the

number of

unwanted SIMPL+ Change events.


-----Original Message-----
From: Crestron@... [mailto:Crestron@...] On
Behalf
Of Jason Melvin
Sent: Friday, May 17, 2013 8:22 AM
To: Crestron@...
Subject: Re: [Crestron] Simpl + Change Analog

I use an SBUF in SIMPL for this, which gets enabled after ~10 sec on

boot.

That way, the initially 0 analog signals don't cause switchers to

change

sources before the old settings get recalled from memory. The SBUF

blocks

serial and analog signals that would otherwise go to devices. Also, a

BUF

signal prevents the program from triggering motion-detector logic for
contact-closure-output detectors, which have inverted logic due to
the
pullup resistor.

On Fri, May 17, 2013 at 7:20 AM, Steve Kaudle <skaudle@> wrote:

**

The only SIMPL+ 'event' that will automatically run when the
program
is initialized is the Main, so if your Change is running at bootup
it's because something is causing the analog connected to the input

to

propagate a zero at bootup (IE: the issue is in your SIMPLWindows
code).

There's nothing wrong with encapsulating the output calculation in

an

IF statement to prevent a transition of the output you don't want,

but

it won't do anything to prevent the unnecessary SIMPL+ thread from
being generated.
I'd concentrate my efforts on preventing the input analog from
propagating at bootup.

From: Crestron@... [mailto:Crestron@...] On
Behalf Of constantcharge2
Sent: Friday, May 17, 2013 2:33 AM
To: Crestron@...
Subject: [Crestron] Simpl + Change Analog


Hi All,

Have a issue that has me stumped.
using the below

Change Analog_in
{
Print("Analog_in %d &#92;n",Analog_in);
Level$ = IToHex(Analog_In);
}

When program initializes it enters this module and outputs unwanted
code eg sets hex levels to 0. (turns off amp's) Is there a way to

stop

this happening?

my only way of fixing this currently is to do a feedback loop eg

Change Analog_in
{
Print("Analog_in %d &#92;n",Analog_in);
if (Analog_in <> Current_Level)
{
Level$ = IToHex(Analog_In);
}
}

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]

------------------------------------

*

****

Check out the Files area for useful modules, documents, and drivers.

A contact list of Crestron dealers and programmers can be found in
the
Database area.

*

****Yahoo! Groups Links

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]



------------------------------------



Check out the Files area for useful modules, documents, and drivers.

A contact list of Crestron dealers and programmers can be found in the
Database area.
Yahoo!
Groups Links

That's not wrong - that's just the IPv86 format of the address. Damn Crestron trying to get ahead of the curve again.

- Chip

--- In Crestron@..., Lincoln King-Cliby <lincoln@...> wrote:

For example...

TPS-4L>testdns www.controlworks.com
IPAddress = 4294967213.4294967233.052.4294967208

Error encountered: The specified path, file name, or both are too long.
The fully qualified file name must be less than 260 characters, and the
directory name must be less than 248 characters.

Please make sure you specified a valid directory path.

Chip,

Is there a way around this? I like this search feature and it does work,
only issue it only searches a few folders as most of my programs are
over the limit.

Thanks, cyberbri

The splash screen sits behind whatever window I open over it.... I don't see the issue.

For example...

TPS-4L>testdns www.controlworks.com
IPAddress = 4294967213.4294967233.052.4294967208

The Crestron module is pretty awesome. It's really simple, just double
check your work. Make sure your DNS servers are working on your processor
and check your gateway. Because it works really well. Use the example
program to get you started.

Sent from my eMail.

On May 17, 2013, at 5:06 PM, Chris <chrmac68@...> wrote:



Any one got a good weather module with a forecast and some graphic feedback
such as images to show conditions..
Weather channel stopped the feed and i cant get a connection using
Crestrons Module.








------------------------------------




Check out the Files area for useful modules, documents, and drivers.

A contact list of Crestron dealers and programmers can be found in the
Database area.
Yahoo!
Groups Links

How big of a deal is it really? ;-) It's only up for 2-3 seconds.


On May 16, 2013, at 7:51 PM, Chip <cfm@...> wrote:

I thought the SIMPL Windows splash was annoying.

This is exponentially worse.

Clearly the people that implemented this thinking it was a good idea have never tried to use more than one application at a time on their computers.

- Chip

--- In Crestron@..., Marc Nield <nieldm@> wrote:

Is it me or is that new, pretty Toolbox startup splash more annoying than useful? You start an upload or a compile and then think "oh I'll start Toolbox" then you can't see what's going on for as long as it takes Toolbox to start coz the damn splash hogs the screen and won't go away.

Like I said, maybe I am doing something wrong, but if I am not I can't believe I am alone in my grumpiness....

[Non-text portions of this message have been removed]

How big of a deal is it really? ;-) It's only up for 2-3 seconds.


On May 16, 2013, at 7:51 PM, Chip <cfm@...> wrote:

I thought the SIMPL Windows splash was annoying.

This is exponentially worse.

Clearly the people that implemented this thinking it was a good idea have never tried to use more than one application at a time on their computers.

- Chip

--- In Crestron@..., Marc Nield <nieldm@> wrote:

Is it me or is that new, pretty Toolbox startup splash more annoying than useful? You start an upload or a compile and then think "oh I'll start Toolbox" then you can't see what's going on for as long as it takes Toolbox to start coz the damn splash hogs the screen and won't go away.

Like I said, maybe I am doing something wrong, but if I am not I can't believe I am alone in my grumpiness….

Um, no - that's not what they're talking about (at least not beyond the
first post). Some RS-232 protocols have a command that simply takes a
number as the parameter and the number is mapped to a button on the IR
remote. Just for a completely random example, something like
"IRCOMMAND_45&#92;n" - that command has pretty much no correlation at all to
the actual IR command which consists of a pattern of on / off pulse
timings. At best, the correlation might be that the command ID's are the
same as what the IR signals ultimately represent. But there's no
"standard" for this sort of conversion and no automated tool to do it as it
will generally be completely different from device to device. The bottom
line is that if you want to control a device with RS-232, knowing the IR
commands really isn't going to get you anywhere - you need to track down
the RS-232 protocol.

Geoff

On Fri, May 17, 2013 at 5:17 PM, jhuerta2803 <jav-gen@...> wrote:

**


Isn't that what this is talking about here?


I just thought someone had created a tool to "integrate" this
automatically.

[Non-text portions of this message have been removed]

Thanks for the suggestions - the XDT is also discontinued, however.

-----Original Message-----
From: Crestron@... [mailto:Crestron@...] On Behalf Of programmix
Sent: Wednesday, May 15, 2013 8:29 PM
To: Crestron@...
Subject: [Crestron] Re: OT: AM/FM Tuner

Xantech XDT Dual Tuner
NAD C 426
Factor Electronics VT-1 and VT-4
Leaf LDT2

AD

--- In Crestron@..., Paul Cunningham <paul.cunningham@> wrote:

I'm looking for a non-Crestron radio tuner that is controllable with feedback via RS-232 or IP, and offers a standard amount of presets. If it has Sirius/XM capability that's great too but not essential. I've used these models but they've all been or about to be discontinued: Integra TUN-3.7, Parasound zTuner, Xantech XT1.

The ADA Quadritune looks like a [pricey] winner, but I am open to suggestions both residential and commercial alike.

Thanks
PC

------------------------------------



Check out the Files area for useful modules, documents, and drivers.

A contact list of Crestron dealers and programmers can be found in the Database area.
Yahoo! Groups Links

**


Isn't that what this is talking about here?


I just thought someone had created a tool to "integrate" this
automatically.

Almost - I had one a couple of months ago, that wouldn't respond to the Select command from the IR driver (Crestron DB) that I've used on 100 other boxes.

Let me know if you'd like a copy of the driver I finally got to work with it.

--- In Crestron@..., "avprogram" <avprogram@> wrote:

Has anybody come across on Apple tv a Menu button that does not work in Crestron. It is the second generation black style box.

**


Diverging: Chris, have you tried two vs. four cores in Fusion? I'm
curious. In the past I always found two to be faster than four, but I'll
try again if something has changed.


On May 17, 2013, at 2:08 PM, Chris Niles <chris.niles.crestron@...>
wrote:

Retina MacBook Pro here w/SSD. Running VMWare Fusion, with 4 assigned

cores

and 4GB assigned memory. Win7 Pro x64.

Initial launch = just under 4s
Subsequent = 2s