iPort v3.21 module - NO R4
felixmoldovan
Junior Member
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.
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
-
You should be able to just create a virtual R4 D:P:S and just use that in the code.
-
felixmoldovan wrote: »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 1381DEFINE_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 // } // } -
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. -
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.
Categories
- All Categories
- 2.5K AMX General Discussion
- 922 AMX Technical Discussion
- 514 AMX Hardware
- 502 AMX Control Products
- 3 AMX Video Distribution Products
- 9 AMX Networked AV (SVSI) Products
- AMX Workspace & Collaboration Products
- 3.4K AMX Software
- 151 AMX Resource Management Suite Software
- 386 AMX Design Tools
- 2.4K NetLinx Studio
- 135 Duet/Cafe Duet
- 248 NetLinx Modules & Duet Modules
- 57 AMX RPM Forum
- 228 MODPEDIA - The Public Repository of Modules for Everyone
- 943 AMX Specialty Forums
- 2.6K AMXForums Archive
- 2.6K AMXForums Archive Threads
- 1.5K AMX Hardware
- 432 AMX Applications and Solutions
- 249 Residential Forum
- 182 Tips and Tricks
- 146 AMX Website/Forums
