Create Buffer

vining

I'm currently playing w/ an AMX written Duet module for an Antex XM tuner and if I create my own buffer for this device I don't get any strings from the device when the Duet comm module is running. If I comment out the Duet Comm module and recompile I get all strings from the device. With standard Netlinx modules I can create as many buffers as I want for a device if I choose so want does the Duet comm module do that prevents the buffer I create from receiving the same strings the Duet module receives.

Joe Hebert

vining wrote:

I'm currently playing w/ an AMX written Duet module for an Antex XM tuner and if I create my own buffer for this device I don't get any strings from the device when the Duet comm module is running.

Take a look at the PASSBACK command in the Duet Module Interface Specification for the Antex. I believe you will get your data if you issue a:
SEND_COMMAND vdvAntex, 'PASSBACK-1'

vining

Joe Hebert wrote:
Take a look at the PASSBACK command in the Duet Module Interface Specification for the Antex. I believe you will get your data if you issue a:
SEND_COMMAND vdvAntex, 'PASSBACK-1'

The doc does indeed specifies the pass back just as you indicated but I got in the diagnostics when I sent the command thru NS2 (control device).

Line     66 :: com.amx.duet.impl.antex.xm100.dr1_0_0.AntexXM100: Unknown Command  "'PASSBACK-1'", received. - 16:33:56

It's not a big deal because I'm probably going to make a new module from scratch but I'm curious why the following doesn't work from the device itself, not the virtual.

condensed version:

DEFINE_DEVICE
dvXM_1   	= 5001:4:0		  // Serial Port
dvTP_XM_1    	= 10001:4:0   		 // Touch Panel
vdvXM_1		= 41004:1:0		// Virtual Device for Zone 1
DEFINE_VARIABLE
NON_VOLATILE CHAR cXM_Buff_1 [255] ;
DEFINE_START
CREATE_BUFFER dvXM_1, cXM_Buff_1 ;
DEFINE_MODULE 'Antex_XM100_Comm_dr1_0_0' COMM1(vdvXM_1, dvXM_1)
DEFINE_MODULE 'Antex_XM100_UI'	TP1(vdvXM_Arry, dvTP_XM_1, nXM_BtnArry, nXM_LVL_Arry, nXM_VT_Arry, nXM_DeBug)
DEFINE_EVENT
DATA_EVENT [dvXM_1]
     
     {
     ONLINE:
	  {
	  SEND_STRING dvXM_1,"'UN1',CRLF" ;//enable unsolicited responses.
	  if (nXM_DeBug)
	       {
	       SEND_STRING 0,"'dvXM_1 is online! Line-<',ITOA(__LINE__),'>',crlf" ;
	       }
	  }
     STRING:
	  {
	  if (nXM_DeBug)
	       {
	       SEND_STRING 0,"'cXM_Buff rcvd from device -> ',cXM_Buff_1,' <-Line-<',ITOA(__LINE__),'>',crlf" ;
	       }
	  }
     }

I get nothing in the debug window when watching "cXM_Buff_1" or in diadnostics when I set nXM_DeBug to 1. If I comment out the comm module they work fine so how the the comm module monopolize the dvXM_1 input buffer. I thought data from here could be routed to as many created buffers as we choose.

vining

Is it possible the comm modules uses data.text and that data.text works directly on the device port input buffer and is executing before my created buffer and because the comm modules string handler is removing the data before it can be passed to my created buffer the nothing in it for me to see when it gets to that point in the code?

Darkside

vining wrote:

I'm currently playing w/ an AMX written Duet module for an Antex XM tuner and if I create my own buffer for this device I don't get any strings from the device when the Duet comm module is running. If I comment out the Duet Comm module and recompile I get all strings from the device. With standard Netlinx modules I can create as many buffers as I want for a device if I choose so want does the Duet comm module do that prevents the buffer I create from receiving the same strings the Duet module receives.

I understand that some manufacturers involved in the Duet program etc. will not allow any of their protocol to be visible to anyone/anything that is not wired up to the physical port.

My understanding of this scenario, and I am happy to stand corrected here, is that even watching the serial port within NSX diagnostics will not show protocol strings being tx'd or rx'd from the comm module. This part of Studio has effectively been closed down to 'outsiders' to protect the intellectual property of the manufacturers.

I am not familiar with the device you are playing with, but perhaps this is why you can't see any protocol strings....

I can also think of 2 ways straight up that this 'problem' can be overcome with....

alexanbo

It's just a property of how duet works. When duet has control of a serial port you can't get feedback out of it in Netlinx. There's an initialize command that gives control to the Duet side of things.