Home AMX User Forum AMXForums Archive Threads AMX Hardware
Options

NI 4100 Queues problem!

KimKim Posts: 52
There was a problem! After two days of work of the program, controller NI 4100 does not serve ComPorts and bulb OUTPUT blinks. In telnet the command " show buffers " shows gradually growing AxLinkTx. Any device on AxLink is not attached. In what there can be a problem?

Thanks all!

Comments

  • Options
    Kim wrote:
    There was a problem! After two days of work of the program, controller NI 4100 does not serve ComPorts and bulb OUTPUT blinks. In telnet the command " show buffers " shows gradually growing AxLinkTx. Any device on AxLink is not attached. In what there can be a problem?

    Thanks all!
    This is a problem we also have in two installations.... unfortunately.
    We are cooperating directly with the Firmware development team of AMX to find a solution, there is a new port firmware in development to fix that. We got a beta and loaded it in an affected system this weekend, and it seems the fix works. Let's see.

    I'll give a note to the development team about your case, so they could get in contact with you.

    Kind regards,
  • Options
    DHawthorneDHawthorne Posts: 4,584
    As always, I highly recommend turning device notifications on for all devices and watching to be sure something is not overloading the queue. I wouldn't get too hung up on the Axlink part of that message - the Axlink is used internally, and may be active even with nothing connected to the external buss; at least that's how I always understood it. Too many messages going to or from any device before the master can process them can and will cause this. I don't rule out a firmware flaw aggravating the problem, but every time I have had it, I have been able to optimize my code to avoid the messaging and make the lockups go away.
  • Options
    Kim wrote:
    There was a problem! After two days of work of the program, controller NI 4100 does not serve ComPorts and bulb OUTPUT blinks. In telnet the command " show buffers " shows gradually growing AxLinkTx. Any device on AxLink is not attached. In what there can be a problem?

    Thanks all!

    Are you using hardware handshaking on any of the serial ports? A problem has been recently found that can cause problems on devices with hardware handshaking enabled. There is a hot fix for this available via tech support. The hot fix is 1.13.6, device-side firmware. It should be released for general distribution via our web page soon.
  • Options
    KimKim Posts: 52
    This is a problem we also have in two installations.... unfortunately.
    We are cooperating directly with the Firmware development team of AMX to find a solution, there is a new port firmware in development to fix that. We got a beta and loaded it in an affected system this weekend, and it seems the fix works. Let's see.

    I'll give a note to the development team about your case, so they could get in contact with you.

    Kind regards,

    Marc, you used ComPorts in your code? If yes that what report?
    On three ComPorts I use RS485 modbus, during the moment when there is a given problem of bulb RX and TX remain to burn, but communication with devices is not present, I have not guessed to look Notifications, at recurrence of a problem I shall necessarily check up.

    Best regards!
  • Options
    KimKim Posts: 52
    DHawthorne wrote:
    As always, I highly recommend turning device notifications on for all devices and watching to be sure something is not overloading the queue. I wouldn't get too hung up on the Axlink part of that message - the Axlink is used internally, and may be active even with nothing connected to the external buss; at least that's how I always understood it. Too many messages going to or from any device before the master can process them can and will cause this. I don't rule out a firmware flaw aggravating the problem, but every time I have had it, I have been able to optimize my code to avoid the messaging and make the lockups go away.

    The matter is that I used my code before on other controllers NI3000, with Duet firmware and not Duet and such problem was not, therefore at once has not guessed to look Notifications, but to check up certainly does not stir. Thanks for advice!
  • Options
    KimKim Posts: 52
    rgelling wrote:
    Are you using hardware handshaking on any of the serial ports? A problem has been recently found that can cause problems on devices with hardware handshaking enabled. There is a hot fix for this available via tech support. The hot fix is 1.13.6, device-side firmware. It should be released for general distribution via our web page soon.

    I use three ports on all the same adjustments RS 485 Enable, "HSON" I do not use. The second controller is registered in my system in URL, but physically it is not attached yet, it can influence?
  • Options
    ericmedleyericmedley Posts: 4,177
    Kim wrote:
    I use three ports on all the same adjustments RS 485 Enable, "HSON" I do not use. The second controller is registered in my system in URL, but physically it is not attached yet, it can influence?

    If I'm reading your problem wrong, I apologize.

    However, there is a common error that many (myself included ) have made when setting up serial ports. That is: sending the port setup command too soon after reboot.

    it is a good practice to do the setup commands in a DATA_EVENT and not in the DEFINE_STARTUP section. The reason for this is that the NI-X100s devices do not show up at master startup.

    So, for example if you're doing something like this at Startup:

    DEFINE_STARTUP

    SEND_COMMAND dv_My_Serial_Port_1, 'SET BAUD 9600,8,N,1'




    ... move the command to the DEFINE_EVENT section and do this


    DEFINE_EVENT

    DATA_EVENT[dv_My_Serial_Port_1]
    {
    ONLINE:
    {
    SEND_COMMAND dv_My_Serial_Port_1, 'SET BAUD 9600,8,N,1'
    }
    }

    This way the master will wait until the serial port is officially online and will actually accept your command.

    My guess is that your serial port is working. It's just not getting set to the correct baud rate because the program tried to send the command to a device that is not yet online.

    Just a guess. Hope it helps.
    ejm
  • Options
    KimKim Posts: 52
    URL List

    Thanks all who has responded to my problem! I decision Seems has found!

    The second controller is registered in my system in URL, but physically it is not attached.
    I have removed record from the list and the second week the system works stably!
  • Options
    KimKim Posts: 52
    The problem has remained?!

    All greetings!
    The problem described above was solved updating firmware up to version 1.13.6.
    Today has faced such problem on Ni4100 with firmware 1.13.7 and master 3.30.371. The controller worked two weeks then has ceased to serve ComPorts and the bulb output burns and input is not present and grows AxLinkTx queue.
    If reboot from telnet master "reboot 0". Comports up, but there is a strong loss of packages. Deenergizing of a power helps only...


    somebody faces such problem?
  • Options
    This problem has some years history...

    Hello All.
    Kim use my non-duet modules and AMX connected to devices via RS485 protocol.
    Problem looks like all leds that service com-ports light on and stop flashing. Also known that AMX master can send data to com-ports and connected devices receive these data and send answers back to AMX but... AMX don't received these answers or com-port device don't send they to master.

    Another side of this problem is that it happened with very 'light' program. For example program consists from one, two or three of my modules only. In this case this problem happens every two days. After growing up of source code - program become more hard to controller - this problem may happened only on? time per a week. When program become very hard - about 0.5MB or bigger of compiled program - this problem happened one time per 1-2 months.

    First time I sent a letter to AMX about three years ago. Their answer was that they can't emulate this situation and their equipment works well. Since this happened three years and there were released a big amount of firmwares for master and devices but problem hasn't resolved yet.

    Dear Marc, can you resend my answer directly to firmware developers. Because this problem happened with every installation of us or our dealers during very long time. Also known that problem is in NI device side because if we reboot master by reboot (0:1:1) controller reboots but device part works terrible - there was big delays with com-ports data in both sides (to and from devices). So only one way to resolve this problem is rebooting of controller via power off and on.
  • Options
    DHawthorneDHawthorne Posts: 4,584
    I wonder if this is related to the unicode bug mentioned elsewhere on these forums.
  • Options
    KimKim Posts: 52
    DHawthorne wrote: »
    I wonder if this is related to the unicode bug mentioned elsewhere on these forums.

    Hello, Dave!
    I cannot find similar problems at a forum connected with unicode. If it is possible, describe how it is connected with unicode? We think that this problem arises in device firmware, because after reboot master device it does not disappear.
  • Options
    DHawthorneDHawthorne Posts: 4,584
  • Options
    KimKim Posts: 52
    DHawthorne wrote: »

    Thanks Dave but i think that problem is not connected with this theme. Because we dont have in diagnostics similar messages.
    However it is told about amx need in good beta testers...

    Best regards
  • Options
    KimKim Posts: 52
    Anybody help!

    Anybody, who normally speak with amx technical support, help me please! I wrote two letters in amx technical support but they not answer on my letters.
    Please resend our problems to technical support.

    Best regards,
    Mikhail
Sign In or Register to comment.