Home› AMX User Forum› AMXForums Archive Threads› AMX Hardware

RS232 Port - Max Data

kennyannkennyann Posts: 113
in AMX Hardware
I know we had a number of issues with Netlinx unable to handle large amount of data on the RS232 ports. I found out through trail and error that port 2 on NI4000 was only port that was able to handle the data that was coming from a RUNCO projector - Status feedback (Runco VX1000 through 5000). I forgot the amount of data but it was enough to create problems in the other ports. My question is has AMX resolved the issue. Can the current NI series able to handle large amount of data on the RS232 or are we still going through the current batch before we see the new batch of NIs?

Comments

  • amxhobbyistamxhobbyist Posts: 90
    If this is a hardware issue, will we be able to return our equipment for repair / replacement? I just bought an NI-3000 and wouldn't like to run into this problem later down the road.
  • Spire_JeffSpire_Jeff Posts: 1,917
    How much data are you talking about? I can't imagine a projector producing that much data. I am in the process of writing the code to interface with the B&K CT600 line of distribution amps/receivers and they can generate a TON of data flying back depending on the request. The problem I ran into was not that the serial port was unable to handle the flow, but that the data was being chopped up as it came in. say the reply was 500 chars long. The processor was generating string events every say 100 chars so when I would check for a properly formated response, it was never found. The simple answer (thank you tech support for this tidbit) was to create a buffer and on string events check the buffer for a complete command.... if I have a chance in the next few days I can post the code I have for that if you like.

    Jeff
  • kennyannkennyann Posts: 113
    Jeff

    I have go back and figure how much data that projector was sending back. The Runco's have been changed so that it does not send back every bit of information. Therefore I cannot give you the amount of data. I just know that I was loosing data when I sent in a Status command except when I used port 2. My buffer so all the data. If I used another port I will only see part of the data stored in the buffer. So I am thinking the problem is with the port. I tried a number of NIs and all of them do the same. It seems like there is batch that has issues.
    I would like to see your code - I guess you are just waiting for the buffer to fill up with the data you wanted.

    amxhobbyist:

    The new batch of NI may have this problem corrected but I cannot confirm this yet.
  • RWozneyRWozney Posts: 19
    More Ni port problems.

    I have found this problem occurs on any port on a Ni3k when integrating to an ADA Suite 16 or 8X8. The data coming into the COM port of the Ni is @ 19200 baud and is one short burst of approximately 120 characters. This causes the Ni to lock up. This problem was confirmed after hours on the line with tech support. The only way we found to avoid the problem is to add an NXC-COM2 card to the system?an expensive work-around. Is there a fix in the works?

    Robb W.
  • alexanboalexanbo Posts: 282
    I've done 5-6 systems now with Suite 16's hooked up to both NXI's and NI's and not had any problems with them. Are you using the AMX module?
  • RWozneyRWozney Posts: 19
    Yes, I'm using the AMX module. Are you keeping the baud rate at 19200 on your systems?

    RW
  • alexanboalexanbo Posts: 282
    Yeah I have been keeping them at 19200. I haven't been implementing anything other then input selection, volume control though.

    The system I have on NI's only have 1 chasis, I do have a 2 chasis system on an NXI that seems fine. If I'm also using other ADA pieces like the Cinema Rhapsody or Trinity tuner I use the ISO-Cat II to talk to them on a separate port.

    Now that I think of it, I'm using an older version of the AMX module before they implemented the ability to talk to Cinema Rhapsodies and what not on the same port. It's version 1.6
  • RWozneyRWozney Posts: 19
    I'm using V2.0 although the problem happens even with no programming, module or other wise. If I even connect the ISOCAT and make an room change on the front of the Suit 16, without sending a command from the AMX, I get the lock up.
  • alexanboalexanbo Posts: 282
    Do you use a separate ISO-Cat in addition to the one built into the Suite 16?

    And not clear on what you mean when you say you make a room change from the front of the Suite 16? Do you mean you have your computer connected to the front port and the AMX connected to the back port? As far as I know you cannot connect to the back and front db-9 ports on the suite 16 at the same time, you can't even have the pyhsical connector in or the Suite 16 will not work.

    Of course it would still seem odd to lock up the AMX, and there's probably a problem there, I just want to make sure I'm not going to run into the same problem.
  • RWozneyRWozney Posts: 19
    No I never use front and rear 232s at the same time. For input change I meant via a keypad on the Suite 16 or front panel on an 8x8. Yes, the system I was connected to was on a bus through a second ISOCAT, maybe that's the problem. Me thinks I need to try this again. Were you using a "second" ISOCAT?

    RW
  • alexanboalexanbo Posts: 282
    No I only use the built in ISO-Cat in the Suite 16... but we don't use the keypads at all.... that's probably where the problem is coming from because the system is sending out more data for them perhaps.
  • ipssheldonipssheldon Posts: 106
    NI-2000 has RS-232 issues

    I found that the NI-2000 also has similar issues. I had one connected to a Polycom Vortex EF2280 that was set in Acknowledgement mode. In this mode, it reports every internal change that occurs (lots of data). Even with buffers of 1000 bytes or more, I found that the NI-2000 would fail with random problems. Usually, it would simply stop processing pushes on Axlink. The program would appear to keep running, just no button presses from online devices. I solved the problem by turning off ACKMOD in the EF2280. But I suspect that any device that sends big chunks of data can cause the same problems. It sounds from these posts that this is an inherent problem of the NI product line. I hope AMX comes up with a firmware fix, as this problem cost me a day and a half on-site before I realized what was occurring.
  • jjamesjjames Posts: 2,908
    I think I may be having the same problem here. Do all of the ports eventually lock up? The funny thing about mine, is that the NI is still acknowledging that it's RECIEVING data from devices - I haven't check to see if it's actually recognizing it in programing. All of my ports' output lock up - including relay and IR. Was all of your guys' ports locking?
  • Marc ScheibeinMarc Scheibein Posts: 882
    We also had several problems with RS232 data, locking up the NI internal ports (all ports), but AXLink and ICSNet still working.

    A colleague verified this with a "Ni lockup" test environment.

    We got a NI master beta firmware to fix that, and it seems to work now.

    But I don't know when the official firmware will be released.
  • Chip MoodyChip Moody Posts: 727
    If anyone can duplicate a failure like this by generating a "flood" of 232 data on >another< controller, (sending it to a controller that is "under test") could you please let me know? (Since I'm not likely to have the same piece of gear that others have been working with)

    I remember getting into a heated discussion with another user here a while back on a similar topic, and I wound up writing code that hammered an NI-2000 with a burst of around 4096 bytes without any problems - at least not on port 2. If this is still an issue - as it appears to be - I'd like to know what I'm doing that prevented me from having this problem.

    - Chip
  • jjamesjjames Posts: 2,908
    We had to revert back to the previous firmware (2.31) and it seems to be working fine now. The strings that were being sent from our Vidikron Model 20 projector every 60 seconds weren't large ("unkown event c"), but seemed to have been enough to have flipped it out. I'm not sure how I can recreate this issue, but going back to the older firmware seems to have fixed it.
  • jjamesjjames Posts: 2,908
    Nevermind - seems to have failed even with the older firmware.
Sign In or Register to comment.