K K

I was able to figure out how to reliably "dissolve" the tsp-link, do the `printbuffer` directly from the 2602B, then dissolve again, and resume using the DMM6500 as master. 

The non-obvious trick is to switch the DMM6500 to USB interface (I used LAN previously), and send the `abort` to the 2602B (via LAN interface) to dissolve the relationship, regardless of which instrument is master.

("dissolve" is vaguely detailed near page 9-3 of DMM6500-901-01 Rev. B / September 2019)

In a computer based system, the master/subordinate relationship between nodes can only be dissolved by performing an abort operation

Hello

After much work, I am able to use TSP-LINK efficiently for my application to simultaneously capture DMM6500 readings during a 2602B IV sweep.

However, the data transfer from 2602B is so slow via TSP-LINK (when DMM6500 is local master node).  Is there an alternative approach? 
 

Detail

It takes about 1000 milliseconds just for the printbuffer query (write + read)!  The rest of the test (including IV sweep) is only 300 milliseconds.  So downloading the data represents some 75% of the total test time!

Without TSP-LINK, using 2602B by itself, the printbuffer for the same sweep is only few tens of milliseconds.  I was going to use the 2602B as local / master node, but the DMM6500 manual says not to do this because 2600B is "old" or something.

Below is the command sent from the PC to the DMM6500 to retrieve the IV sweep data from the 2602B.  It has 351 rows and 12 columns.

printbuffer(1, node[2].smua.nvbuffer1.n, node[2].smua.nvbuffer1.readings, node[2].smua.nvbuffer2.readings, node[2].smua.nvbuffer1.sourcevalues, node[2].smua.nvbuffer1.timestamps, node[2].smua.nvbuffer1.statuses, node[2].smua.nvbuffer2.statuses, node[2].smub.nvbuffer1.readings, node[2].smub.nvbuffer2.readings, node[2].smub.nvbuffer1.sourcevalues, node[2].smub.nvbuffer1.timestamps, node[2].smub.nvbuffer1.statuses, node[2].smub.nvbuffer2.statuses)

One Alternative

I tried making a table on the 2602B, then adding it to the dataqueue, and finally querying dataqueue.next() on the DMM6500.  This method is about twice as fast (~500 ms), but still unacceptably slow!   and also code smell
 

function make_table()
    local arr = {}
    for i = 1, smua.nvbuffer1.n do
        arr[i] = smua.nvbuffer1.readings[i] ..",".. smua.nvbuffer2.readings[i] ..",".. smua.nvbuffer1.sourcevalues[i] ..",".. smua.nvbuffer1.timestamps[i] ..",".. smua.nvbuffer1.statuses[i] ..",".. smua.nvbuffer2.statuses[i] ..",".. smub.nvbuffer1.readings[i] ..",".. smub.nvbuffer2.readings[i] ..",".. smub.nvbuffer1.sourcevalues[i] ..",".. smub.nvbuffer1.timestamps[i] ..",".. smub.nvbuffer1.statuses[i] ..",".. smub.nvbuffer2.statuses[i]
    end
    return arr
end

The manual says printbuffer can accept tables, but i think this terminology is confused with proper lua tables as I cannot get printbuffer to work with a lua table, only reading buffers.  My idea is to print the table using format.REAL32 to reduce characters transferred (for speed).


How can I speed it up?  Thanks!

f