开云体育

Without knowing the specific error, I would suggest you make sure your firmware on the MC3 is up to date.

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

I am transplanting an mc3 into a system that formerly was using a cnmsx-av. The client wants a c2n-txm added. In simpl I am getting 5 errors that are saying C# errors within the complete hardware interface v4 on compile. Anyone use a 3 series processor with one of these old tuners? Any way to fix the errors?

Just so you understand what's going on, when you connect multiple ecrosspoints to a single ccrosspoint, the digital signals update to the state of the last ecross connected. If there is no signal defined on the ccross, that is interpreted as a 0 and hence will drive your feedback low. This is the same behavior that enabling a bunch of feedback buffers to the same signals on a TP would have. Whatever the state of the last enabled buffer is will be what the TP reflects. Once everything is connected however, from that point on the last changed signal from any ccross will be reflected on the ecross.

Analog signals are slightly different in that if there is/was a value on them, it will remain until that value is updated. That's why a volume level is reflected on a room without volume.

Serial signals behave a bit like digitals if they are connected to a "Make String Permanent", the last one connected will be the readout. If a serial is defined on the first ecross with an MSP but not defined on the second ecross, the serial will go away rather than being held like an analog volume would be. If serials are *not* connected to an MSP on the equipment end, the serial is not passed along at all or is passed as a null string ("") to the ccross. If a song was playing on an iDock for example and there was no MSP on the serial signals, the current song title and other metadata would not be passed along to a second TP connecting to it until the song changed or metadata was updated/refreshed some other way.

Hope that was understandable and helpful.

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

Thanks a lot Neil.

I think I am going in the right direction, but I need to expand what I have.

I have one ccross from the kitchen panel connecting to multiple ecrosses.

Splitting it up to a ccross per av logic group and ccrosses for lighting, havc, etc., might do the trick.

I'm just glad I don't have to rewrite everything, just expand what I've done so far.

Thanks again, I might post again after some testing tonight.
Sean



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

You best bet is to use parallel sets of crosspoints a for different kinds of logic (AV, lighting, HVAC, etc.)

That means a separate ECCONNECT for each set of crosspoints. I typically use a CCROSS for each type of logic with its own ECCONNECT and as many ECROSSes as devices/zones/rooms as the CCROSS should control.

For grouping, I find It best to use a "group" ECROSS that handles the FB back to the CCROSS and then use either a subset of crosspoints or buffers to have devices/rooms/zones follow the "group" ECROSS.

While you can have a one to many relationship it's difficult to manage feedback correctly as all of ECROSS FB will get jammed together on the CCROSS they all connect to. .

Also, when you have undefined FB joins on an ECROSS they are forced to 0 on connect effectively clearing your feedback on the CCROSS.

Keeping parallel logic separated avoids these issues. I only allow a 1 to 1 CCROSS to ECROSS relationship, but because you can have an AV CCROSS, lighting CCROSS, HVAC CCROSS, etc you can e controlling the theatre AV, games room lighting and basement HVAC all at the same time with correct feedback.

-Neil Dorin

Sent from my iPhone

On 2012-12-24, at 11:35 AM, "Sean" <seanzombie56@> wrote:

I'm trying to figure out if my issues are in my theory, programming, or both.

I use crosspoints well in a one to one situation. My question is, can I use one ccross to connect to a few ecross connections with fb staying along the way.

My system seems to work fine controlling devices, but when I connect to another ecross, I lose FB from my original ecross.

Hope this explanation helps....

From my main room, I connect to the theater via ecross for lights, etc., while keeping that connection alive, I connect to a blu-ray player via ecross. Now my commands seem to work, but what happens is....when I connect to the second ecross, my display fb drops and only comes back when I select theater again.

In watching simpl debugger, ids dont change or get disconnected from my "room ccross" after selecting blu-ray.

Does that fb get dropped when connecting to another ecross without fb across that join, or is there something missing in my program?

A side note, volume seems to stay when connecting from a room with volume to a room without volume, so I assumed fb would stay if nothing is on that attached join.

Happy Holidays, thanks in advance for any help.

Sean

What processor/remote do you have?

--- In Crestron@..., "Block-O-Matic" <michael@> wrote:

Yes, that happened. It will again tonight.

mb

--- In Crestron@..., "LENREX" <lenrex@> wrote:

Has anybody seen their MTX-3 or PTX-3 reboot late at night? Around 11pm PST or 2am EST?

Thanks a lot Neil.

I think I am going in the right direction, but I need to expand what I have.

I have one ccross from the kitchen panel connecting to multiple ecrosses.

Splitting it up to a ccross per av logic group and ccrosses for lighting, havc, etc., might do the trick.

I'm just glad I don't have to rewrite everything, just expand what I've done so far.

Thanks again, I might post again after some testing tonight.
Sean



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

You best bet is to use parallel sets of crosspoints a for different kinds of logic (AV, lighting, HVAC, etc.)

That means a separate ECCONNECT for each set of crosspoints. I typically use a CCROSS for each type of logic with its own ECCONNECT and as many ECROSSes as devices/zones/rooms as the CCROSS should control.

For grouping, I find It best to use a "group" ECROSS that handles the FB back to the CCROSS and then use either a subset of crosspoints or buffers to have devices/rooms/zones follow the "group" ECROSS.

While you can have a one to many relationship it's difficult to manage feedback correctly as all of ECROSS FB will get jammed together on the CCROSS they all connect to. .

