Funny you mentioned that. Just for kicks, after i successfully was talking over terminal, i power cycled completely. AC and battery for 30 seconds, applied power and there i was talking to the NI, went to another site, copied my parameters, cycled power and that as well came on-line? Now at both sites I am talking and can carry on with graphic rendering, etc. GE tech support ( 3rd guy ) wanted me to put a part # NX-587E on the Bus as a emulator, i was wondering why we have not needed in the past but these now we do? No reply, just that the part is a keypad emulator and sits on address 248. But if you dont have a addressed keypad at that location, what is it emulating? Anyways here is what i have set on the NX-8E panel only with a P-0003 cable with this pinout:
GE NI
2 3
3 2
5 5
NX-8E parameters
loc.207
1
loc.208
2
loc.209
1
loc.210
seg1
25678
seg2
134
loc.211
seg.1
245678
seg.2
1345
seg.3
seg.4
3458 - this one in particular, I found you need to have set if you have one keypad, make it a primary
loc.212
192 - this is the address of keypad 1 on partition 1 - the GE will send thru the RS232 what that keypad is doing or getting from the panel as well.
After all settings are done, leave power on NX-8E for 1 min ( GE recommends this due to bus scanning and settings are taking place ) after that remove power completely from GE and apply, should be good, or at least it worked for us on two seperate sites.
I encountered a problem using the ReQuest Duet module, where once the device was powered off via the module, after about 1 minute it seemed impossible to switch it back on again using the module. If you tried to switch it on before 1 minute was up then it worked fine.
The work around I used was to send IR command to switch it back on. Not sure if it was a module problem or device problem.
I really wish AMX would make the source code for modules available or at least provide templates for different device module types. I love using modules as they save so much time and if I need to create modules then I try to model then to the standards, having tempates availabel would save me so much time.
The ability to make forum type comments/bug encountered where you download the modules would also be extremely usefu. This would make users aware of any problem they encounter using the modules. Also a formal way of reporting problems in the modules where AMX followed up and fixed them would be great.
I encountered a problem using the ReQuest Duet module, where once the device was powered off via the module, after about 1 minute it seemed impossible to switch it back on again using the module. If you tried to switch it on before 1 minute was up then it worked fine.
Probably because you're supposed to leave the ARQ on all the time. I don't see why you'd want to power it off via the module and I wouldn't consider this particular issue a bug. The unit takes a loooong time to come up and about a minute to shut down, if you issue an "on" while shutting down it probably cancels the shutdown somehow.
Yesterday I had an extremely painful experience with the Duet module for the Lectrosonics DM series digital audio processors. Specifically, using this module with a DM1612.
I am beating my head against the wall now with the DM1624 module trying to control a DM812. I finally got the module sending strings and working but the DM just will NOT respond in any way. I've been looking for the "secret switch" LOL
~Avguy49
When AMX started releasing modules - 10 years ago? - I found that they were concentrating on home theater stuff, and not on the gear that I needed. So I started writing my own. I have since found that the Duet modules in general are seriously bloated and slow, and pretty much impossible to troubleshoot. Also, the channel-based API is severely limiting. It's fine for stuff like telling a display to turn on, but it's not so fine for telling a Biamp to unmute the fader in unit 2 with instance ID tag 'prog_audio'. For anything with a remotely complex API - like a Biamp or other audio DSP, or any VTC system - it's just easier to code it directly. If the module's API is just as complex as the device's native protocol, then why bother dealing with the module?
My Netlinx display control modules only query and control the parameters I care about (power, input, picture mute and lamp hours, plus 'PASSTHRU=' just in case). Just because the protocol supports adjusting the red black-level gamma, that doesn't mean I want to do that from a touchpanel.
The most important thing about rolling my own modules is code reusability: any matrix switcher (for example) behaves exactly the same from the main program's perspective. If my new project has an Autopatch instead of an Extron, I just drop in the appropriate homebrewed module and I'm done.
I don't think I've ever used an AMX UI module. The button-per-function mentality is just too limiting, and alien.
.
Hi All,
I thought I might as well throw my ore in on the module front after having another bad module experience. I, like most try and write my own modules generally do just the vital few commands but to keep track of them as needed.
Last week I used the panasonic projector module from AMX, to cheer me up I found that moving the channel levels for power and mute I was able control those functions and the module would keep the projector in check! Not so for input it appears. This was sent by a command to the module and, if timed wrong, could be completely ignored by the projector leaving the module and the projector out of sync.
So.... My wish list for modules is fairly simple. For display devices I'd like the module to take care of the displays status at all times, thus if I ask the module for a power on and select input 1 then the module will keep an eye on the projector and make sure that when it has powered up it is indeed on input 1 and if not, do something about it!
If the above behaves as requested it makes stitching the rest of the code together a far easier job. All that is required timing wise from the device interface is if the projector is cooling or warming. Everything else should look after itself.
Hi All,
I thought I might as well throw my ore in on the module front after having another bad module experience. I, like most try and write my own modules generally do just the vital few commands but to keep track of them as needed.
Last week I used the panasonic projector module from AMX, to cheer me up I found that moving the channel levels for power and mute I was able control those functions and the module would keep the projector in check! Not so for input it appears. This was sent by a command to the module and, if timed wrong, could be completely ignored by the projector leaving the module and the projector out of sync.
So.... My wish list for modules is fairly simple. For display devices I'd like the module to take care of the displays status at all times, thus if I ask the module for a power on and select input 1 then the module will keep an eye on the projector and make sure that when it has powered up it is indeed on input 1 and if not, do something about it!
If the above behaves as requested it makes stitching the rest of the code together a far easier job. All that is required timing wise from the device interface is if the projector is cooling or warming. Everything else should look after itself.
Too much to ask!?
Kind Regards
Colin
I've noticed a trend by the major display manufacturers of moving away from rs232. Most are just doing IR and perhaps their own internal company control method that might speak to their gear. Also, if you have the ability to pop in on the HDMI you can control it there. But, I think the days of TVs being controlled by rs232 are fast coming to an end.
Having said that, it's hard for any prewritten modules to keep up with this sector of the AV world.
So.... My wish list for modules is fairly simple. For display devices I'd like the module to take care of the displays status at all times, thus if I ask the module for a power on and select input 1 then the module will keep an eye on the projector and make sure that when it has powered up it is indeed on input 1 and if not, do something about it!
If the above behaves as requested it makes stitching the rest of the code together a far easier job. All that is required timing wise from the device interface is if the projector is cooling or warming. Everything else should look after itself.
That's how I've always written my own modules for display control.
Ditto here. Same with all devices. If you tell something to do it, then it should.
+1. There's no point using AMX modules when you have to implement queuing and timing of commands to the module to ensure that the module honours those commands and makes the device do what you're after.
It's usually quicker and more reliable to roll your own because of the way AMX modules generally operate.
So.... My wish list for modules is fairly simple. For display devices I'd like the module to take care of the displays status at all times, thus if I ask the module for a power on and select input 1 then the module will keep an eye on the projector and make sure that when it has powered up it is indeed on input 1 and if not, do something about it!
I would have to disagree, and I don't write my display modules that way. If a command to turn on a projector is sent and the projector is cooling down, and so can't be turned on, the last thing I want is for it to remember the command and then turn it on after the cool down period. Same if an off command is sent during warmup. The reason being is that projectors are often on lifts that retract into the ceiling and if left on in that case can cause a fire or overheat. If someone chooses a source and the projector is cooling down, they might walk away thinking its broken. Then it comes on and no one is there to turn it off. What I prefer is to leave it to the client code to do whatever it thinks is best considering the situation, and the module just sends its current state whenever it changes. The client code can ask the module for its current state at any time so there is no confusion. If someone hits a source when its cooling down, then the client code can print a message or do something intelligent depending on the situation.
As for input switching, I like to leave that to client code as well. Its up to the client code to track the power state and switch inputs once its powered up not the module. The module just supplies everything the client code needs to do this properly.
Paul
I would have to disagree, and I don't write my display modules that way. If a command to turn on a projector is sent and the projector is cooling down, and so can't be turned on, the last thing I want is for it to remember the command and then turn it on after the cool down period. Same if an off command is sent during warmup. The reason being is that projectors are often on lifts that retract into the ceiling and if left on in that case can cause a fire or overheat. If someone chooses a source and the projector is cooling down, they might walk away thinking its broken. Then it comes on and no one is there to turn it off. What I prefer is to leave it to the client code to do whatever it thinks is best considering the situation, and the module just sends its current state whenever it changes. The client code can ask the module for its current state at any time so there is no confusion. If someone hits a source when its cooling down, then the client code can print a message or do something intelligent depending on the situation.
As for input switching, I like to leave that to client code as well. Its up to the client code to track the power state and switch inputs once its powered up not the module. The module just supplies everything the client code needs to do this properly.
Paul
I agree that if a projector is warming ot cooling any button pushes for the projector should be ignored and a message popped stating commands are not accepted during this period or just a "bonk" sound. Queuing commands during this period could easliy cause mechanical problems or hazards as mention but even if that isn't a real issue it would drive the client nuts when the timeout period ends and the module cycles through the queued commands that may have been collected during that time frame. Otherwise the module should manage the device unless there's a possibilty of the user interfacing directly with the display or using a non AMX control. You don't want the client fighting with the program.
I would have to disagree, and I don't write my display modules that way. If a command to turn on a projector is sent and the projector is cooling down, and so can't be turned on, the last thing I want is for it to remember the command and then turn it on after the cool down period. Same if an off command is sent during warmup. The reason being is that projectors are often on lifts that retract into the ceiling and if left on in that case can cause a fire or overheat. If someone chooses a source and the projector is cooling down, they might walk away thinking its broken. Then it comes on and no one is there to turn it off. What I prefer is to leave it to the client code to do whatever it thinks is best considering the situation, and the module just sends its current state whenever it changes. The client code can ask the module for its current state at any time so there is no confusion. If someone hits a source when its cooling down, then the client code can print a message or do something intelligent depending on the situation.
As for input switching, I like to leave that to client code as well. Its up to the client code to track the power state and switch inputs once its powered up not the module. The module just supplies everything the client code needs to do this properly.
Paul
If the client code is sending a power on command to the module I'd hope it's also dropping the projector lift at the same time, every time. Otherwise the situation you describe, with the projector on but in the ceiling, is possible with both methods of control and, as you say, is a very bad thing.
If, however, the lift is being dropped whenever you send a power on command to the module, and can't be raised without sending a power off command, it shouldn't be possible to have a projector on in the ceiling with either method of control.
Queuing commands during this period could easliy cause mechanical problems or hazards as mention but even if that isn't a real issue it would drive the client nuts when the timeout period ends and the module cycles through the queued commands that may have been collected during that time frame.
It depends on the way it's cued. Agreed, the last thing you want is to have the user sit through a mute > input change > mute > umute etc feature show. You can set up the cues to only remember the latest requested state and make sure that the device is always moving towards that whenever it is capable. For example if the user walks into the room and attempts to display something from a laptop, then 20 seconds later changes their mind and goes to play a DVD the user interface can reflect the requested state instantly, and provide information while the rest of the system warms up and transitions to that state. The user should be in control of the equipment, not the other way round.
The module can provide feedback about the current state which can be used by the client code. This gives the programmer implementing the module the ability to control cueing (ie turn on, wait for it to warm, then shoot the device a state change request), or alternatively he/she can just tell it to head to a specific state and have the module handle anything required to make that happen in the background.
I don't use discreet buttons for projectors the systems I work on. Most systems are conference systems and selecting a source is the prompt to bring the projector on, shutting down the system resests everything and switches the projector off.
The module will make sure that the projector is on and it's input /mute state are where I expect them to be.
As the amx code will lock the system with a shutdown animation whilst it receives real feedback from the projector module that it is cooling there will not be a situation where the projector can get hoiked up into the ceiling whilst being on! Besides, as the hoist and the projector commands would be tied together the module will never receive a power on request without the hoist dropping. More to the point, the module will make sure that if the projector is up in the ceiling it is very much off!!
I guess it depends on approach. I find a module that I can fire commands at such as input, irrespective of timing and know that it will sort out the projector when it's ready (ie after warming up)... the most useful. It negates the need to have to place timing commands in your main program. When a source is selected I can simply send projector on and DVI input and know that the projector will end up where I expect it once it's up and running.
The previous debate over the need to embed automation logic in a module is very thought provoking. There are good arguments for both methods.
AMX has determined that automation logic belongs outside the com module (device driver.) This allows module development to be consistent and allow quicker turn-around. The AMX supplied UI modules are provided for example purposes only and provide a method to the test the controlled component in a stand-alone environment.
My intent in starting the thread was to provide a place to report specific modules that may have defects and need some revision.
I think the clearone converge modules are shockingly bad and more or less useless.
While I've always written my own modules, I recently tried some for a system
that had a few clearone devices and the AMX modules seemed like they
might speed things up. No such luck.
The disconcerting aspect of using this device is that some of my best contacts
at AMX couldn't verify some of its functionality. Moreover, what is really
kind of heartbreaking is to see the bloated DUET files along side the
single ******** module. While I spent time just trying to figure out how to make basic
functions happen, like volume, my friend downloaded the creston module
and had it running in minutes. That kind of makes me feel like I picked the wrong team.
I've always found AMX modules to be over complicated and they also don't tend to take into account the need of the integrator. Its as though they are written with the device in front of the programmer and when it works thats it with no thought how its going to be used in the real world. I've always tended to write my own modules and I write them for others. I have used a few modules written by AMX in the past but have always found them to be painful to integrate.
I don't stick to AMX's module layout, I have my own and it allows me to put stuff together really quickly and I don't have to wait to see if someone decides that there is enough of an issue with a module to fix it.
Don't even get me started on DUET modules.
Modules are something that Cre$tron are very good at doing and supporting, maybe someone should take a leaf out of their book. They value & listen to their programmers...and it works!
Comments
Funny you mentioned that. Just for kicks, after i successfully was talking over terminal, i power cycled completely. AC and battery for 30 seconds, applied power and there i was talking to the NI, went to another site, copied my parameters, cycled power and that as well came on-line? Now at both sites I am talking and can carry on with graphic rendering, etc. GE tech support ( 3rd guy ) wanted me to put a part # NX-587E on the Bus as a emulator, i was wondering why we have not needed in the past but these now we do? No reply, just that the part is a keypad emulator and sits on address 248. But if you dont have a addressed keypad at that location, what is it emulating? Anyways here is what i have set on the NX-8E panel only with a P-0003 cable with this pinout:
GE NI
2 3
3 2
5 5
NX-8E parameters
loc.207
1
loc.208
2
loc.209
1
loc.210
seg1
25678
seg2
134
loc.211
seg.1
245678
seg.2
1345
seg.3
seg.4
3458 - this one in particular, I found you need to have set if you have one keypad, make it a primary
loc.212
192 - this is the address of keypad 1 on partition 1 - the GE will send thru the RS232 what that keypad is doing or getting from the panel as well.
After all settings are done, leave power on NX-8E for 1 min ( GE recommends this due to bus scanning and settings are taking place ) after that remove power completely from GE and apply, should be good, or at least it worked for us on two seperate sites.
I encountered a problem using the ReQuest Duet module, where once the device was powered off via the module, after about 1 minute it seemed impossible to switch it back on again using the module. If you tried to switch it on before 1 minute was up then it worked fine.
The work around I used was to send IR command to switch it back on. Not sure if it was a module problem or device problem.
I really wish AMX would make the source code for modules available or at least provide templates for different device module types. I love using modules as they save so much time and if I need to create modules then I try to model then to the standards, having tempates availabel would save me so much time.
The ability to make forum type comments/bug encountered where you download the modules would also be extremely usefu. This would make users aware of any problem they encounter using the modules. Also a formal way of reporting problems in the modules where AMX followed up and fixed them would be great.
I am beating my head against the wall now with the DM1624 module trying to control a DM812. I finally got the module sending strings and working but the DM just will NOT respond in any way. I've been looking for the "secret switch" LOL
~Avguy49
My Netlinx display control modules only query and control the parameters I care about (power, input, picture mute and lamp hours, plus 'PASSTHRU=' just in case). Just because the protocol supports adjusting the red black-level gamma, that doesn't mean I want to do that from a touchpanel.
The most important thing about rolling my own modules is code reusability: any matrix switcher (for example) behaves exactly the same from the main program's perspective. If my new project has an Autopatch instead of an Extron, I just drop in the appropriate homebrewed module and I'm done.
I don't think I've ever used an AMX UI module. The button-per-function mentality is just too limiting, and alien.
.
Hi All,
I thought I might as well throw my ore in on the module front after having another bad module experience. I, like most try and write my own modules generally do just the vital few commands but to keep track of them as needed.
Last week I used the panasonic projector module from AMX, to cheer me up I found that moving the channel levels for power and mute I was able control those functions and the module would keep the projector in check! Not so for input it appears. This was sent by a command to the module and, if timed wrong, could be completely ignored by the projector leaving the module and the projector out of sync.
So.... My wish list for modules is fairly simple. For display devices I'd like the module to take care of the displays status at all times, thus if I ask the module for a power on and select input 1 then the module will keep an eye on the projector and make sure that when it has powered up it is indeed on input 1 and if not, do something about it!
If the above behaves as requested it makes stitching the rest of the code together a far easier job. All that is required timing wise from the device interface is if the projector is cooling or warming. Everything else should look after itself.
Too much to ask!?
Kind Regards
Colin
I've noticed a trend by the major display manufacturers of moving away from rs232. Most are just doing IR and perhaps their own internal company control method that might speak to their gear. Also, if you have the ability to pop in on the HDMI you can control it there. But, I think the days of TVs being controlled by rs232 are fast coming to an end.
Having said that, it's hard for any prewritten modules to keep up with this sector of the AV world.
That's how I've always written my own modules for display control.
Ditto here. Same with all devices. If you tell something to do it, then it should.
+1. There's no point using AMX modules when you have to implement queuing and timing of commands to the module to ensure that the module honours those commands and makes the device do what you're after.
It's usually quicker and more reliable to roll your own because of the way AMX modules generally operate.
I would have to disagree, and I don't write my display modules that way. If a command to turn on a projector is sent and the projector is cooling down, and so can't be turned on, the last thing I want is for it to remember the command and then turn it on after the cool down period. Same if an off command is sent during warmup. The reason being is that projectors are often on lifts that retract into the ceiling and if left on in that case can cause a fire or overheat. If someone chooses a source and the projector is cooling down, they might walk away thinking its broken. Then it comes on and no one is there to turn it off. What I prefer is to leave it to the client code to do whatever it thinks is best considering the situation, and the module just sends its current state whenever it changes. The client code can ask the module for its current state at any time so there is no confusion. If someone hits a source when its cooling down, then the client code can print a message or do something intelligent depending on the situation.
As for input switching, I like to leave that to client code as well. Its up to the client code to track the power state and switch inputs once its powered up not the module. The module just supplies everything the client code needs to do this properly.
Paul
If the client code is sending a power on command to the module I'd hope it's also dropping the projector lift at the same time, every time. Otherwise the situation you describe, with the projector on but in the ceiling, is possible with both methods of control and, as you say, is a very bad thing.
If, however, the lift is being dropped whenever you send a power on command to the module, and can't be raised without sending a power off command, it shouldn't be possible to have a projector on in the ceiling with either method of control.
The module can provide feedback about the current state which can be used by the client code. This gives the programmer implementing the module the ability to control cueing (ie turn on, wait for it to warm, then shoot the device a state change request), or alternatively he/she can just tell it to head to a specific state and have the module handle anything required to make that happen in the background.
The module will make sure that the projector is on and it's input /mute state are where I expect them to be.
As the amx code will lock the system with a shutdown animation whilst it receives real feedback from the projector module that it is cooling there will not be a situation where the projector can get hoiked up into the ceiling whilst being on! Besides, as the hoist and the projector commands would be tied together the module will never receive a power on request without the hoist dropping. More to the point, the module will make sure that if the projector is up in the ceiling it is very much off!!
I guess it depends on approach. I find a module that I can fire commands at such as input, irrespective of timing and know that it will sort out the projector when it's ready (ie after warming up)... the most useful. It negates the need to have to place timing commands in your main program. When a source is selected I can simply send projector on and DVI input and know that the projector will end up where I expect it once it's up and running.
The previous debate over the need to embed automation logic in a module is very thought provoking. There are good arguments for both methods.
AMX has determined that automation logic belongs outside the com module (device driver.) This allows module development to be consistent and allow quicker turn-around. The AMX supplied UI modules are provided for example purposes only and provide a method to the test the controlled component in a stand-alone environment.
My intent in starting the thread was to provide a place to report specific modules that may have defects and need some revision.
I think the clearone converge modules are shockingly bad and more or less useless.
While I've always written my own modules, I recently tried some for a system
that had a few clearone devices and the AMX modules seemed like they
might speed things up. No such luck.
The disconcerting aspect of using this device is that some of my best contacts
at AMX couldn't verify some of its functionality. Moreover, what is really
kind of heartbreaking is to see the bloated DUET files along side the
single ******** module. While I spent time just trying to figure out how to make basic
functions happen, like volume, my friend downloaded the creston module
and had it running in minutes. That kind of makes me feel like I picked the wrong team.
I don't stick to AMX's module layout, I have my own and it allows me to put stuff together really quickly and I don't have to wait to see if someone decides that there is enough of an issue with a module to fix it.
Don't even get me started on DUET modules.
Modules are something that Cre$tron are very good at doing and supporting, maybe someone should take a leaf out of their book. They value & listen to their programmers...and it works!