¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io

Re: Simpl + Change Analog


 

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


Join [email protected] to automatically receive all group messages.