NCX-IRS4 and NCX-REL10 Lose connection, reboot of master is the only way to get back

rosswylie

Hi

I have a project producing some strange results,

The system is

1 No. NI-3000
2 No. MVP-8400
2 No. NCX-IRS4
1 No. NCX-REL10

I have encountered numerous problems with this system,

The expansion ports are dropping out of the system for some reason and the only way to get them back online is to reboot the master controller!!

Also the system loses the panels, although in the protected setup the wireless connection is still there, but there is no connection to the master,

again the only solution that i have found to fix this is to reboot the master controller!

I would like to get to the root of the problem so any advice would be greatfully received,

So far I have updated the firmware on the two MVP-8400s and updated the NI-3000, Also changed the buffer threshhold size from 10 to 2000,

Can anyone shed some light on this?

Thanks

Ross Wylie

DHawthorne

Excessive traffic to the panel can cause this. Open up your notifications section in Studio diagnostics, and turn on all event to the touch panel, and see if there are a lot of updates going to the panel. More than a half dozen per second can become problematic and probably indicate a problem spot anyway.

rosswylie

thanks for the reply,

If it turns out there are over half a dozen messages per second what steps should i take to fix this issue?

Ross

yuri

are those diagnostic messages or asynchronous notifications?

DHawthorne

Figure out what part of the code is causing the messages and change it so they don't occur so frequently. Common issues are feedback in mainline. I saw a job once (wasn't one of mine, but I wound up taking it over) where the original programmer used a stock Marantz receiver module. There was nothing wrong with the module, but it had seperate feedback for the ON and OFF states that were intended to display on different buttons. The weren't using either button in the panel design, so they assigned them to channel 0. There's two problems with that: first, zero is the wildcard for all, so it went to all the buttons. Second, since every pass of mainline turned the ON button on, and the OFF button off, and they were assigned to the same button (and in this case, all the buttons) you always got one of both of those states set on every pass. There were literally hundreds of them going to the panel every second. It ran fine, actually, for a few days before everything caught up and crashed the system, but what happened was first things got sluggish, then the panel dropped ofline, then it locked up completely. It also brought his house netywork to its knees from the WAP activity to the panel.

I found this by doing exactly what I just advised you. Once I saw what messages were going out too often, I found the section in code that generated them. In this case, I could have assigned the feedback to proper (and different) channels, but since it wasn't being used anyway, I just commented it out. Since it didn't noticibly affect the system right away, I am now cautious about such things, and run an event notificatin check on every system as a matter of course ... especially if I'm working with someone else's modules.

DHawthorne

yuri wrote:

are those diagnostic messages or asynchronous notifications?

I suppose you could characterize them as asynchronous notifications, but I'm not referring to traffic on a serial port or anything like that. I'm talking about the diagnostic tool that lets you track the messages that flow between a master and a panel in the normal course of operations. It's in the diagnostic section of NS, but I wouldn't really call themn diagnostic messages, it's just the tool that lets you see them that is diagnostic.

rosswylie

Hi again

I will try the diagnostics on the system I am talking about,

In the mean time do you think that the system is falling over because i have feedback on
each of the rooms the system controls and also feedback to confirm that the system is linked,

Therefore I have a total of 12 feedbacks always talking! I.e. 5 rooms and 1 feedback flash on the 2 panels,

The two panels are identical in their functionality but have been programmed so that they are not combined, so that they can be used at the same time in different rooms,

I know that the system is more robust when there is only 1 touch panel, but when the second panel is introduced the system gets confused

DHawthorne

rosswylie wrote:

Hi again

I will try the diagnostics on the system I am talking about,

In the mean time do you think that the system is falling over because i have feedback on
each of the rooms the system controls and also feedback to confirm that the system is linked,

Therefore I have a total of 12 feedbacks always talking! I.e. 5 rooms and 1 feedback flash on the 2 panels,

The two panels are identical in their functionality but have been programmed so that they are not combined, so that they can be used at the same time in different rooms,

I know that the system is more robust when there is only 1 touch panel, but when the second panel is introduced the system gets confused

It depends on the type of feedback. Any kind of feedback that requires a message to be sent to the panels should be limited to once or twice a sceond, not continuously streaming in mainline (use a timeline instead). Direct channel feedback, however, if linked to a real panel button, only actually updates if the channel changes, the master keeps track of it. For example: [dvTP, 1] == nSystemState ... that would only actually change when nSystemState changes. This doesn't seem to be true for virtual devices - those channels always go out. A variable text field that uses a SEND_COMMAND to update, however, would stream continuously.

rosswylie

This is the code that i use for the link flash, to show the system is connected

It uses the timeline, but perhaps I have done it the wrong way,


PROGRAM_NAME='Link_Flash'

DEFINE_DEVICE

// Panel
#IF_NOT_DEFINED dvMVP1
dvMVP1 = 10001:1:0 // MVP7500 192.168.1.22
#END_IF
#IF_NOT_DEFINED dvMVP2
dvMVP2 = 10040:1:0 // MVP7500 192.168.1.23
#END_IF
// Declare Virtual Device
#IF_NOT_DEFINED vdvMVP1
vdvMVP1 = 33128:1:0 // Virtual Panel
#END_IF

