IR Issues

staticattic

I am currently working a job that sports 21 NI-3100 masters and 21 NXT-CV10 touch panels. The IR ports are fighting me the entire way. Sometimes they fire, other times they don't. Let me rephrase that. When the systems power on via the TP push, The master will fire off IR ports 1 and 2 to power LCD screens. Sometimes ports 1 and 2 will fire, other times not, and no, there is nothing in my code. No IF's, WHEN's, BUT's, etc, just a straight button push. When the power button is pushed, PULSE IR's 1 & 2. When they quit working all together, I moved the devices on 1 & 2 to other IR ports. Again, similar results. If I reboot the master a few times, they start working again. The results are sporadic and I can't replicate the problem. So far, I have had this same issue on the first 4 masters I have programmed. I just downloaded the latest and greatest firmware file and will be able to install it tomorrow. When the masters POST, IR #7 never lights up, which is one issue the new firmware file addresses. Do you think all of my problems are stemming from needing a firmware upgrade? All of these masters are brand new. One thing that makes me nervous, all of the AMX equipment was shipped directly to the site. When the masters arrived, the customer realized they ordered the NI-3100's without ICSNet installed. So they went out and bought 21 ICSNet daughter boards and installed them all, before I got onsite. I am worried they touched something they should not have touched or maybe a static charge zapped something. I am crossing my fingers that the firmware file will fix everything. What do you think? Do I stand a chance or am I fighting a losing battle?

vining

statticattic wrote:

So they went out and bought 21 ICSNet daughter boards and installed them all, before I got onsite.

Those little boards are a pain in the but to install and get the plastic nut to catch while holding it in the proper position. With out a grounded wrist band or at least occasionally grounding themselves to discharge the potential static build up could have very bad consequenses as they fumble about, trying to hold this thing, sticking their hands on whatever they come across.

What kind of customer is this? And 21 NI-3100s, what the heck are you building?

staticattic

That's your tax dollars at work my friend. This is an install I am doing at Fort Jackson. I wasn't part of the engineering design, I was just told to put it together and make it work. Each room has its own 3100, VBrick, Converge 1212, NXT-CV10, Extron 88 MVX, and HDD recorders. On top of that, the big rooms have 4 projectors, 3 cameras, 16 microphones, 1 Converge 1212A, 2 Converge 1212's, and 2 VBricks. The Converge's and Christie projectors are all IP controlled. And the cherry on top of it all, an RMS Server is going to be keeping its eye on every button push. If it wasn't for those dang IR's this job has been a dream.

vining

Well then since it military and the boards were probably installed by GS type civilians or Army ET's I'm sure they took the appropriate static precautions. I learned that in the Navy and that type of training is pretty much the same regardless of branch.

So why isn't the IR working? Maybe the firmware will do the trick and tomorrow you'll be grinning from ear to ear. Good luck manana.

PhreaK

When you say they aren't firing are you referring to the IR light not lighting up, or the command not making it to the other end? Sorry if this is a stupid question, but it isn't something small like pulse timings or badly installed emitters?

Jimweir192

Are the IR files captured or cut/pasted Hex or downloads.

Do the front LED's for IR 1&2 fire or is it just the emitters that don't fire?

Sounds like the files might be corrupted slightly (or a bad CF but thats unlikely to be replicated on all masters). Are both files the same - same LCD screen?

If you load an alternative known IR file does this fire?

Can you rebuild the files, even cutting and pasting into a new IR file might flag up a problem.

staticattic

The lights don't light up and nothing happens on the other end. One set of IR files was downloaded from AMX. The other set was captured via an IRIS. Sometimes it is the IRIS captured files that act up, other times it's the downloaded ones. What makes it frustrating is that I can't do anything to replicate the issue. It happens so sporadically.

For all of the IR devices I have ever controlled, even with no emitter, the LED light would flash. The only time I have not seen the light flash is when I accidentally pulse an empty channel. Like if I pulse channel 50 and 50 has no function, the light will not blink. Other than the LED's, the only other way I know to test an IR emitter is to use my camera phone to see if the emitter actully pulses. I just don't understand why the issues I am having are happening like they are. The common factors are the IR files, my code, and the devices. In my code, I am not doing any fancy tricks with the IR files. The LCD's only power on or off, that's it. The DVD's also don't use any fancy tricks. I'm not against pointing the finger at my code, but I don't think that is the problem. I would think if my code were the problem, I would have better luck replicating the problem or at least figuring out a pattern. If the IR file that was captured via the IRIS were screwy, would that effect my other IR files and cause weird results across the board?

vining

You could try actuating directly from IR edit, bypassing the code completely to see if it's the port or the file or niether.

Joe Hebert

If you don?t want to wake the IREdit monster you can use Control A Device in NS to send IR directly out.

karageur

To my mind comes maybe silly advices, but who knows:
1) get the latest device & master firmwares as you already mentioned
2) check if CARRIER IR on IR port is ON with GET MODE command
3) use only Control Device to be sured if there is nothing wrong with the code ...
4) check another 100% working self captured IR file with uploading on a same port

