Home AMX User Forum AMXForums Archive Threads AMX Hardware

Program not running on NIXXXX Help needed - Urgent

This is a bit desperate...I'm supporting an installer across the country on a Saturday morning. A program that was tested just fine in a NI4100 here, was sent to the jobsite to a different NI4100. He can download it, but the program doesn't actually do anything. He can telnet in to confirm the files have been correctly received. He has the touchpanel correctly connected (input light flashes with every button push), but nothing on the outputs. It's like the program is not actually runing. The ports address in my program (5001:x:0) match what he sees in the online tree. He was able to borrow an NI-2100 and we're seeing the same thing happening with this one too. The first dipswitch is set in the correct position. Must be doing something wrong but I'm a bit stumped

Thanks in advance

OP

Comments

  • jjamesjjames Posts: 2,908
    Do you have anything in the code or in a module that checks the serial number or unique ID that could disable the program? I suggest putting in a very simple program that flips a relay just to test (I'd imagine that the relay flip program will work.) If it does, you might want to comment as much as needed to know that the program is actually running. After that, start uncommenting sections a little at a time. I'd start with commenting out DATA_EVENTs for actual devices first, but not touch panels. If you've got some of your page flips in code, you can at least try to verify that the UI portion is running properly. If it is, put back SOME of the DATA_EVENTs for IR & serial devices one at a time.

    Another thing, are you using Duet modules? If so, verify that the firmware of the master is up to date as I seem to remember there being a change in the compiler that rendered Duet modules inoperable on older firmware (and that firmware wasn't even *that* old.) It's a problem I run into every now and then when going back to an older job.

    So, in general - remove a lot of code (put in a simple program if needed.) Verify firmware. And if all else fails, looks like you might have to wait until Monday to talk to TS, though I suspect it's something in code disabling his master and not yours, which is why I ask if there is serial number / unique ID checks.
  • glr-ftiglr-fti Posts: 286
    Might also be as simple as dip switch one being in the up position which disable the program from running.
  • the8thstthe8thst Posts: 470
    Have you double checked the system number settings for each master and the device ID of the touch panel?
  • HedbergHedberg Posts: 671
    the8thst wrote: »
    Have you double checked the system number settings for each master and the device ID of the touch panel?

    ++ on touch panel configuration--device id etc. Make sure the tp that appears in the tree matches what's in the code.
  • banobano Posts: 173
    If the devices you're trying to control are ir, make sure you have the correct ir files mapped and downloaded.

    This is a bit desperate...I'm supporting an installer across the country on a Saturday morning. A program that was tested just fine in a NI4100 here, was sent to the jobsite to a different NI4100. He can download it, but the program doesn't actually do anything. He can telnet in to confirm the files have been correctly received. He has the touchpanel correctly connected (input light flashes with every button push), but nothing on the outputs. It's like the program is not actually runing. The ports address in my program (5001:x:0) match what he sees in the online tree. He was able to borrow an NI-2100 and we're seeing the same thing happening with this one too. The first dipswitch is set in the correct position. Must be doing something wrong but I'm a bit stumped

    Thanks in advance

    OP
Sign In or Register to comment.