开云体育

**


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 \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 \n",Analog_in);
if (Analog_in <> Current_Level)
{
Level$ = IToHex(Analog_In);
}
}

**


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

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]

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

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]

**


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);
}
}

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

*

****

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

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