Also, when you have undefined FB joins on an ECROSS they are forced to 0 on connect effectively clearing your feedback on the CCROSS.

Keeping parallel logic separated avoids these issues. I only allow a 1 to 1 CCROSS to ECROSS relationship, but because you can have an AV CCROSS, lighting CCROSS, HVAC CCROSS, etc you can e controlling the theatre AV, games room lighting and basement HVAC all at the same time with correct feedback.

-Neil Dorin

Sent from my iPhone

On 2012-12-24, at 11:35 AM, "Sean" <seanzombie56@> wrote:

I'm trying to figure out if my issues are in my theory, programming, or both.

I use crosspoints well in a one to one situation. My question is, can I use one ccross to connect to a few ecross connections with fb staying along the way.

My system seems to work fine controlling devices, but when I connect to another ecross, I lose FB from my original ecross.

Hope this explanation helps....

From my main room, I connect to the theater via ecross for lights, etc., while keeping that connection alive, I connect to a blu-ray player via ecross. Now my commands seem to work, but what happens is....when I connect to the second ecross, my display fb drops and only comes back when I select theater again.

In watching simpl debugger, ids dont change or get disconnected from my "room ccross" after selecting blu-ray.

Does that fb get dropped when connecting to another ecross without fb across that join, or is there something missing in my program?

A side note, volume seems to stay when connecting from a room with volume to a room without volume, so I assumed fb would stay if nothing is on that attached join.

Happy Holidays, thanks in advance for any help.

Sean

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

I am transplanting an mc3 into a system that formerly was using a cnmsx-av. The client wants a c2n-txm added. In simpl I am getting 5 errors that are saying C# errors within the complete hardware interface v4 on compile. Anyone use a 3 series processor with one of these old tuners? Any way to fix the errors?

I have to chime in here as well and report nothing but good things about pakedge. I've worked with them directly on a lot of things and they're all very helpful. What issues are you having?

--- In Crestron@..., "m.nguyen" <mpninc@> wrote:

We have been using pakedge as well and it been pretty solid aside from the
issue with ps3 with virtual cell.
On Dec 22, 2012 5:22 PM, "Kris" <kris.k@> wrote:

**


Never had hardware issues. Only issues with improper setup, wiring or
implementation. Got to love IT issues!

--- In Crestron@..., "Bill Karlis" <vkarlisc@> wrote:

Hello All :-)

For our crestron IT backbone, we've been using Pakedge routers,

switches, access points and their virtual kit lately.

Occasionally, we seem to be having network issues at clients homes and

apartments. Its not often but does seem to happen.

I am trying to narrow it down whether its a problem on our side with

running wires / terminating ends properly etc.

Has anyone else had hardware issues with Pakedge gear?

Thanks in advance,
Bill

Use a past symbol.
On Dec 24, 2012 8:46 PM, "wanderingpoet79" <kenny.jackson@...> wrote:

**


Is there anyway to shutdown a system time wise. For example I would like
an MPS shutdown every night at exactly 1:00 am. What symbols would I need?

Thanks

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

You best bet is to use parallel sets of crosspoints a for different kinds of logic (AV, lighting, HVAC, etc.)

That means a separate ECCONNECT for each set of crosspoints. I typically use a CCROSS for each type of logic with its own ECCONNECT and as many ECROSSes as devices/zones/rooms as the CCROSS should control.

For grouping, I find It best to use a "group" ECROSS that handles the FB back to the CCROSS and then use either a subset of crosspoints or buffers to have devices/rooms/zones follow the "group" ECROSS.

While you can have a one to many relationship it's difficult to manage feedback correctly as all of ECROSS FB will get jammed together on the CCROSS they all connect to. .

Also, when you have undefined FB joins on an ECROSS they are forced to 0 on connect effectively clearing your feedback on the CCROSS.

Keeping parallel logic separated avoids these issues. I only allow a 1 to 1 CCROSS to ECROSS relationship, but because you can have an AV CCROSS, lighting CCROSS, HVAC CCROSS, etc you can e controlling the theatre AV, games room lighting and basement HVAC all at the same time with correct feedback.

-Neil Dorin

Sent from my iPhone

On 2012-12-24, at 11:35 AM, "Sean" <seanzombie56@...> wrote:

I'm trying to figure out if my issues are in my theory, programming, or both.

I use crosspoints well in a one to one situation. My question is, can I use one ccross to connect to a few ecross connections with fb staying along the way.

My system seems to work fine controlling devices, but when I connect to another ecross, I lose FB from my original ecross.

Hope this explanation helps....

From my main room, I connect to the theater via ecross for lights, etc., while keeping that connection alive, I connect to a blu-ray player via ecross. Now my commands seem to work, but what happens is....when I connect to the second ecross, my display fb drops and only comes back when I select theater again.

In watching simpl debugger, ids dont change or get disconnected from my "room ccross" after selecting blu-ray.

Does that fb get dropped when connecting to another ecross without fb across that join, or is there something missing in my program?

A side note, volume seems to stay when connecting from a room with volume to a room without volume, so I assumed fb would stay if nothing is on that attached join.

Happy Holidays, thanks in advance for any help.

Sean

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

Can I share gateways between programs in 3 series processors?

Scenario 1: (2) MLX-3's (each running on different programs in the MC3)from the built in gateway, with different RF-IDs.

Scenario 2: (2) TPS-6X's (each running on different programs in the MC3)from a single shared CEN-HPRFGW, with different RF-IDs.