开云体育

**


Anyone know who actually makes these flat panels for the cisco profile
55s? I have to serially control them and don't want to spend hours trying
different baud rates & protocols...

Thanks!

wrote:

**


Neli, do you have VPN access, and you're using your own computer

or

a PC onsite that you can remote into somehow?

Chris


On Thu, Jun 13, 2013 at 12:50 PM, Neil Dorin <neildorin@...> wrote:

+1000

I'm 3000kms from a large enterprise commercial project as we speak and
remotely updating firmware and VTP projects on 90+ TSW-750s. Flawless and
painless...


On Thu, Jun 13, 2013 at 11:34 AM, Dustin <dustin@...>

wrote:

**

While I completely acknowledge the growing pains and evolution of the

new

products, one thing I think some folks are missing are the new tools

for

deploying firmware and graphics updates such as FTP usage and the FGET
console command. With the new panels, both firmware and graphics

projects

are becoming too large to manage remotely unless you utilize the new
commands. The pain of these updates is severely lowered when it takes a
fraction of the time.

I updated a 32Mb tsw project on over 200 panels that are on 5 different
properties yesterday in 2 hours all from my desk. Firmware can be done

in

the same fashion. (I have done it in the past)

Really takes the sting out of it.


--- In Crestron@..., "Jason Santlofer" <jason@...> wrote:

I think everyone needs to tell Crestron the very same thing. It is

not

ok

to have dealers running around constantly because the product was put

out

before it should have been. 6 firmwares 12 tech calls and 90 Hours

later

(unbillable) I think I might now actually have a stable functional

system.

Now who is going to pay me for my time? Sure as hell not the

customer.

From: Crestron@... [mailto:Crestron@...] On

Behalf

Of dingothewop
Sent: Wednesday, June 12, 2013 11:54 AM
To: Crestron@...
Subject: [Crestron] Re: TSW-750 Issues





I'm having the same issues, as well as the same fears as you are

Heath.

I'm

wondering if's an issue with he network switch the TSW's are

connected

to. I

AM using the CEN-SWPOE24 and I have a sneaking suspicion that the POE

is

not

very reliable. The SWPOE24 also has the reboot at "x" time function

but I

have found that when I have network wierdness, a soft reboot does not

work,

a power cycle is the only remedy. I am curious to see what other

network

switches others are using.

And Heath, your a major player in the Crestron world, maybe you could
explain to them that as programmers we cant run back to a job and do
firmware updates every 2 months, that seems to be the frequency in

which

the

TSW "inprovements" are coming.

Dino
Lips Electronics

--- In Crestron@... <mailto:Crestron%40yahoogroups.com>

,

Heath

Volmer <hvolmer@> wrote:

"Periodicreboot on" turns on the every-day reboot cycle. It should

then

reboot every day at 2am. You only run the command once, on the TSW.

I haven't had the feedback problems since, but there is a

noticeable

"start up lag" and unpredictability that happens the first time

someone

tries to access something each day, as the various objects get going.

On

the

panels that I have not set to reboot, I've noticed some other odd

behaviors

- most notably buttons going off like fireworks - so I have concluded

that

rebooting is the best thing to do for now.

(I'm a firm believer that this stuff is never going to work

reliably

like

it did when a slow Cresnet thing was the go-to. We better be building

this

into our pricing and service plans - and our clients' expectations. I

hope

to heaven that I'm wrong.)

Heath Volmer
Digital Domain Systems
Littleton, CO

Sent from my iTypo 4

On Jun 11, 2013, at 12:24 PM, "cyberbri24" <cyberbri24@> wrote:

On the phone now (on hold) with TB. I'm using the TSW-750 with a

DMPS-300-C and having the damm button FB issue. Still trying to find

out

the

winning combination on what is causing it or how to get it to stop

doing

this. Is this command below supposed to be only sent to the panel and

at

night when the user is not staring at it? My button FB is for a list

of

sources and it is really bubgging the hell out of me that I am

wasting

all

day on what other people are saying is a known issue. Ugh! I can see

in

toolbox that my FB is high but the panel obviously is showing either

wrong

or no FB.

Thanks,
Cyberbri

I suspect that you'll find that they are still on line, and

transmitting

presses, but have stopped responding to feedback. If not, you've

got

a

different problem than what many of us have been up against. I've

been

dealing

with this for a while and the band-aid solution for now is to use

the

PERIODICREBOOT ON command to keep the things fresh every day. If

someone

needs

multiple reboots per day, you may need to devise logic to console

and

issue

reboot commands multiple times.

We've been through the "channels", all the way. No more channels

to

go

through.

They know that something is wrong. I had almost lost faith in my

own

ability to

finish ;-).

