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 \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);
}
}
[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]
