Proper device boot sequence?

All,

I recently had made changes to a master, which is a master master to a larger system; it ended up working however causing issues with other things, so until we can fix these problems, I reverted to the prior code.
I have been made aware that 2 codecs connected to this master master are not communicating with the local TP for the master master or the adjacent control room, which remotely controls this master master.

They are tandberg mxp6k codecs, and are powered on, however key presses blink the input light on the master, however the TX/RX lights do nothing.

I am not onsight, and can only direct people on site.

I am assuming that the connection between the master and the codec is the problem, ie. no handshake essentially between the comm ports on the master and the codecs. ?

What would be the proper order to ensure everything comes online.
I have always made sure the devices were fully on before rebooting the master, but would it be better to completely boot the master then boot each device individually?

Again, being that I'm not onsite, I cannot watch diagnostics as devices come online, etc...

Any insight would be great!

Thanks all.

Comments

  • viningvining X Member Posts: 4,348
    however key presses blink the input light on the master, however the TX/RX lights do nothing.
    That would be my first concern but it may be the way the code is written it won't send strings if the dev isn't online so it really depends on the code. Most serial modules don't check an "online" flag to qualify sending strings but it is possible your code does.

    If your code is blocking strings to "offline" devices then you need to figure out why the devs are offline and in most cases power on devices before booting the master is preferred.

    If your code isn't blocking strings based on "online" status then your TX should at least be flashing regardless of the device's state, powered on or off. So why isn't TX flashing?

    Since TX leds aren't flashing I would say your code is either blocking based on "online" status, the master has the dreaded cap issue or your M2M url list has changed (if this issue spans masters). This assumes your running the code that previously worked.
  • I am awaiting to hear if anything is found on site, but yes this is the identical code that was working running now. And I can look through the code, but I cant find anything on my side that would block the tx lights when hitting a button. Im not sure whats going on in the duet jar though though, to know if that would block anything if not see as online.

    Ill reply back once I hear back, if there is anything new to add.

    thanks vining!



    Edit: (Here's the code to see if anything does stand out: this is the local code that directly connects to the codecs. )
    DEFINE_DEVICE{
    // NI 4100 *************************************************
    dvCodec1 = 5001:1:0 // Tandberg MXP Codec
    dvCodec2 = 5001:2:0 // Tandberg MXP Codec

    vdvCodec1_1 = 41001:1:0
    vdvCodec1_2 = 41001:2:0
    vdvCodec1_3 = 41001:3:0
    vdvCodec2_1 = 41002:1:0
    vdvCodec2_2 = 41002:2:0
    vdvCodec2_3 = 41002:3:0

    dvTP1_C = 10001:3:0 // Reserved for Codecs
    //...... other TP stuff..
    }

    DEFINE_VARIABLE{
    INTEGER nSelectedCodec[MAX_PANELS]

    VOLATILE DEV dvCodecs[]=
    {
    dvCodec1,
    dvCodec2
    // dvCodec3
    }
    VOLATILE DEV vdvCodecsPort1[]=
    {
    vdvCodec1_1,
    vdvCodec2_1
    // vdvCodec3_1
    }
    VOLATILE DEV vdvCodecsPort2[]=
    {
    vdvCodec1_2,
    vdvCodec2_2
    // vdvCodec3_2
    }
    VOLATILE DEV vdvCodecsPort3[]=
    {
    vdvCodec1_3,
    vdvCodec2_3
    // vdvCodec3_3
    }

    VOLATILE INTEGER nCodecBtns[]=
    {
    151, // Transmitting (feedback only)
    152, // Disconnect (Hang Up)
    153, // Duo Video toggle
    154 // Mic On/Off
    }

    VOLATILE INTEGER nCodec2Btns[]=
    {
    251, // Transmitting (feedback only)
    252, // Disconnect (Hang Up)
    253, // Duo Video toggle
    254 // Mic On/Off
    }
    }

    DEFINE_START{
    DEFINE_MODULE 'Tandberg_MXP_Comm_dr1_0_0' modCodec1(vdvCodec1_1,dvCodec1)
    DEFINE_MODULE 'Tandberg_MXP_Comm_dr1_0_0' modCodec2(vdvCodec2_1,dvCodec2)
    }

    DEFINE_EVENT{
    BUTTON_EVENT[dvTPC,150] // "YES" BUTTON ON THE "VTC WARNING" PAGE. SERVES AS CONFIRMATION.
    { // PAGE SHOWN ID USER TRIES TO DISCONNECT WHILE A VTC CALL IS ACTIVE
    PUSH :
    {
    OFF[vdvCodec1_1,238] // HANG UP / DISCONNECT CODEC
    OFF[vdvCodec1_2,238] // HANG UP / DISCONNECT CODEC
    //
    // SEND_COMMAND dvTPA,'@PPX'
    // SEND_COMMAND dvTPA,'PAGE-Security Level'
    // SEND_COMMAND dvTPA,'PPN-Security Level Title'
    }
    }

    BUTTON_EVENT[dvTPC,164] // Selfview
    {
    PUSH :
    {
    TO [vdvCodec1_1,191]
    }
    }

    BUTTON_EVENT[dvTPC,165] // Pip
    {
    PUSH :
    {
    TO [vdvCodec1_1,193]
    }
    }

    BUTTON_EVENT[dvTPC,141] // Camera Input
    {
    PUSH :
    {
    TO [dvTPC,BUTTON.INPUT.CHANNEL]
    SEND_COMMAND vdvCodec1_3,'INPUTSELECT-1'
    IF (![vdvCodec1_1,309])
    {
    SEND_COMMAND vdvCodec1_1,'INPUT-CAMERA,1'
    }
    }
    }

    BUTTON_EVENT[dvTPC,142] // PC Input
    {
    PUSH :
    {
    TO [dvTPC,BUTTON.INPUT.CHANNEL]
    IF (![vdvCodec1_1,309])
    {
    SEND_COMMAND vdvCodec1_1,'INPUT-DVI,1'
    }
    ELSE
    {
    SEND_COMMAND vdvCodec1_2,'INPUT-DVI,1'
    }
    }
    }

    BUTTON_EVENT[dvTPC,250] // "YES" BUTTON ON THE "VTC WARNING" PAGE. SERVES AS CONFIRMATION.
    { // PAGE SHOWN ID USER TRIES TO DISCONNECT WHILE A VTC CALL IS ACTIVE
    PUSH :
    {
    OFF[vdvCodec2_1,238] // HANG UP / DISCONNECT CODEC
    OFF[vdvCodec2_2,238] // HANG UP / DISCONNECT CODEC
    //
    // SEND_COMMAND dvTPA,'@PPX'
    // SEND_COMMAND dvTPA,'PAGE-Security Level'
    // SEND_COMMAND dvTPA,'PPN-Security Level Title'
    }
    }

    BUTTON_EVENT[dvTPC,264] // Selfview
    {
    PUSH :
    {
    TO [vdvCodec2_1,291]
    }
    }

    BUTTON_EVENT[dvTPC,265] // Pip
    {
    PUSH :
    {
    TO [vdvCodec2_1,293]
    }
    }

    BUTTON_EVENT[dvTPC,241] // Camera Input
    {
    PUSH :
    {
    TO [dvTPC,BUTTON.INPUT.CHANNEL]
    SEND_COMMAND vdvCodec2_3,'INPUTSELECT-1'
    IF (![vdvCodec2_1,309])
    {
    SEND_COMMAND vdvCodec2_1,'INPUT-CAMERA,1'
    }
    }
    }

    BUTTON_EVENT[dvTPC,242] // PC Input
    {
    PUSH :
    {
    TO [dvTPC,BUTTON.INPUT.CHANNEL]
    IF (![vdvCodec2_1,309])
    {
    SEND_COMMAND vdvCodec2_1,'INPUT-DVI,1'
    }
    ELSE
    {
    SEND_COMMAND vdvCodec2_2,'INPUT-DVI,1'
    }
    }
    }

    BUTTON_EVENT[dvTPC,nCodecBtns]
    {
    PUSH :
    {
    LOCAL_VAR INTEGER nIndex
    nIndex = GET_LAST(nCodecBtns)
    SWITCH (nIndex)
    {
    CASE 2: // Hang Up/Disconnect
    {
    OFF[vdvCodec1_1,238]
    OFF[vdvCodec1_2,238]
    }
    CASE 3: // DuoVideo toggle
    IF ([vdvCodec1_1,238])
    {
    PULSE[vdvCodec1_1,308]
    }
    ELSE
    SEND_COMMAND dvTPA[GET_LAST(dvTPA)],'ADBEEP' // only when in a call
    CASE 4: // Mic Toggle
    PULSE [vdvCodec1_1,145]
    }
    }
    }

    BUTTON_EVENT[dvTPC,nCodec2Btns]
    {
    PUSH :
    {
    LOCAL_VAR INTEGER nIndex
    nIndex = GET_LAST(nCodec2Btns)
    SWITCH (nIndex)
    {
    CASE 2: // Hang Up/Disconnect
    {
    OFF[vdvCodec2_1,238]
    OFF[vdvCodec2_2,238]
    }
    CASE 3: // DuoVideo toggle
    IF ([vdvCodec2_1,238])
    {
    PULSE[vdvCodec2_1,308]
    }
    ELSE
    SEND_COMMAND dvTPA[GET_LAST(dvTPA)],'ADBEEP' // only when in a call
    CASE 4: // Mic Toggle
    PULSE [vdvCodec2_1,145]
    }
    }
    }

    }

    DEFINE_PROGRAM{
    [dvTPC,nCodecBtns[1]] = ([vdvCodec1_1,238] || [vdvCodec1_2,238] || [vdvCodec1_3,238])
    [dvTPC,nCodecBtns[3]] = [vdvCodec1_1,309]
    [dvTPC,nCodecBtns[4]] = [vdvCodec1_1,146]
    [dvTPC,nCodec2Btns[1]] = ([vdvCodec2_1,238] || [vdvCodec2_2,238] || [vdvCodec2_3,238])
    [dvTPC,nCodec2Btns[3]] = [vdvCodec2_1,309]
    [dvTPC,nCodec2Btns[4]] = [vdvCodec2_1,146]
    }
  • rfletcherrfletcher Junior Member Posts: 217
    the duet module for tandberg mxp codecs does not send commands to the device unless it has successfully completed a handshake with the device. It will try to connect periodically (which you will see in device notifications and with the tx light blinking), but button presses generally will not result in a send string until the device is recognized as being online.

    If the tandberg is fully online when the amx system boots, and they aren't handshaking properly, i would double check everything about the connection between them. Make sure the baud rate on all devices is set correctly, make sure the cables are plugged in all the way, try replacing the cable, ect.

    -Ryan
  • AuserAuser Junior Member Posts: 506
    They are tandberg mxp6k codecs, and are powered on, however key presses blink the input light on the master, however the TX/RX lights do nothing.

    I would personally investigate the following:

    1 - There are known issues between certain firmware/development environment Duet versions. Update your AMX tools including the Duet runtimes and update the firmware on the control system.

    2 - You don't seem to be explicitly setting the baud rate for the device. From the Duet module document:
    If you are using RS-232, please verify that PROPERTY-Baud_Rate in the module and xConfiguration SerialPort 1 BaudRate on the MXP matches.

    ...

    If serially controlled, upon initialization the AMX Comm module will communicate with the device and information will be exchanged. Default baud rate is 9600. The Baud rate can be changed with the PROPERTY-Baud_Rate,[baud rate] followed by the REINIT command.
  • Thanks for the suggestions guys! I am still waiting to hear back on status.


    As for firmware/software versions. This is the original netlinx software vers and firmware verions loaded when this system was initially built; it is completely disconnected from the internet and will never be connected.
    So there should not be any change in software versions; I assume this was related to duet dependencies?
    ...if so, I did oringinally think about this, however because of the environment and 24/7 opperation of this system. nothing is tounched and all is houses in secure environments where nobody can access the physical units except people like me... who are unforntunetly thoasands of miles from them..
  • rfletcher wrote: »
    the duet module for tandberg mxp codecs does not send commands to the device unless it has successfully completed a handshake with the device. It will try to connect periodically (which you will see in device notifications and with the tx light blinking), but button presses generally will not result in a send string until the device is recognized as being online.

    If the tandberg is fully online when the amx system boots, and they aren't handshaking properly, i would double check everything about the connection between them. Make sure the baud rate on all devices is set correctly, make sure the cables are plugged in all the way, try replacing the cable, ect.

    -Ryan

    This is my thought.


    Hopefully once we get this fixed, I can post a reason, but for others in the future if they come across this problem, maybe this will help them visualize my possible problem....

    Just from playing aroudn here, I have tried to see how I could mess up a connection between the codec (which i dont have one local to truly test), but here is what I got from changing netlinx versions vs firmware verisons on my test 3100

    This is the failed to load drivers.
    Line 47 (14:54:40):: DA.processNewDevice: {Device-Revision=1.0.0, Device-Category=ip,serial,rs-232, Device-Make=TANDBERG, Physical-Device=5001:1:0, obje
    Line 48 (14:54:40):: ctClass=[Ljava.lang.String;@aab411, Device-SDKClass=com.amx.duet.devicesdk.VideoConferencer, Bundle-Version=2.0.0, Device-Model=MXP
    Line 49 (14:54:40):: ,3000MXP,6000MXP, Duet-Device=41001:1:0, service.id=4, Duet-Module=TANDBERG_MXP_COMM_dr1_0_0}
    Line 50 (14:54:46):: Device Access: DeviceAccess.loadDrivers - failed to resolve dependencies for /bundle/TANDBERG_MXP_COMM_dr1_0_0


    Heres successfully loading drivers:
    Line 127 (15:36:50):: DA.processNewDevice: {Device-Make=TANDBERG, Duet-Device=41002:1:0, Duet-Revision=1.0.0, Device-Revision=1.0.0, Device-SDKClass=com.
    Line 128 (15:36:50):: mx.duet.devicesdk.VideoConferencer, Physical-Device=5001:2:0, Device-Channels=350, Poll_Time=10000, Device-Levels=30, objectClass=[
    Line 129 (15:36:50):: java.lang.String;@4b7996, service.id=8, Duet-Make=TANDBERG, Device-Service=com.amx.duet.routers.snapi.ISNAPIRouter, IP_Address=10.0
    Line 130 (15:36:50):: 0.1, Bundle-Version=2.0.0, Timeout_Count=3, Port=23, Device-Model=MXP,3000MXP,6000MXP, Baud_Rate=9600, Duet-Model=MXP,3000MXP,6000M
    Line 131 (15:36:50):: P, Device-Category=ip,serial,rs-232}
    Line 132 (15:36:50):: Memory Available = 36631160 <12144>
    Line 133 (15:36:50):: DriverLocatorSnapiImpl.loadDriver : hits found = 1
    Line 134 (15:36:50):: DriverLocatorSnapiImpl.loadDriver : drivers found = 1
    Line 135 (15:36:50):: SNAPIRouter: VideoConferencerComponent loaded
    Line 136 (15:36:50):: SNAPIRouter: DialerComponent loaded
    Line 137 (15:36:50):: SNAPIRouter: VolumeComponent2 loaded
    Line 138 (15:36:51):: SNAPIRouter: PhonebookComponent loaded
    Line 139 (15:36:51):: SNAPIRouter: SourceSelectComponent3 loaded
    Line 140 (15:36:51):: SNAPIRouter: PowerComponent loaded
    Line 141 (15:36:51):: SNAPIRouter: CameraComponent2 loaded
    Line 142 (15:36:51):: SNAPIRouter: MenuComponent loaded
    Line 143 (15:36:51):: SNAPIRouter: ModuleComponent loaded
    Line 144 (15:36:51):: CIpEvent::OnLine 41002:1:2056
Sign In or Register to comment.