Heath

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

[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]

**


Nice diagram.

Are you certain its not the signals on CC that are controlling the
'equipment' instead of EC signals? I know thats akin to 'is it plugged in'
but sounds like it could be the problem.


--- In Crestron@..., "Sebastian" <s.marszalek11@...> wrote:

Hey All,

I built a module that has a CCross, ECross and ECConnect to control

various equipment.

The problem is that, when I have more then one instance of the module in

the program and try to connect from one module to the other, it does not
work as intended.

--------------|
CC ---> EC -->| Equipment <----- Module-1 (Works Great)
--------------|

--------------|
CC ---> EC -->| Equipment <----- Module-2 (Works Great)
--------------|


Lets say I tell the CC from Module 2 to connect to EC in Module 1, it

connects but the signals are forwarded back to Module 2 and controlling
equipment attached to Module 2 instead of going out the Module 1 and
controlling equipment attached to Module 1.

Any help is greatly appreciated.

Thank you

Sure it's allowed but often not desired.

It's rare you'd want to have multiple ECCONNECTs in a set of related
crosspoints.

For example, if you have an interface CCROSS that you want to connect to
any ONE of a set of ECROSS symbols (say each is for an audio zone) then you
want one ECCONNECT to pair with the CCROSS. It will manage the connection
and disconnection of ECROSS symbols to the one CCROSS. This is best
practice for a set of mutually exclusive ECROSS symbols.

If I read your first post correctly, you've encapsulated a CCROSS,
ECCONNECT and ECROSS inside a single module. Unless you want a 1:1
relationship between the CCROSS and ECROSS within that module alone, this
will likely not produce what you're looking for.

You could easily encapsulate the CCROSS and ECCONNECT in a module for each
interface instance and have a separate module containing an ECROSS for each
equipment instance you want to connect to. In 90% of applications, this is
the best practice.



On Thu, Jun 13, 2013 at 12:11 PM, sebastian marszalek <
s.marszalek11@...> wrote:

**


Yes, I made sure that i disconnect from EC in Module 1 and it still
doesn't
work.

Neil, I get what you are saying but I thought multiple ECConnect's in a
single program is allowed?

--
Sebastian Marszalek


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

**


Yes, I made sure that i disconnect from EC in Module 1 and it still doesn't
work.

Neil, I get what you are saying but I thought multiple ECConnect's in a
single program is allowed?

--
Sebastian Marszalek


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

**


While I completely acknowledge the growing pains and evolution of the new
products, one thing I think some folks are missing are the new tools for
deploying firmware and graphics updates such as FTP usage and the FGET
console command. With the new panels, both firmware and graphics projects
are becoming too large to manage remotely unless you utilize the new
commands. The pain of these updates is severely lowered when it takes a
fraction of the time.

I updated a 32Mb tsw project on over 200 panels that are on 5 different
properties yesterday in 2 hours all from my desk. Firmware can be done in
the same fashion. (I have done it in the past)

Really takes the sting out of it.


--- In Crestron@..., "Jason Santlofer" <jason@...> wrote:

I think everyone needs to tell Crestron the very same thing. It is not ok
to have dealers running around constantly because the product was put out
before it should have been. 6 firmwares 12 tech calls and 90 Hours later
(unbillable) I think I might now actually have a stable functional

