Home AMX User Forum AMXForums Archive Threads AMX Hardware

ICSNet Dead after sending code

Anyone else having this type of problem? I have an NI-3100 running as a main processor with 5 other processors connected M2M. I also have a card frame attached to the master with 3 IR cards currently in the frame. There is also a module shell about 50ft away from the card frame and processor that is connected to the card frame. Both the card frame and the shell have their own power supplies.

The problem I have recently started having is that after loading my code to the processor, about 80-90% of the time, all of the ICSNet stuff disappears. If I move the connection for the ICSNet wire from the main processor to the second processor in the rack, the ICSNet devices show up. Move it back, and the ICSNet devices aren't there. This leads me to think its a problem with the processor. I am able to fix the problem by pulling the power on the processor and letting it hard reboot. No code changes, nothing disabled, just a hard reboot and everything is fine (until the next code change).

I am running the latest firmware and I am leaning towards this possibly being involved in the problem as this symptom just started appearing in the last couple weeks (around the time I upgraded the firmware). Yesterday, I swapped out processors to make sure it wasn't a hardware problem with the processor, but the symptom still exists. (I also managed to completely screw myself by deleting most of the configuration information which is stored to files on the processor, but that's a whole other story ... and yes, there is a plan to automate backups of the processor, but it's not implemented yet.... about to start working on that in a few minutes tho :) ).

I was just wondering if anyone else has experienced similar problems or has any recommendations on what to consider next.

Thanks,
Jeff

Comments

  • ericmedleyericmedley Posts: 4,177
    I've only seen this once and it turned out to be a bad ICS card in the master. (Mine was and older NI-2000)
  • Spire_JeffSpire_Jeff Posts: 1,917
    Although it is possible, I am fairly sure that it is not hardware. I swapped the affected processor with a different processor and still have the same problem. The two processors were ordered at least a few months apart and the new processor has the different silk screening, so I doubt they are from the same batch. (but I have not ruled this out totally ;) )

    I am going to try some things when I get the chance at the office with different firmware versions. I am also going through my code in an attempt to reduce some of the startup burden to see if that might be causing problems.

    Jeff
  • AuserAuser Posts: 506
    Spire_Jeff wrote: »
    I am also going through my code in an attempt to reduce some of the startup burden to see if that might be causing problems.

    Good idea. I saw this behaviour in a job where a bug resulted in 14 display modules interpreting every response on a daisy chained serial line (generating a big loading on the processor).

    Fixing the bug fixed the problem.
Sign In or Register to comment.