vining Posts: 4,368
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.
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). 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.
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.
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....