Home AMX User Forum NetLinx Modules & Duet Modules

iPort v3.21 module - NO R4

Hello (my first hello around here)

Quite new in the AMX, getting drawn in by my company's switch-over from C*.* to A*.*
I am busy programming a system which, amongst others, integrates an iPort. Any help would be highly appreciated in guiding me through the module utilization, but with 2 MVP52001 and two AXD-C4's (no R4)

Long story short, the provided UI interface with this module has provisions for R4's, and I was just wandering if I have to add a "dummy" one, or edit all the references to R4 out from the UI module.

Many thanks.

Comments

  • viningvining Posts: 4,368
    You should be able to just create a virtual R4 D:P:S and just use that in the code.
  • jjamesjjames Posts: 2,908
    Hello (my first hello around here)

    Quite new in the AMX, getting drawn in by my company's switch-over from C*.* to A*.*
    I am busy programming a system which, amongst others, integrates an iPort. Any help would be highly appreciated in guiding me through the module utilization, but with 2 MVP52001 and two AXD-C4's (no R4)

    Long story short, the provided UI interface with this module has provisions for R4's, and I was just wandering if I have to add a "dummy" one, or edit all the references to R4 out from the UI module.

    Many thanks.

    Since there are only a total of 4 references, I took them out of the UI module.
  • Thanks gents.

    Am I correct then in saying that the header of my UI module will be showing:
    MODULE_NAME='iPort_UI' (DEV vdviPort, DEV dvTP[], INTEGER TP_BUTTONS[],INTEGER TP_FIELDS[], INTEGER TP_LEVELS[], INTEGER nLISTS[])
    			//************INTEGER nR4_DMS_Port1, INTEGER nR4_DMS_Port2) these two arguments commented out
    

    plus also removing the four references to the R4's in the module body?

    line 1365 to 1381
    DEFINE_FUNCTION fnPAGE_FLIP_NP()
    {
        STACK_VAR INTEGER nTEMP
        
        nTEMP = GET_LAST(dvTP)
        
    //    SELECT   //This is done to page flip back to the corresponding iPort Page if there are multiple iPorts controlled from 1 DMS
    //    {		// More ports can be added depending on how many iPorts are being controlled by one DMS
    //	ACTIVE (nR4_DMS_PORT1 = nCURRENT_TP_PORT):
    //	{
    //	    SEND_COMMAND dvTP[nTEMP], 'PAGE-iPort Now Playing' //Flip DMS page to Now Playing page 1
    //	    WAIT 5
    //	    SEND_VTEXT(TP_FIELDS[19],'q') // q = play icon with AMXBOLD font
    //	    ON[dvTP,TP_BUTTONS[3]] //turns DMS play button ON
    //	}
    //	ACTIVE (nR4_DMS_PORT2 = nCURRENT_TP_PORT):
    //	{
    //	    SEND_COMMAND dvTP[nTEMP], 'PAGE-iPort Now Playing 2' //Flip DMS page to Now Playing page 2
    //	    WAIT 5
    //	    SEND_VTEXT(TP_FIELDS[19],'q') // q = play icon with AMXBOLD font
    //	    ON[dvTP,TP_BUTTONS[3]] //turns DMS play button ON
    //	}
    //    }
    }
    

    and line 1545 to 1555
    			//SELECT	//This is done to page flip back to the corresponding iPort Menu if there are multiple iPorts controlled from 1 DMS
    //			{		
    //			    ACTIVE (nR4_DMS_PORT1 = nCURRENT_TP_PORT):
    //			    {
    //				SEND_COMMAND dvTP[nTEMP], 'PAGE-iPort Menu' //Flip DMS page back to Menu 1
    //			    }
    //			    ACTIVE (nR4_DMS_PORT2 = nCURRENT_TP_PORT):
    //			    {
    //				SEND_COMMAND dvTP[nTEMP], 'PAGE-iPort Menu 2' //Flip DMS page back to Menu 2
    //			    }
    //			}
    
  • jjamesjjames Posts: 2,908
    That is exactly what I did and am not having any problems (yet.)
  • Thanks James. It did the trick here as well...

    I am surprised you say "no problems", or maybe I am doing something wrong...
    I could not get a decent feedback from the module vdviPort with v3.21. For some odd reason, the strings were "delivered" only like every other second, the fastest. The current time count would only update at 2 - 3 seconds, not to mention that the song title, the total track time and so forth would have to be lucky to get parsed and delivered.
    When watching the actual serial port, the strings were having a pace of 4-5 updates per second, which makes me believe that the module itself does not make an OUT for every IN.
    Never the less, when I overwrote the "iPort COMM" file with v3.0 beta, everything started to become alive and every input string had a parsed value at the exit from the module...

    I would be curious if I might have overlooked something, and I am interested in finding a way to give a chance to v3.21, as it seems to be addressing some bugs as well.
  • jjamesjjames Posts: 2,908
    The only issue I had was it stopped communicated . . . but I had my tech reboot the iPort and undock the iPod . . . all seemed fine after that. I'm offsite so I'm not exactly sure what's going on - but no complaints.
Sign In or Register to comment.