开云体育

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]

**


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

As my computer has grown older, I find that I appreciate an acknowledgement that the program actually started after I clicked the icon.

Nothing more annoying than after waiting 5 minutes winding up with 3 instances of Toolbox open...

--- 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鈥�.

**


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

Thanks Neil, yeah I do the same but don't have a 3 series processor available right now. Oh well.....never a dull moment!

--- In Crestron@..., Neil Dorin <neildorin@> wrote:

Considering the dynamic nature of most Core3UI content it's pretty much useless anyway. I run my projects as xpanels and use a screenshot tool like Win7 snippet tool or Greenshot to capture the actual state of the UI including button fb and indirect text.

Sent from my iPhone

On 2013-05-16, at 4:45 PM, "avsystemdesign" <avsystemdesign@> wrote:

Really?! We cant print out our pages, or save them as images?
Please tell me I am missing something.

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

If not the wrong way, how else could this be taken?

I don't program 24/7 or anything close to that, so yes I did make it through the cert course without knowing this. Pretty cool, huh?

Thanks for the vote of confidence.



--- In Crestron@..., "Ted" <ted_brincka@> wrote:

Don't take this the wrong way, but you actually made it all the way to taking the cert exam thinking that IR codes can just be translated to 232? Wow!

--- In Crestron@..., "jhuerta2803" <jav-gen@> wrote:

Sorry for the confusion Chip. I thought that IR codes could be easily converted to rs232 serial commands. I have now learned thanks to you and others that they are not they same.

I was able to find the serial commands in the Files section, and there was also a module that might be useful as well.

Thanks for the input.



--- In Crestron@..., "Chip" <cfm@> wrote:

Your posts are very confusing. (Or it's just been a long day. Or both)

You mention that you want to use RS232 control, but then you talk about capturing IR codes and using an IR bud. Not the same thing.

RS232 control would be using the DB-9 connector on the display and connecting it to a COM port on your processor. No IR. No buds.

There are at least two PFM series RS232 modules already in the SIMPL windows library. There's a decent chance one of them will get you at least power control of the unit, so I'd suggest looking at the documentation for one of the modules and fashioning up an RS232 cable...

If none of those modules work, I'm afraid your best bet to find the RS-232 commands (did I mention these have nothing to do with IR?) would be to call Sony and see if you are lucky enough to find a tech that's willing to dig them out for you.

- Chip


--- In Crestron@..., "jhuerta2803" <jav-gen@> wrote:

New to this forum, or maybe a long time since my last post. I am working on one of my certification programs and have plasma display that is not listed in the Crestron DB. I managed to capture the IR commands from the remote using the Crestron IR learner, but I need to convert the commands from IR to rs232 since the cert instructions call for rs232 control instead of IR.

I entered the IR codes via the Tx signal to see if they work the way I thought they should be entered into a Serial I/O, but they aren't working. The power_cycle code is 0x010F, and I entered it into the Tx signal as &#92;x00x010F&#92;x03 and the plasma does not turn on.

I guess I am just missing how to enter the command into the serial I/O param. I tried "0x101F", but that doesn't do anything either.

I haven't tried connecting an IR bud to make sure they even work that way, but they seem to be the same as another model that is listed in the database.

Ah, I just saw the bit about Geoffrey Reynold's conversion program. I will try that and see how that works.



--- In Crestron@..., "davestaud" <DaveStaud@> wrote:

I think this belongs in the "Connecting Devices" section...

=================================================================

Q: Where can I find Crestron IR codes for a <brand> <model> ?
A: Discrete codes for most brands that support them, can usually be
found in the Crestron Database -- search by Manufacturer, then look
in the "Generic", "Multiple", or "UnClassified" folders.

Also, most devices will respond to IR drivers for similar models
within the same brand -- ie., the driver for the Mitsubishi HSU-780
will probably work with the 580.

The Remote Central web site has IR codes for a large number of
devices, in Philips Pronto format (see
).
Pronto-style codes can be converted into Crestron format by either of
two pieces of software: 1) Crestron's "Driver Editor And Learner for
Windows" (aka DEAL) can import Pronto-style codes one at a time, or
2) group member Geoffrey Reynolds has written an excellent utility
program that will convert an entire set of Pronto codes (embodied in
a .ccf file) into a Crestron IR driver in one step (see
for details)

Please don't ask the group for IR drivers until you've tried all of
the above -- it's generally considered rude to ask others to do
research that you should be doing for yourself.

=================================================================

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