Acxess and NetLinx

jeff.gardiner

Hi there,

This may come across as a silly question, but I missed the programming days of Axcess and have only been programming in NetLinx. Recently, a customer upgraded an old Panja Axcent box, and I was able to get the old code off of it which turns out to have been a good thing since the old document camera we're trying to control doesn't have a listed protocol anymore. The Panja box controls the camera fine, but the new NI-900 does not.

Anyway, long story short, here's the code I'm trying to use in NetLinx, the same code that someone else wrote (read: I apologize for the syntax) found on the Axcent controller:

DEFINE_CONSTANT
DELAY = 50  (* mSEC DELAY FOR SENDING STRINGS *)

DEFINE_CALL 'SEND AVP STRING' (STR[2])
{
  IF (LENGTH_STRING(STR) = 1)
    AVP_STRING = "2,27,19,DELAY,STR[1],27,19,DELAY,
                  3,27,19,DELAY,(STR[1] BXOR 3)"
  ELSE IF (LENGTH_STRING(STR) = 2)
    AVP_STRING = "2,27,19,DELAY,STR[1],27,19,DELAY,STR[2],27,19,DELAY,
                  3,27,19,DELAY,((STR[1] BXOR STR[2]) BXOR 3)"
  ELSE
    AVP_STRING = ""

  CANCEL_WAIT 'NO RESPONSE'
  SEND_STRING AVP,AVP_STRING
  WAIT 5 'NO RESPONSE'
  SEND_STRING AVP,AVP_STRING
}

DEFINE_START
SEND_COMMAND AVP, 'SET BAUD 9600, O, 8, 1, 485 DISABLE'
WAIT 5
SEND_COMMAND AVP,'CHARD-200'

DEFINE_PROGRAM
PUSH[TP,87]                         (* LIGHTING OFF *)
  CALL 'SEND AVP STRING' ("$57")

When I connect my computer to the output serial port on the Axcent controller to see what the commands it is sending are, I see this:

$02,$57,$03,$54,$02,$57,$03,$54

When I connect my computer to output serial port on the new NI-900 with the same code, I see this:

$02$1B$13$32$55$1B$13$32$03$1B$13$32$56
$02$1B$13$32$57$1B$13$32$03$1B$13$32$54
$02$1B$13$32$57$1B$13$32$03$1B$13$32$54

I tried just replicating the commands I found the Axcent controller to be sending out, but it doesn't work on the camera. I'm thinking the timing might be off or something.

Is someone with more experience able to explain the difference between the Axcess and NetLinx code that would result in such different strings?

Any help anyone can provide would be hugely appreciated.

Thanks,
Jeff.

ericmedley

A couple things hat you may want to confirm in the serial port setup on the NI. I notice the setup command in the access processor calls for 'odd' parity. The default on the NI is 'none' or an 'N'. ,ake sure your serial port is setup correctly.

Apart from that you may need to post you Netlinx code for us to see what's going on.
E

Auser

Looks to me like the code on the Axcent box was sending escape sequences to delay transmission between characters by 50ms.

DEFINE_DEVICE
dvAVP = 5001:1:0

define_function AVP_Send(char cAVPCommand[2])
{
  stack_var char cAVPString[32]
  if(length_Array(cAVPCommand) = 1)
    cAVPString= "$02,cAVPCommand[1],$03,(cAVPCommand[1] BXOR 3)"
  else
  if (length_array(cAVPCommand) = 2)
    cAVPString= "$02,cAVPCommand[1],cAVPCommand[2],$03,
        ((cAVPCommand[1] BXOR cAVPCommand[2]) BXOR 3)"
  else
    cAVPString= ""

  send_string dvAVP, "cAVPString"
}

DEFINE_EVENT
data_event[dvAVP]
{
  online:
  {
    send_command dvAVP, 'CHARDM-50'
  }
}

The above doesn't implement the resend on no response behaviour from the original code.

jeff.gardiner

Thanks for the responses, guys.

I did notice the odd parity. I guess I don't really understand how send_string works in the Axcent box because I would have thought it would act pretty much like it does when directly transferred into NetLinx code (the second set of strings in my first post). But it looks like adding a variable called "delay" and defining it as 50 slows the send rate instead of adding it as a character in the string like NetLinx does.

Auser, the code you have there looks just like what I tried in my NI-900 to no avail, but I did not try the CHARDM. I'll give that a shot when I'm on site later today.

Thanks again,
Jeff.

Hedberg

The Axcent code appears to work fine on my NI700, but there are two things that need to be accounted for:

1. Send the command for port parameters in a data_event online handler and not in define_start. In all probability, define_start runs before the serial port comes on line. If you enable device notifications and do a get baud command you can verify the port settings.

2. As Auser noted, the axcent code is embedding escape sequences in the string. These are explained in the documentation. Upon my first test, they didn't work. Then in AMX-PI there is this:

"10/16/09 v1.20.7 -SW2105_NI_700_Device_v1_20_7.kit
[...]

- Added command to enable/disable check for escape sequences in strings

being transmitted. Commands are ESCSEQOFF and ESCSEQON. The

default behavior is now off (used to be on)."

Sending the command 'ESCSEQON' made the code work properly. Just looked at what appears to be the most recent documentation and this send_command is not noted or explained.

I don't know why you are getting three strings sent out rather than two -- that's not what I observe.

jeff.gardiner

Wow, awesome find Hedberg! That's exactly what I wasn't understanding and didn't know to look for. So in Axcent coding, you can imbed escape sequences directly in the string which would have been removed from NetLinx coding...

I added that 'ESCSEQON' command and moved everything to a data_event, and it is now properly controlling the document camera.

I really appreciate the assistance! I owe you one.

Have a great one!
Jeff.

Hedberg

jeff.gardiner wrote: »

Wow, awesome find Hedberg! That's exactly what I wasn't understanding and didn't know to look for. So in Axcent coding, you can imbed escape sequences directly in the string which would have been removed from NetLinx coding...

I added that 'ESCSEQON' command and moved everything to a data_event, and it is now properly controlling the document camera.

I really appreciate the assistance! I owe you one.

Have a great one!
Jeff.

The escape sequence feature exists in both Axcent and Netlinx serial ports. The difference is that in Axcent boxes. there appears to be no facility to disable the interpretation of the sequence and the subsequent stripping out of the sequence. The result is that it is impossible, as far as I can tell, to send the bytes that comprise an escape sequence out through the serial port on an Axcent box. In Netlinx boxes running current firmware, the default behavior is to not recognize the escape sequences and to push the integers out the serial port. Turning on the escape sequence interpretation results in the same behavior as with an Axcent box.

Here's a link to what appears to be the most recent documentation on Netlinx controllers:
http://www.amx.com/assets/manuals/NetLinxControllers.WebConsole-ProgrammingGuide.FMv3.pdf
In the section on serial ports the escape sequence behavior is described. In the section on "send_command" to the serial ports, however, the ability to turn this feature on and off is not mentioned and it does not appear that the fact that it is off by default is noted. They should fix that.

My suspicion is that the escape sequence feature is something almost never used and that the default behavior was changed in response to people not being able to send certain integer sequences out through the ports. There was a discussion in the forums about this back in 2009 (found by searching the forums) which leads me to think that almost nobody needs or uses this feature.

Added -- it would seem to me that Auser's suggestion to use: send_command dvAVP, 'CHARDM-50' should work and would probably be easier and cleaner than using the escape sequence delays. You might consider testing his code suggestion to see if it works with the cameras you are programming for.

Jimweir192

ESC sequences are often needed with PLCs and if I recall with Alcorn mcbride show controllers anything that uses a 9 bit protocol