system.

Now who is going to pay me for my time? Sure as hell not the customer.







From: Crestron@... [mailto:Crestron@...] On

Behalf

Of dingothewop
Sent: Wednesday, June 12, 2013 11:54 AM
To: Crestron@...
Subject: [Crestron] Re: TSW-750 Issues





I'm having the same issues, as well as the same fears as you are Heath.

I'm

wondering if's an issue with he network switch the TSW's are connected

to. I

AM using the CEN-SWPOE24 and I have a sneaking suspicion that the POE is

not

very reliable. The SWPOE24 also has the reboot at "x" time function but I
have found that when I have network wierdness, a soft reboot does not

work,

a power cycle is the only remedy. I am curious to see what other network
switches others are using.

And Heath, your a major player in the Crestron world, maybe you could
explain to them that as programmers we cant run back to a job and do
firmware updates every 2 months, that seems to be the frequency in which

the

TSW "inprovements" are coming.

Dino
Lips Electronics

--- In Crestron@... <mailto:Crestron%40yahoogroups.com> ,

Heath

Volmer <hvolmer@> wrote:

"Periodicreboot on" turns on the every-day reboot cycle. It should then

reboot every day at 2am. You only run the command once, on the TSW.

I haven't had the feedback problems since, but there is a noticeable

"start up lag" and unpredictability that happens the first time someone
tries to access something each day, as the various objects get going. On

the

panels that I have not set to reboot, I've noticed some other odd

behaviors

- most notably buttons going off like fireworks - so I have concluded

that

rebooting is the best thing to do for now.

(I'm a firm believer that this stuff is never going to work reliably

like

it did when a slow Cresnet thing was the go-to. We better be building

this

into our pricing and service plans - and our clients' expectations. I

hope

to heaven that I'm wrong.)

Heath Volmer
Digital Domain Systems
Littleton, CO

Sent from my iTypo 4

On Jun 11, 2013, at 12:24 PM, "cyberbri24" <cyberbri24@> wrote:

On the phone now (on hold) with TB. I'm using the TSW-750 with a

DMPS-300-C and having the damm button FB issue. Still trying to find out

the

winning combination on what is causing it or how to get it to stop doing
this. Is this command below supposed to be only sent to the panel and at
night when the user is not staring at it? My button FB is for a list of
sources and it is really bubgging the hell out of me that I am wasting

all

day on what other people are saying is a known issue. Ugh! I can see in
toolbox that my FB is high but the panel obviously is showing either

wrong

or no FB.

Thanks,
Cyberbri

I suspect that you'll find that they are still on line, and

transmitting

presses, but have stopped responding to feedback. If not, you've got

a

different problem than what many of us have been up against. I've

been

dealing

with this for a while and the band-aid solution for now is to use the
PERIODICREBOOT ON command to keep the things fresh every day. If

someone

needs

multiple reboots per day, you may need to devise logic to console and

issue

reboot commands multiple times.

We've been through the "channels", all the way. No more channels to

go

through.

They know that something is wrong. I had almost lost faith in my own

ability to

finish ;-).

Heath

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

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

Are you disconnecting one EC before connecting the next?

Chris
On Jun 13, 2013 11:48 AM, "Sebastian" <s.marszalek11@...> wrote:

**


Hey All,

I built a module that has a CCross, ECross and ECConnect to control
various equipment.

The problem is that, when I have more then one instance of the module in
the program and try to connect from one module to the other, it does not
work as intended.

--------------|
CC ---> EC -->| Equipment <----- Module-1 (Works Great)
--------------|

--------------|
CC ---> EC -->| Equipment <----- Module-2 (Works Great)
--------------|

Lets say I tell the CC from Module 2 to connect to EC in Module 1, it
connects but the signals are forwarded back to Module 2 and controlling
equipment attached to Module 2 instead of going out the Module 1 and
controlling equipment attached to Module 1.

Any help is greatly appreciated.

Thank you

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




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