Firmware issue possible in 1.6.79 on NX series

SCamphaug

Just wondering if anyone else has seen this one, I have a few times on a few controllers and it's causing modules to fail. In Notifications view it appears serial data is not being gathered to the delimiter before the event happens. Pic attached. Reboot always solves it.

SCamphaug

Marc Scheibein

Never have seen that.... how is the system load, in console type CPU USAGE ? Any messages in diagnostics, so maybe runtime issues?

richardherman

I certainly have seen that, but also on earlier firmware. I especially noticed it on RS485 connections, but that could just be a coincidence. A string that was send in one go would end up being received as multiple chunks, sometimes 10 or 12. I concluded that it had something to do with the sender timing not being perfect or the NX being a bit to picky about timing.
It happened when I replaced older NI's with NX's. Where the same serial device had worked for years without problems it started with this behavior after the replacement. These used device drivers I made myself, so I worked around it.

Marc Scheibein

if receiving of the strings is programmed well, it should not be a problem, because the data should be collected into a buffer. Parsing would be triggered by the incoming data into the DATA_EVENT..STRING, and parsing only executed when e.g. a $0D was received ( depending on the protocol structure).

richardherman

Exactly. The annoying one was a device that gave replies probably meant for synchronous communications: it did not send a delimiter and the length of the reply depended on the message that was send. So when parsing you had to remember the last command that was send and parse based on that. I now have to include received string length with that, where that was never necessary with an NI that received the whole reply at once, not multiple chunks.
Most things are solvable, but there IS a difference between NI and NX serial ports (like the RS485 transceiver being rather crappy on the NX series). NI serial ports were much more robust in my opinion.

Duncan Ellis

@SCamphaug said:

I normally concatenate everything anyway and split it using a loop and line end marker in the data event. You can never assume that the incoming data will be complete unless its from an AMX device. I've had this happen in all versions of NI and NX so its nothing new as far as I'm concerned.

make a buffer inside your data event

sBuffer = "Buffer,DATA.TEXT"

the use a loop to find all the line end markers (as there may be more than one complete response in the string) -

Marc Scheibein

The protocol has a clear delimiter sequence "$0D,':'", which makes it pretty easy to parse:
(sorry for the bad formatting :-) )

data_event[dvMySerialDevice]
{
     string:
     {
          stack_var char sTemp[50];
          sBuffer = "sBuffer,data.text" // but personally I prefer the good old CREATE_BUFFER() in define_start :-)
          while(find_string(sBuffer,"$0D,':'",1))
          {
               sTemp = remove_string(sBuffer,"$0D,':'",1)
               select
               {
                    active(find_string(sTemp,"VOL=",1)):
                    {
                         //something here
                    }
                    active(find_string(sTemp,"PWR=",1)):
                    {
                         //something here
                    }
                    active(1):
                    {
                         // found data that had an delimiter, but has not matched to any of the keywords above
                    }
               }
          }
     }
}

SCamphaug

Ye that's exactly how I've gotten around that but I found it pretty interesting.