#IF_NOT_DEFINED vdvMVP2
vdvMVP2 = 33132:1:0 // Virtual MVP 2
#END_IF


#IF_NOT_DEFINED dvDEBUG
dvDEBUG = 0:0:0 // Test Only
#END_IF

(***********************************************************)
(* CONSTANT DEFINITIONS GO BELOW *)
(***********************************************************)
DEFINE_CONSTANT

(* Link Pulse *)
TIMELINE_ONCE = 0
TIMELINE_REPEAT = 1
TIMELINE_ABSOLUTE = 0
TIMELINE_RELATIVE = 1

LINK_PULSE_TIMELINE = 1

(***********************************************************)
(* VARIABLE DEFINITIONS GO BELOW *)
(***********************************************************)
DEFINE_VARIABLE

// Link Lamp
INTEGER FLASH
VOLATILE LONG TIMEARRAY[1] = (1000)
VOLATILE LONG AS_SECS // Used by Auto Shutdown

(***********************************************************)
(* STARTUP CODE GOES BELOW *)
(***********************************************************)
DEFINE_START

//TIMEARRAY[1] = 1000 (* 1000 = 1 sec *)
TIMELINE_CREATE(LINK_PULSE_TIMELINE,TIMEARRAY,1,TIMELINE_ABSOLUTE,TIMELINE_REPEAT)

(***********************************************************)
(* THE EVENTS GO BELOW *)
(***********************************************************)
DEFINE_EVENT

TIMELINE_EVENT[LINK_PULSE_TIMELINE]
{
SWITCH(TIMELINE.SEQUENCE)
{
CASE 1:
{
FLASH = !FLASH
AS_SECS++
}
}
}

(***********************************************************)
(* THE ACTUAL PROGRAM GOES BELOW *)
(***********************************************************)
DEFINE_PROGRAM

// Link Lamp
[vdvMVP1,254] = FLASH
[vdvMVP2,254] = FLASH

(***********************************************************)
(* END OF PROGRAM *)
(* DO NOT PUT ANY CODE BELOW THIS COMMENT *)
(***********************************************************)

rosswylie

The code below is used to turn off the rooms by switching off the amps ect,

i have used the same channel codes to tell me whether the rooms are on or off, ie the link flashes when the room is off and when the room is on then the link stops flashing, could this be causing the problem

BUTTON_EVENT[AMP_OFF_BUTS]
{
PUSH:
{

ROOM_SELECT[MVP] = 0
AMP_SELECT = BUTTON.INPUT.CHANNEL-150
SEND_STRING dvDEBUG,"'Amp Off Selection - ',ITOA(AMP_SELECT)"
CALL 'KRAMER VS828' (K_BOTH,0,AMP_SELECT)
OFF[dvRELAYS_1,AMP_SELECT]
SELECT
{

ACTIVE(AMP_SELECT = 4) : //living room
{
SEND_COMMAND dvAMP_Living,"'SP',28"
PULSE[dvPioneerLiv,9]
//CALL 'MARANTZ 1 POWER' (dvMarantzLiv,PL_OFF)
}
ACTIVE(AMP_SELECT = 6) : //bedroom
{
SEND_COMMAND dvAMP_BEDROOM,"'SP',28"
PULSE[dvPioneerBED,9]
//CALL 'MARANTZ 2 POWER' (dvMarantzBed,PL_OFF)
}
ACTIVE(AMP_SELECT = 1) : //Kitchen
{
PULSE[dvLGKitchen,9]
//CALL 'MARANTZ 2 POWER' (dvMarantzBed,PL_OFF)
}

}
}
}

DHawthorne

The timeline looks fine to me, except that you are redefiing the constants to create it. As long as those values are the same as what the internal timeline code defines, there shouldn't be a problem - but you don't need to put in definitions for TIMELINE_ABSOLUTE, etc. Also, the usual way to initialize an array as you did for TIMEARRAY is TIMEARRAY[1] = {1000}. I don't know what the parenthesis do to it, but if it compiles OK, maybe it's fine, maybe not. The only other thing that might cause any of this code to create a runaway would be if something else is changing the LINK variable. If it's only done in the timeline, you should be OK.

Unrelated to any of this, you also don't need the precompiler directives in your DEFINE_DEVICE section (the #IF_DEFINED, etc. statements). It won't let you define a device twice no matter what you do, and unless you have a corresponding #DEFINE somewhere, those conditionals will never activate anyway.

But, at first glance, it really doesn't seem to me that this code is your problem. You need to check the notifications and see what is going on. Once a second is by no means too frequent. It may be your disconnects are unrelated to message traffic.

Chip Moody

You mean the curly-braces? You've declared an array, even though it's only one element in size. All arrays loaded in the declaration section need to have the elements "wrapped" in curly-braces, even if there's only one element... So, loading TIMEARRAY[3] would have looked like TIMEARRAY[3] = {1000,2000,3000}.

Not to be confused with updating an element elsewhere in the program, where you're doing TIMEARRAY[x] = y...

- Chip

DHawthorne wrote:

Also, the usual way to initialize an array as you did for TIMEARRAY is TIMEARRAY[1] = {1000}. I don't know what the parenthesis do to it, but if it compiles OK, maybe it's fine, maybe not.