Home NetLinx Modules & Duet Modules

2 identical Sharp projectors, 1 system

I have 2 Sharp XG435XU projectors in 1 room.

Do I need to load 2 modules, or can I define/address the two projectors to respond a single module?

Thanks,

Doug Menke

Comments

  • ericmedleyericmedley Senior Member - 4000+ posts Posts: 4,177
    dmenke wrote: »
    I have 2 Sharp XG435XU projectors in 1 room.

    Do I need to load 2 modules, or can I define/address the two projectors to respond a single module?

    Thanks,

    Doug Menke


    Two of the same module with two different real devices (where you plug in the RS-232 connection) and two virtual devices. ( vdv_Proj_1 = 33001:01:0 vdv_Proj_2= 33002:01:0) ... something like that.
  • JeffJeff Junior Member Posts: 374
    This is where the module name comes in.
    define_module 'Christie LX650 Rev1-00' proj1(vdvTP_Proj1,vdvProj1,dvProj1)
    define_module 'Christie LX650 Rev1-00' proj2(vdvTP_Proj2,vdvProj2,dvProj2)
    

    The first module is named proj1, the second module is named proj 2. They both work.

    The real downside is its now a huge pain in the butt to view variables within each module. I haven't found a way around this, has anyone else?

    J
  • DHawthorneDHawthorne Junior Member Posts: 4,584
    Jeff wrote: »
    This is where the module name comes in.
    define_module 'Christie LX650 Rev1-00' proj1(vdvTP_Proj1,vdvProj1,dvProj1)
    define_module 'Christie LX650 Rev1-00' proj2(vdvTP_Proj2,vdvProj2,dvProj2)
    

    The first module is named proj1, the second module is named proj 2. They both work.

    The real downside is its now a huge pain in the butt to view variables within each module. I haven't found a way around this, has anyone else?

    J

    Nope, it's one of the known shortcomings of the debugging system. What I do when having trouble is comment out all but the device I am having trouble with, then debug it. When it's going right, I un-comment the rest and move on.
  • dmenkedmenke Junior Member Posts: 25
    OK, I understand how to do it, but does it actually run 2 instances of the module, or just communicate properly with one module?

    Will doing this bog down the master?

    Thanks for the help so far!

    Doug
  • JeffJeff Junior Member Posts: 374
    It creates two instances of the module.

    It doesn't bog down the master, at least as far as I've been able to tell.

    We have had a problem lately with RS232 ports suddenly having no receive data anymore. When we call AMX, they go through all the test motions, conclude that the ports dont work, and we ship it back and they fix it. After about 10 of these (over a year or more) they started to suggest that maybe our problem was in all the polling we do. Our modules poll status every second or two, and they seemed to think that was excessive. The other thing they particularly pointed out as problematic was when we included multiple modules that all started at the same time that all polled the same thing. For example, 3 identical projectors declared in code like my prior example.

    What we ended up doing was putting a line in the module that allows you to pulse it to start polling. Then, in the mainline, you stagger the pulses to the individual modules, and they all end up polling slightly off, not at the same time. After 20 seconds, if that channel isn't pulsed, the module starts polling automatically, so if you forget to put the line in, its no big deal.

    I can't say I'm convinced this is necessary, but if you've run into that problem, thats AMX's current suggestion for how to avoid it.

    J
  • a_riot42a_riot42 AMX Wizard Posts: 1,619
    Jeff wrote: »
    Our modules poll status every second or two, and they seemed to think that was excessive. The other thing they particularly pointed out as problematic was when we included multiple modules that all started at the same time that all polled the same thing. For example, 3 identical projectors declared in code like my prior example.

    Why do you feel the need to poll so much and so often? Projectors are slow beasts.
    My understanding was that regardless of how many instances you have of a module, the code is loaded only once.
    Paul
  • JeffJeff Junior Member Posts: 374
    Threadjack alert . . . .

    I poll every second. I poll 4 things, Power, Input, Lamp Status, and Video Mute Status. (Usually). one each second. Sometimes its every 2 seconds, depending on the projector.

    I poll that fast because I do all of my feedback on the panel based on answers from the projector. I try to avoid fake feedback, so I make sure I'm polling fast enough to show the user what's happening in a timely manner.

    J
  • ColzieColzie Senior Member Posts: 470
    Jeff wrote: »
    Threadjack alert . . . .

    I poll every second. I poll 4 things, Power, Input, Lamp Status, and Video Mute Status. (Usually). one each second. Sometimes its every 2 seconds, depending on the projector.

    I poll that fast because I do all of my feedback on the panel based on answers from the projector. I try to avoid fake feedback, so I make sure I'm polling fast enough to show the user what's happening in a timely manner.

    J

    I generally do this as well. This summer I had 3 identical rooms (3 masters), each with 4 projectors running identical modules. No problems.
  • ericmedleyericmedley Senior Member - 4000+ posts Posts: 4,177
    It is true that most devices don't like to be polled much. I've found that most the Marantz stuff we do doesn't like to be polled much faster than every three seconds. I remember hitting Epson projectors more than once every 5 seconds was a bad thing too. One would think it shouldn't matter since most processors are running above 50Mhz nowadays. But it still seems to be an issue.
  • a_riot42a_riot42 AMX Wizard Posts: 1,619
    I poll projectors once every 5 to 10 seconds when they are not off. If I poll every 5 seconds, the average time until a panel will get updated after an event is 2.5 seconds. That's more than fast enough for a slow device like a projector. I usually try to keep communication at a minimum by using lazy logic and poll as little as possible and not write code in define_program so that the system responds to button events as quickly as possible. You may even find that keeping the system so busy polling, you are adding so much overhead that it actually increases the feedback lag rather than decreasing it.
    Paul
  • patbpatb Junior Member Posts: 140
    I poll at different rates for different things. For lamp hours that only change once per hour - I poll once every 30 mins. For power I poll every 5 minutes if nothing is going on in the module, but when I press a power button and send a power command I poll once per second until I get a valid response back from the projector and then drop back to the once every 5 mintue polling. Seems silly to poll every second for lamp hours when it only changes once per hour - it.

    I am used to dealing with very large systems with multiple instances of the same module - I've done ones in the last year with 37 LCD panels (museum), another system with 25 projectors and 12 plasmas (museum), another system with 36 projectors and 12 plasma/LCDs (bowling alley), and a sports bar with 6 projectors and 18 plasmas. In systems of this size even the slightest change in the module can greatly affect the performance and speed of the code. For a typical home theater you might be able to get a way with polling 4 things once per second, but put 36 instances of that same module in a piece of code and that system will grind to a halt because it is running so slow. One of the advantages of the system I do is that the AMX is the ONLY way to control anything. If the user didn't push a button on the touch panel then nothing changed. I don't typically poll for input status and pic mute status until a button is pressed becasue that is the only way for it to change.

    Another tip for polling and keeping up the speed of the system that was mentioned in the previous post. I agree with it strongly - put nothing in the define_program section of a module. Put all polling inside of a timeline.
  • a_riot42a_riot42 AMX Wizard Posts: 1,619
    Jeff wrote: »
    This is where the module name comes in.
    define_module 'Christie LX650 Rev1-00' proj1(vdvTP_Proj1,vdvProj1,dvProj1)
    define_module 'Christie LX650 Rev1-00' proj2(vdvTP_Proj2,vdvProj2,dvProj2)
    

    The first module is named proj1, the second module is named proj 2. They both work.

    The real downside is its now a huge pain in the butt to view variables within each module. I haven't found a way around this, has anyone else?

    J

    This might work better for you.

    define_variable
    vdvTPs[] = {vdvTP1, vdvTP2}
    vdvProjs[] = {vdvProj1, vdvProj2}
    dvProjs[] = {dvProj1, dvProj2}
    
    define_module 'Christie LX650 Rev1-00' proj1(vdvTPs, vdvProjs, dvProjs)
    
  • DHawthorneDHawthorne Junior Member Posts: 4,584
    Only if the module was meant to handle arrays in the first place. For something as simple as a projector, my personal opinion is that the overhead to make a module multi-device capable just isn't worth it; easier to just use multiple modules.
Sign In or Register to comment.