开云体育

Just wondering if any one has a thought on this.
I have a video wall that I want to control the position of windows.
Instead of using sliders I wanted to make it so you could control it on a TSW panel.
Initially thought the switcher widget or the gesture widget could work somehow but
1)switcher widget allows the same inputs in multiple places
2) gesture control is simply a swipe up/down/left/right command

Next, I thought of somehow reading the XY position of the input on the panel and using that to move the position. But don't think this can be done.

Any ideas?

When side A requests an update from side B, B sends a single "clear" followed by the
non-zero data. If you have one signal defined at Join 1, and another at Join 4000 it would
at most send 2 states.


--- In Crestron@..., Heath Volmer <hvolmer@...> wrote:

If i understand: On the "genericly-named" remote end, where all of the signals are
defined, an update request will cause a slew of data to flow out, back to the main. On
the "main" end, where fewer signals are defined, the corresponding update-request will
generate less data towards the remote end.

I guess the question is simplest as: Do the undefined signals get transmitted, or only
the defined?

Heath


On May 15, 2013, at 1:36 PM, Kool-Aid Drinker <herald@...> wrote:

EISC don't know what is on the receiving end, they send based on their
inputs whether the other end has a matching output or not.

So, network traffic and overhead.

On Wed, 15 May 2013 11:35:50 -0600, Heath Volmer <hvolmer@...>
wrote:

Experimenting with making a "generic" sort of bridge between two programs to break up the
organization of a program, and to off-load some potentially heavy processing.

If, in the program broken away from the main program, I define an EISC with a ton of
generic signals (dig1, dig 2... 600 of each flavor maybe) and in the main program only use
the signals that are relevant, do I wind up with a mass of updating going on between
programs or does it only update those signals that are defined on the sending end?

I could potentially have many of these EISCs, but only heavily-loaded in the remote program.

Heath

Anyone have a confirmed solution to this problem?

I have a very similar situation with a Program running perfectly on MC3, but now after installed on a Pro3 the processor reboots intermittently with the "HW Watchdog timeout" error (iPad mini's and iphone are part of this project also) Pro3 is running FW v1.006.0026 (Feb 06 2013), sounds too similar to be a coincidence and I'm just wondering what was done to fix the other reported cases


--- In Crestron@..., "Sean" <sound.scan@> wrote:

How did you swap/replace your control system in SIMPL? I recall on another message board a situation where someone had done a control system replace and was experiencing issues very similar to yours. The fix was to create a new program with the new control system and manual copy over all of the hardware and logic folders. I'll see if I can find a link to the original thread.

--- In Crestron@..., "xymox1357" <public2@> wrote:

Well everything ran perfectly without rebooting until I moved from a MC3 to the Pro3. Then without any changes to the code First gen iPads and the mini fall offline after a few days and then finally I get a HW Watchdog reboot. This cycle repeats.

On reboot everything works perfectly.

--- In Crestron@..., "Gregg M" <jets_in_2003@> wrote:

I get the same HW Watchdog error in my cp3 that has no ipads in it, just a tsw-750 and tpmc-8x-ga. TB swears it's an issue with my code, but I have het to find the cause. All my module have never had in issue running on the MC3

--- In Crestron@..., "xymox1357" <public2@> wrote:

This just in:

System rebooted.. On its own..

From the error log "Notice: nk.exe # 20:06:51 3-10-2013 # HW Watchdog timeout"

So something is going on in the Pro3.

This is my second one. I RMA'ed one a few days ago because it went down face first and was not rebooting. After A while I got it back up and reloaded, but I decided to swap anyway.

Something seems like there is a real issue here.. And a HW Watchdog timeout is not trivial.

Have you try

Www.docs.sony.com

To find your model and protocol.

{Paf}
Le 14 mai 2013 20:32, "jhuerta2803" <jav-gen@...> a écrit :

**


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.

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

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.

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

How did you swap/replace your control system in SIMPL? I recall on another message board a situation where someone had done a control system replace and was experiencing issues very similar to yours. The fix was to create a new program with the new control system and manual copy over all of the hardware and logic folders. I'll see if I can find a link to the original thread.

--- In Crestron@..., "xymox1357" <public2@> wrote:

Well everything ran perfectly without rebooting until I moved from a MC3 to the Pro3. Then without any changes to the code First gen iPads and the mini fall offline after a few days and then finally I get a HW Watchdog reboot. This cycle repeats.

On reboot everything works perfectly.

--- In Crestron@..., "Gregg M" <jets_in_2003@> wrote:

I get the same HW Watchdog error in my cp3 that has no ipads in it, just a tsw-750 and tpmc-8x-ga. TB swears it's an issue with my code, but I have het to find the cause. All my module have never had in issue running on the MC3

--- In Crestron@..., "xymox1357" <public2@> wrote:

This just in:

System rebooted.. On its own..

From the error log "Notice: nk.exe # 20:06:51 3-10-2013 # HW Watchdog timeout"

So something is going on in the Pro3.

This is my second one. I RMA'ed one a few days ago because it went down face first and was not rebooting. After A while I got it back up and reloaded, but I decided to swap anyway.

Something seems like there is a real issue here.. And a HW Watchdog timeout is not trivial.

If i understand: On the "genericly-named" remote end, where all of the signals are defined, an update request will cause a slew of data to flow out, back to the main. On the "main" end, where fewer signals are defined, the corresponding update-request will generate less data towards the remote end.

I guess the question is simplest as: Do the undefined signals get transmitted, or only the defined?

Heath


On May 15, 2013, at 1:36 PM, Kool-Aid Drinker <herald@...> wrote:

EISC don't know what is on the receiving end, they send based on their
inputs whether the other end has a matching output or not.

So, network traffic and overhead.

On Wed, 15 May 2013 11:35:50 -0600, Heath Volmer <hvolmer@...>
wrote:

Experimenting with making a "generic" sort of bridge between two programs to break up the
organization of a program, and to off-load some potentially heavy processing.

If, in the program broken away from the main program, I define an EISC with a ton of
generic signals (dig1, dig 2... 600 of each flavor maybe) and in the main program only use
the signals that are relevant, do I wind up with a mass of updating going on between
programs or does it only update those signals that are defined on the sending end?

I could potentially have many of these EISCs, but only heavily-loaded in the remote program.

Heath

I dont have a fix for you, but in my home i have my MC3 running latest firmware ( was also fine with .05.15 as well). And its eisc to a pro2 running 4.7.5 been that way for like a year with no issues. I was running them through a d-link green 24port unmanaged gigabit switch, and recently changed them to a HP 16 port managed gigabit switch. Still humming along.

What switch are you using?
Jon

Sent from my iPad

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

Experimenting with making a "generic" sort of bridge between two programs to break up the organization of a program, and to off-load some potentially heavy processing.

If, in the program broken away from the main program, I define an EISC with a ton of generic signals (dig1, dig 2... 600 of each flavor maybe) and in the main program only use the signals that are relevant, do I wind up with a mass of updating going on between programs or does it only update those signals that are defined on the sending end?

I could potentially have many of these EISCs, but only heavily-loaded in the remote program.

Heath