2 identical Sharp projectors, 1 system
dmenke
Posts: 25
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
Do I need to load 2 modules, or can I define/address the two projectors to respond a single module?
Thanks,
Doug Menke
0
Comments
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.
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.
Will doing this bog down the master?
Thanks for the help so far!
Doug
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
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
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.
Paul
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.
This might work better for you.