Home› AMX User Forum› AMX General Discussion

Possible corrupted file?

adcantrelladcantrell Posts: 24
in AMX General Discussion
to keep it short, my IR file thats mapped to port 13 of my ni-3100 is now firing on every button push from every panel. but somehow but does not control the actual device its meant for anymore.

it worked fine for months. what gives?

Comments

  • a_riot42a_riot42 Posts: 1,624
    adcantrell wrote: »
    to keep it short, my IR file thats mapped to port 13 of my ni-3100 is now firing on every button push from every panel. but somehow but does not control the actual device its meant for anymore.

    it worked fine for months. what gives?

    I would do a clean disk and load everything again and see what happens. That's a weird one.
    Paul
  • adcantrelladcantrell Posts: 24
    just tried that. didnt work.
  • AuserAuser Posts: 506
    Not a cable box that's being controlled is it? If so it may have got a firmware update off the wire that means the IR file you're using is no longer working.

    If not, what device are you controlling?
  • viningvining Posts: 4,368
    Auser wrote: »
    Not a cable box that's being controlled is it? If so it may have got a firmware update off the wire that means the IR file you're using is no longer working.

    If not, what device are you controlling?
    Although not completely impossible I would think even if a cable box did a firmware update it would be more in the lines of what DirecTV did and just modify pulse times or re-action times. To completely change IR files and make the IR file inoperative would also render all the remote controls that come with the boxes inoperative and that wouldn't make much sense but in this new world order who knows.

    For the IR port to fire on every TP/port/button push I would say the fault would lay with the master or TP or code unless the code hasn't changed. I would start with the TP and first make sure different ports are firing and not just the same port on every page that should be a different port are indeed different ports.
  • DHawthorneDHawthorne Posts: 4,584
    Perhaps you thought of these on your own, but since they haven't been brought up so far:

    When something like this happens to me, I always suspect the emitter first. More often than not, it's one of those hair-thin leads that has been crimped or shaved and fails over time. I have also seen seasonal issues, where the angle of the sun coming in a nearby window might drown out the IR some times of the year, but not others.
  • adcantrelladcantrell Posts: 24
    i dont know guys. after loading a new workspace with limited functions it cleared up and i had the probalem of times when re adding more than one IR file or especially the Cable box IR file and so i would just clean disk and take one step back. I ended up adding the code but taking out the last thing i had added before i saw the problem which was some code to get an RTI remote to control channels through the AXR RF.

    when i did this did this problem went away and ALL the sources worked great with NO doubling of the IR outputs.

    so i THOUGHT that this must have been the problem. HOWEVER when I loaded the RTI code back in to reinstate the problem, it never returned all sources work fine.

    so at this point im back where i started with the original EVERYTHING but without the problem. wow WTH?!
  • viningvining Posts: 4,368
    adcantrell wrote: »
    i dont know guys. after loading a new workspace with limited functions it cleared up and i had the probalem of times when re adding more than one IR file or especially the Cable box IR file and so i would just clean disk and take one step back. I ended up adding the code but taking out the last thing i had added before i saw the problem which was some code to get an RTI remote to control channels through the AXR RF.

    when i did this did this problem went away and ALL the sources worked great with NO doubling of the IR outputs.

    so i THOUGHT that this must have been the problem. HOWEVER when I loaded the RTI code back in to reinstate the problem, it never returned all sources work fine.

    so at this point im back where i started with the original EVERYTHING but without the problem. wow WTH?!

    Well we don't like to talk about this much but some times AMX equipment ships with out first removing the gremlins used inside the equipment during the manufacturing process. When out in the field these gremlins can lay dormant for months or even years but when they wake they make the systems do all sorts of crazy things and then they just stop, return to sleep and the system runs normal. Often these gremlins never wake again. It is bizarre and I often forget about them when weird crap starts to happen but eventually I'll remember and realize it was probably just one of them that briefly wroke up, had its little bit of fun at my expense and then went back to sleep with an evil little smile on its face.
  • John NagyJohn Nagy Posts: 1,740
    The real fun starts when the AMX gremlins start a fight with the network voodoo dolls. Then it's generally up to the DirecTV vampires to sort it out.
  • adcantrelladcantrell Posts: 24
    well found that if I take out the code that i had written last to get the RTI remote to talk to the NI via an axr-RF the problem goes away. now im just wondering if its the code itself? or possibly some limit i have exceeded for the NI. memory or something? anybody have any ideas?
  • viningvining Posts: 4,368
    Unless this is a real large job I doubt you've reached any limits although running out of memory can cause weird behavior from what I've read (never experienced first hand, I don't think). Chances are it's something in the code that causing the problem.

    I know recently I've included an include file into my system made some minor modification and then notice all kinds of weird crap happening and of course alot of stuff that should happen wasn't. I looked through the code and sure enough I noticed a compiler directive "#IF_DEFINED" or maybe not_defined was placed at the begining of my define section and there wasn't a follow up "#END_IF". Well if you know how they work you'd know that when the code was being compiled at that point where this code was included and the compiler ran into that directive it stopped compiling any code from that point after. Maybe you're doing something equally as stupid.

    Does the majority of the system still work or does it stop when you try to do system events that use this section of code?
  • DHawthorneDHawthorne Posts: 4,584
    adcantrell wrote: »
    well found that if I take out the code that i had written last to get the RTI remote to talk to the NI via an axr-RF the problem goes away. now im just wondering if its the code itself? or possibly some limit i have exceeded for the NI. memory or something? anybody have any ideas?

    I doubt it. The controller portion with the IR ports, etc., has it's own memory that is separate from the master which holds the code. You load IR files to the controller, to the ports themselves. There is no relation to the master's memory
  • adcantrelladcantrell Posts: 24
    So I found out the problem was the fact that the RTI Amx rf codes has a channel trigger of "000", well I used it for the "0" on one of my cable boxes. What was happening is that I guess when netlinx sees any button_event with a channel value of 0 in the code, it means any button push from any panel will execute that command. I changed it to trigger 255 and all is well.
  • DHawthorneDHawthorne Posts: 4,584
    adcantrell wrote: »
    So I found out the problem was the fact that the RTI Amx rf codes has a channel trigger of "000", well I used it for the "0" on one of my cable boxes. What was happening is that I guess when netlinx sees any button_event with a channel value of 0 in the code, it means any button push from any panel will execute that command. I changed it to trigger 255 and all is well.

    That explains it. Using 0 for a channel number is the wildcard for "any channel."
Sign In or Register to comment.