开云体育

The way the customer wants it set up is mainly the reason for keeping the cable box with the tv. He would like the three small tv's to always be on a particular channel. (ESPN, CNN, Weather)

On his ipad, he will have 4 icons representing each tv. If he wants to control a particular display, he will long press the icon for that display which will give him control of that displays cable box. If he wants to swap that small display to the large display, he will just tap the small displays icon which will move the cable box to the large display.

It seems to be working well in test manager using the TT method. I'll find out tomorrow how well it works in the real world.

Chris

--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@> wrote:

I argue that it really doesn't matter what cable box is on what Television, since you should be driving the control logic from the currently routed source to the specific selected display.

So I imagine you have a way to select which 'display' you want to control, you're control logic already knows what cable box is on what display, so why does it matter specifically 'Cablebox 1' is on TV1?



--- In Crestron@..., "Christopher" <topher1200s@> wrote:

Thanks for the suggestions guys. I'll be working on this today and implementing it tomorrow. Hopefully I can get it working the way I want.

Chris

--- In Crestron@..., "Kris" <kris.k@> wrote:

With some toggles to select a display(s) and init/equates to get analog values for the current sources, then abufs triggered by a "swap" button (which also resets the toggles) you might get some cool switching logic. Drive the matrix switcher withe the feedback from the equates. I use a similar logic set to select multiple rooms then a common source. I don't see why you couldn't just make the logic swap current sources instead of just select a new source.

--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@> wrote:

Well, that wouldn't be swapping now would it. :)

I would maybe do a route upon the swap press, which puts everything bakc to 1/2/3 across the top and 4 on the bottom. Then upon the swap release, swap 1/4 or 2/4 or 3/4. Depends upon what kind of device you're controlling switching for how fast/noticible it will be.

--- In Crestron@..., "Christopher" <topher1200s@> wrote:

I have a project where we have 4 displays. 3 Small displays above 1 large display. Each display has it's own cable box. (4 boxes)

The customer would like to be able to swap display 1 and 4 or 2 and 4 or 3 and 4.

I have the swap working by using the logic from the video in this post

but I'm having the following problem If I swap 1 and 4, where display 1 is showing cable box 4 and display 4 is showing cable box 1 and I press swap 2 and 4, display 2 will now show cable box 1 and display 4 will show cable box 2.

I need to figure out a way where I can have the displays default back to their own cable box when I make a swap.

Hopefully someone has some ideas for me.

Thanks for the help.

Chris

I have been lurking - watching the thread about "deleting signals with no
driving source".