HARMAN_icraigie

Try using the Stacked Pulse command instead of a system PULSE - I have found it to be a lot more robust, in fact I can't remember the last time I actually pulsed an IR command. You might need to play around with the CTON and CTOF settings to get the timing right.

SEND_COMMAND dvIR, "'SP',<ir_index>"

Auser

icraigie wrote: »

Try using the Stacked Pulse command instead of a system PULSE - I have found it to be a lot more robust, in fact I can't remember the last time I actually pulsed an IR command. You might need to play around with the CTON and CTOF settings to get the timing right.

SEND_COMMAND dvIR, "'SP',<ir_index>"

+1 - good advice which may well solve the problem. Good practice to put the CTON and CTOF send_commands in the online event for the IR port so that if a master gets swapped out the pulse timings will be retained too.

PhreaK

Ditto on that. "'IROFF'" is also your friend when using stacked pulses. It will clear out any stacked commands in the buffer.

DHawthorne

You can bypass the entire IRON/IROFF issue by using SP instead of PULSE for your IR. It will also queue the IR and might eliminate other conflicts.

PhreaK

DHawthorne wrote: »

You can bypass the entire IRON/IROFF issue by using SP instead of PULSE for your IR. It will also queue the IR and might eliminate other conflicts.

I was under the impression IROFF was there for use with stacked pulses ('SP') as it will clear out any stacked commands waiting to go out. Very useful for when you are say issuing a power state command or drive select etc.

Anyway to get back to topic, if the lights aren't lighting up then it sounds as though it may be an issue with either the IR files or the code calling them. To rule out anything wierd that may be happening in the code try dumping this onto one of the affected masters.

PROGRAM_NAME='IR Test'

DEFINE_DEVICE

dvIRPort = 5001:9:0			// the IR port to test


DEFINE_VARIABLE

CONSTANT INTEGER TL_IR_FLASH

PERSISTENT INTEGER nIRChannelWithCommand = 1	// a slot with a command in it in the IR file

PERSISTENT LONG lFlashSpacing[1] = {1000}	// the delay between IR pulses (in milliseconds)


DEFINE_EVENT

DATA_EVENT[dvIRPort] {
    ONLINE: {
	SEND_COMMAND dvIRPort, "'SET MODE IR'"
	SEND_COMMAND dvIRPort, "'CARON'"
	SEND_COMMAND dvIRPort, "'CTON', lFlashSpacing[1]/200"
	SEND_COMMAND dvIRPort, "'CTOF', lFlashSpacing[1]/200"
	
	TIMELINE_CREATE(TL_IR_FLASH, 
			lFlashSpacing, 
			LENGTH_ARRAY(lFlashSpacing), 
			TIMELINE_ABSOLUTE,
			TIMELINE_REPEAT)
    }
}

TIMELINE_EVENT[TL_IR_FLASH] {
    SEND_COMMAND dvIRPort, "'SP',nIRChannelWithCommand"
}

Make sure that you either change the device and IR channel number to suite, or have an IR file on the first IR port with something in channel 1. You should see the LED for the port flash once per second. If not then it's going to be something taking place on either the device controller or a dodgy IR file.

Joe Hebert

PhreaK wrote: »

I was under the impression IROFF was there for use with stacked pulses ('SP') as it will clear out any stacked commands waiting to go out. Very useful for when you are say issuing a power state command or drive select etc.

I?ve got nothing against it but I personally have never found a reason to use IROFF. I use SP and CP. CP will clear the queue and then stack a new pulse.

PhreaK

Joe Hebert wrote: »

CP will clear the queue and then stack a new pulse.

What d'ya know. Cool. Learn something new everyday.

staticattic

<feeling sorry for myself>
I love my job and working with the military. I hate that I can't connect to the freakin' Internet when I am on a job site. or if I find some one willing to do some surfing using their profile, te Internet is so locked down, it is pretty much useless. sometimes I just want to grab someone by the throat.
</feeling sorry for myself>

thank you guys so much for all of the help. I think I have tried everything so far except for CP. I am going to call AMX and let them weigh in on the issue. Here is something that may sound silly, but thinking back over my programming career, I have never had to control more than one device on a system via IR. up until this particular job, my devices have always been serially contolled and sometimes IP. this particular job, each room has 4 IR devices, 2 LCD screens and 2 DVD recrders. I am using IR ports 3,4,5,and 6. when they start their day, the master is supposed to fire off 3 and 4 for the monitors, wait one second and then fire 5 & 6 for the dvd's. sometimes it works right, other times just 3 & 4 will fire, sometimes 5 & 6, sometimes 3 & 5, sometimes 4 & 5, etc. Is it too much to fire 2 IR's at the same time? I just created a timeline to fire them one at a time with a one second wait in between. I am waiting for the master to come back online so I can try that. other than that, I am running out of ideas. I just find it odd that 4 masters are having the same issues.