开云体育

Theory question:

Do EISC and ethernet TPs speak essentially the same language (CIP?) and function similarly in terms of network performance? In other words, if I direct a group of signals at a TP and at an identically-defined EISC, does the processor treat each of them the same or does one have more overhead? Does one weigh more heavily on the network?

"Logic" would dictate that they all speak in the same optimized fashion.

Heath

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

**


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

I see the new mobile app that supports Core3 has been released and I feel it's about time I spend more time understanding it. My hope was it was going to make many things easier, and doable without multiple work arounds. At first glance it looks pretty good, we now have button modes and gestures to use on mobile.

The one key thing I was looking for was a simple way to create flexible scrolling lists. My wish list isn't huge, I'd like to programmatically define the number of items, give each one a serial text join, plus an analog join for an icon or mode.

Hopefully someone out there will tell me after Crestron has worked on this for the past three years and learned from the DNav 'limitations' that they now have made this possible but I'm just to simple to find the right list or secret to CED object to make it work.

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]

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

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]

My main issue is that you can't record and stream at the same time so you are unable to use the TSW(for example) as a confidence monitor. ?You can set it up but the minute you hit record....it's gone. ?Then you need to run it out of the HDMI Out to a flat panel for a confidence monitor which causes more cost and less real estate on a instructor's podium. ?I was told future firmware may accommodate that.


________________________________
From: eagrubbs <eagrubbs@...>
To: Crestron@...
Sent: Thursday, May 16, 2013 11:47 PM
Subject: [Crestron] Re: Capture Live HD


The main issue I have with it is you cannot playback from it. If that feature could be added it would be a lot better. Easy to control. Setting up the IPT/z or whatever part # that sony camera is, sucks if you go by the manual. I had to download some sony software to set it up so I could set up the stream to the panels. my .01

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

What are you looking for -- programming? End user? Sales?

It's stupid easy to program basic functionality, though some aspects require more reading of the tea leaves in the help file than I'd like but for your first time there's enough to build a framework that gets you to a point where you don't waste much time onsite.

Setting a static IP via the front panel is a PITA until you realize that DHCP (completely different menu) has to be turned off for before a static IP will "stick" & the one time I tried using one in "Streaming" mode (I had some time to kill on a jobsite) I don't recall it working well, again that was only one time, and every CaptureHD I've done has been used in "Record" mode/as a VCR replacement -- e.g. user plugs their USB drive in, hits record, at end of meeting hits stop and take the drive with them.

Using a composite video camera input in the 2010s feels dirty to me and, it seems, most of my clients as well. As a result, every CaptureHD I've deployed has been the CaptureHD Pro (which accepts Composite or HD-SDI camera inputs; about 75% of them are using HD-SDI now, the remainder for future resistance) but I assume the differences between the two are not that great aside from that.

HTH,

Lincoln

-----Original Message-----
From: Crestron@... [mailto:Crestron@...] On Behalf Of Gerard
Sent: Thursday, May 16, 2013 9:14 PM
To: Crestron@...
Subject: [Crestron] Capture Live HD

Opinions on this?

Thanks.



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



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

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



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