In my not-so-humble opinion, a programmer has only 3 defenses to keep
someone from re-using his code for another project. One is to supply
incomplete or wrong source code. Another is to encrypt essential parts of
the code (this is part of what Simpl# is intended to be for). The third is
to make the code confusing so the person trying to "steal" it will perhaps
decide it is easier to start over and do the whole thing himself.

I have never supplied incomplete or wrong code (to my knowledge).
Encryption is too much trouble. This leaves option #3.

In every case where someone has complained to me about "obfuscated" code,
I have found that they are trying to re-use my code for another project -
against the provisions of the contract. Some programmers have even had the
gall to call me up and ask me to explain it to them. I don't mind helping
if they are doing program maintenance on the original project - that's ok -
but when they call me to ask me to explain how to program another project
using my code -
ouch!!!

Regards
Someone who has been burned.
Paul



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




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 have been lurking - watching the thread about "deleting signals with no driving source".

In my not-so-humble opinion, a programmer has only 3 defenses to keep someone from re-using his code for another project. One is to supply incomplete or wrong source code. Another is to encrypt essential parts of the code (this is part of what Simpl# is intended to be for). The third is to make the code confusing so the person trying to "steal" it will perhaps decide it is easier to start over and do the whole thing himself.

I have never supplied incomplete or wrong code (to my knowledge). Encryption is too much trouble. This leaves option #3.

In every case where someone has complained to me about "obfuscated" code, I have found that they are trying to re-use my code for another project - against the provisions of the contract. Some programmers have even had the gall to call me up and ask me to explain it to them. I don't mind helping if they are doing program maintenance on the original project - that's ok - but when they call me to ask me to explain how to program another project using my code -
ouch!!!

Regards
Someone who has been burned.
Paul

If a "programmer" needs to borrow my code in order to program something,
they probably aren't my competition. We stick with legal provisions for
protecting code, because they're the only ones with any teeth. Encryption
is a joke, and I'm too busy to (intentionally!) obfuscate anything.
Besides, I owe my customers complete and legible code that they can take
to another dealer if they want. It's our job to make sure they don't want
to switch dealers. If we aren't doing our job to retain the customer,
withholding or obfuscating source code is only going to make them angry and
possibly result in legal action.


On Wed, Mar 13, 2013 at 10:26 AM, oldspunky <paul@...>wrote:

I have been lurking - watching the thread about "deleting signals with no
driving source".

In my not-so-humble opinion, a programmer has only 3 defenses to keep
someone from re-using his code for another project. One is to supply
incomplete or wrong source code. Another is to encrypt essential parts of
the code (this is part of what Simpl# is intended to be for). The third is
to make the code confusing so the person trying to "steal" it will perhaps
decide it is easier to start over and do the whole thing himself.

I have never supplied incomplete or wrong code (to my knowledge).
Encryption is too much trouble. This leaves option #3.

In every case where someone has complained to me about "obfuscated" code,
I have found that they are trying to re-use my code for another project -
against the provisions of the contract. Some programmers have even had the
gall to call me up and ask me to explain it to them. I don't mind helping
if they are doing program maintenance on the original project - that's ok -
but when they call me to ask me to explain how to program another project
using my code -
ouch!!!

Regards
Someone who has been burned.
Paul



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




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

--
Jeremy Weatherford


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

I have been lurking - watching the thread about "deleting signals with no
driving source".

In my not-so-humble opinion, a programmer has only 3 defenses to keep
someone from re-using his code for another project. One is to supply
incomplete or wrong source code. Another is to encrypt essential parts of
the code (this is part of what Simpl# is intended to be for). The third is
to make the code confusing so the person trying to "steal" it will perhaps
decide it is easier to start over and do the whole thing himself.

I have never supplied incomplete or wrong code (to my knowledge).
Encryption is too much trouble. This leaves option #3.

In every case where someone has complained to me about "obfuscated" code,
I have found that they are trying to re-use my code for another project -
against the provisions of the contract. Some programmers have even had the
gall to call me up and ask me to explain it to them. I don't mind helping
if they are doing program maintenance on the original project - that's ok -
but when they call me to ask me to explain how to program another project
using my code -
ouch!!!

Regards
Someone who has been burned.
Paul



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




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

yes you can

On Tue, Mar 12, 2013 at 1:46 PM, Aaron <aaron.larson@...> wrote:

**


Can you use the Packet Transmission device extender on a com port slot of
a DM-RMC-SCALER-C to dynamically change the com settings?

I have used this before on processors and ST-COMS but I have not used a
port on a DM system. Anyone know?

Aaron

Hello,

Does anyone know how to mute the input audio to the program output without muting the microphones? This is a case of when a speaker wants to speak over playing video through a microphone. I am using the DMPS-300 v1.1 module currently. Any help with this problem would be appreciated.

Thank you,

Eric Mackay

It seems to me like this may be a really good application for a truth
table. You may need one table per display or possibly one table could be
used for all the switching logic. I've only used a tt once as I haven't
really had a good scenario for them.

Nick

Sent from my eMail.

On Mar 13, 2013, at 8:24 AM, Christopher <topher1200s@...> wrote:



Thanks for the suggestions guys. I'll be working on this today and
implementing it tomorrow. Hopefully I can get it working the way I want.

Chris

--- In Crestron@..., "Kris" <kris.k@> wrote:

With some toggles to select a display(s) and init/equates to get analog

values for the current sources, then abufs triggered by a "swap" button
(which also resets the toggles) you might get some cool switching logic.
Drive the matrix switcher withe the feedback from the equates. I use a
similar logic set to select multiple rooms then a common source. I don't
see why you couldn't just make the logic swap current sources instead of
just select a new source.

--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@> wrote:

Well, that wouldn't be swapping now would it. :)

I would maybe do a route upon the swap press, which puts everything

bakc to 1/2/3 across the top and 4 on the bottom. Then upon the swap
release, swap 1/4 or 2/4 or 3/4. Depends upon what kind of device you're
controlling switching for how fast/noticible it will be.

--- In Crestron@..., "Christopher" <topher1200s@> wrote:

I have a project where we have 4 displays. 3 Small displays above 1

large display. Each display has it's own cable box. (4 boxes)

The customer would like to be able to swap display 1 and 4 or 2 and

or 3 and 4.

I have the swap working by using the logic from the video in this

post

but I'm having the following problem If I swap 1 and 4, where

1 is showing cable box 4 and display 4 is showing cable box 1 and I press
swap 2 and 4, display 2 will now show cable box 1 and display 4 will show
cable box 2.

I need to figure out a way where I can have the displays default

to their own cable box when I make a swap.

Hopefully someone has some ideas for me.

Thanks for the help.

Chris

I argue that it really doesn't matter what cable box is on what Television, since you should be driving the control logic from the currently routed source to the specific selected display.

So I imagine you have a way to select which 'display' you want to control, you're control logic already knows what cable box is on what display, so why does it matter specifically 'Cablebox 1' is on TV1?



--- In Crestron@..., "Christopher" <topher1200s@> wrote:

Thanks for the suggestions guys. I'll be working on this today and implementing it tomorrow. Hopefully I can get it working the way I want.

Chris

--- In Crestron@..., "Kris" <kris.k@> wrote:

With some toggles to select a display(s) and init/equates to get analog values for the current sources, then abufs triggered by a "swap" button (which also resets the toggles) you might get some cool switching logic. Drive the matrix switcher withe the feedback from the equates. I use a similar logic set to select multiple rooms then a common source. I don't see why you couldn't just make the logic swap current sources instead of just select a new source.

--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@> wrote:

Well, that wouldn't be swapping now would it. :)

I would maybe do a route upon the swap press, which puts everything bakc to 1/2/3 across the top and 4 on the bottom. Then upon the swap release, swap 1/4 or 2/4 or 3/4. Depends upon what kind of device you're controlling switching for how fast/noticible it will be.

--- In Crestron@..., "Christopher" <topher1200s@> wrote:

I have a project where we have 4 displays. 3 Small displays above 1 large display. Each display has it's own cable box. (4 boxes)

The customer would like to be able to swap display 1 and 4 or 2 and 4 or 3 and 4.

I have the swap working by using the logic from the video in this post

but I'm having the following problem If I swap 1 and 4, where display 1 is showing cable box 4 and display 4 is showing cable box 1 and I press swap 2 and 4, display 2 will now show cable box 1 and display 4 will show cable box 2.

I need to figure out a way where I can have the displays default back to their own cable box when I make a swap.

Hopefully someone has some ideas for me.

Thanks for the help.

Chris

From: oldspunky <paul@...>
Sent: Mar 13, 2013 10:26 AM
To: Crestron@...
Subject: [Crestron] In defense of obfuscation

I have been lurking - watching the thread about "deleting signals with no driving source".

In my not-so-humble opinion, a programmer has only 3 defenses to keep someone from re-using his code for another project. One is to supply incomplete or wrong source code. Another is to encrypt essential parts of the code (this is part of what Simpl# is intended to be for). The third is to make the code confusing so the person trying to "steal" it will perhaps decide it is easier to start over and do the whole thing himself.

I have never supplied incomplete or wrong code (to my knowledge). Encryption is too much trouble. This leaves option #3.

In every case where someone has complained to me about "obfuscated" code, I have found that they are trying to re-use my code for another project - against the provisions of the contract. Some programmers have even had the gall to call me up and ask me to explain it to them. I don't mind helping if they are doing program maintenance on the original project - that's ok - but when they call me to ask me to explain how to program another project using my code -
ouch!!!

Regards
Someone who has been burned.
Paul

It seems to me like this may be a really good application for a truth
table. You may need one table per display or possibly one table could be
used for all the switching logic. I've only used a tt once as I haven't
really had a good scenario for them.

Nick

Sent from my eMail.

On Mar 13, 2013, at 8:24 AM, Christopher <topher1200s@...> wrote:



Thanks for the suggestions guys. I'll be working on this today and
implementing it tomorrow. Hopefully I can get it working the way I want.

Chris

--- In Crestron@..., "Kris" <kris.k@> wrote:

With some toggles to select a display(s) and init/equates to get analog

values for the current sources, then abufs triggered by a "swap" button
(which also resets the toggles) you might get some cool switching logic.
Drive the matrix switcher withe the feedback from the equates. I use a
similar logic set to select multiple rooms then a common source. I don't
see why you couldn't just make the logic swap current sources instead of
just select a new source.

--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@> wrote:

Well, that wouldn't be swapping now would it. :)

I would maybe do a route upon the swap press, which puts everything

bakc to 1/2/3 across the top and 4 on the bottom. Then upon the swap
release, swap 1/4 or 2/4 or 3/4. Depends upon what kind of device you're
controlling switching for how fast/noticible it will be.

--- In Crestron@..., "Christopher" <topher1200s@> wrote:

I have a project where we have 4 displays. 3 Small displays above 1

large display. Each display has it's own cable box. (4 boxes)

The customer would like to be able to swap display 1 and 4 or 2 and 4

or 3 and 4.

I have the swap working by using the logic from the video in this

post

but I'm having the following problem If I swap 1 and 4, where display

1 is showing cable box 4 and display 4 is showing cable box 1 and I press
swap 2 and 4, display 2 will now show cable box 1 and display 4 will show
cable box 2.

I need to figure out a way where I can have the displays default back

to their own cable box when I make a swap.

Hopefully someone has some ideas for me.

Thanks for the help.

Chris

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

I have actually used the 'CHV-THSTAT w/5-2 scheduler' with a bacnet system. I just sent all the necessary signals at the bottom of the module to the bacnet system, instead of the Crestron thermostat.

-Kevin

On Mar 13, 2013, at 9:07, "ben899621" <ben.newberry@...> wrote:

Hi,

I'm trying to set up a HVAC scheduler for a system that has been installed. Ideally I would like to emulate what the 'CHV-THSTAT w/5-2 scheduler 4.0.0' does but it needs to control a KNX heating and Daikin AC system that is in the property without a CHV-THSTAT installed and working all in software.

So the wishlist is being able to setup timers for weekday and weekend (wakeup, leave...etc) and setpoints for these times. When the timers are active compare the current room temps with what the setpoints are and then output a signal to turn on/off the heating or AC accordingly.

Does anyone know if it is possible to achieve this by using the above mentioned module as I can't see that it ouputs signals for either turning on off the Heating/AC, or what the setpoints are so I could program that function in myself.

I am in the process of programing my own module using the event scheduler but this does not seem like an ideal way of achieving what I am trying to do.

Any help is very much appreciated!

Thanks for the suggestions guys. I'll be working on this today and implementing it tomorrow. Hopefully I can get it working the way I want.

Chris

--- In Crestron@..., "Kris" <kris.k@> wrote:

With some toggles to select a display(s) and init/equates to get analog values for the current sources, then abufs triggered by a "swap" button (which also resets the toggles) you might get some cool switching logic. Drive the matrix switcher withe the feedback from the equates. I use a similar logic set to select multiple rooms then a common source. I don't see why you couldn't just make the logic swap current sources instead of just select a new source.

--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@> wrote:

Well, that wouldn't be swapping now would it. :)

I would maybe do a route upon the swap press, which puts everything bakc to 1/2/3 across the top and 4 on the bottom. Then upon the swap release, swap 1/4 or 2/4 or 3/4. Depends upon what kind of device you're controlling switching for how fast/noticible it will be.

--- In Crestron@..., "Christopher" <topher1200s@> wrote:

I have a project where we have 4 displays. 3 Small displays above 1 large display. Each display has it's own cable box. (4 boxes)

The customer would like to be able to swap display 1 and 4 or 2 and 4 or 3 and 4.

I have the swap working by using the logic from the video in this post

but I'm having the following problem If I swap 1 and 4, where display 1 is showing cable box 4 and display 4 is showing cable box 1 and I press swap 2 and 4, display 2 will now show cable box 1 and display 4 will show cable box 2.

I need to figure out a way where I can have the displays default back to their own cable box when I make a swap.

Hopefully someone has some ideas for me.

Thanks for the help.

Chris