visadev (TCP/IP) not working with parfeval while working with visa

Hi,

in our lab we measure VISA instruments in parallel (parallel computing toolbox with parfeval) , in order to increase readout frequency. Connections are based on LAN-TCP/IP. In addition we read data from microcontrollers (with a webserver running on them) via Matlab standard webread/webwrite functions (see example for 4 parallel tasks below). None of these parallel reads interfere with each other.

So far we have been using the visa class, however, we are trying to upgrade to visadev now, as recommended.

I remember having issues with the old visa class + multiprocessing as well, but was able to mitigate them by calling fopen(visaObj) and finally fclose(visaObj) within the function to be called in parfeval (see example below). This however is no longer possible with visadev as it handles its connection by itself and only a clear would disconnect it, as far as I understand. I'm not sure if the error I face here is somehow related to this behaviour or not.

I have attached a minimal 'working' example of

(1) the script initializing the instrument and running the parallel readout with parfeval,

(2) the instrument class definition using visadev which does not work and

(3) the same dummy implementation using the old visa class which works. Of course I checked that the class methods run as expected when called in a non-parallel environment. I have not tried this with other VISA connection types (GPIB, USB etc.) or other parallel processing approaches yet.

I'd be grateful for any ideas. Unfortunately this really is a dealbreaker for us in the lab - and I assume for many other VISA users it will be as well. Parallel/Async readout really is a crucial topic for data acquisition.

Thanks,

Jakob Seidl

Infineon Technologies

The Error:

Error using parallel.FevalFuture/fetchNext

The function evaluation completed with an error.

Error in Run_DummyInstr (line 8)

[completedId,value] = fetchNext(parFuncArray);

Caused by:

Error using visalib.internal.VisaClient/disableErrorOnRead

Property assignment is not allowed when the object is empty. Use subscripted assignment to create an array

element.

% And looking at parFuncArray for a more precise Error message:

parFuncArray =

FevalFuture with properties:

ID: 58

Function: @(varargin)myInstr.readNtimes(varargin{:})

CreateDateTime: 01-Mar-2023 10:50:44

StartDateTime: 01-Mar-2023 10:50:44

RunningDuration: 0 days 0h 0m 0s

State: finished (read)

Error: Property assignment is not allowed when the object is empty. Use subscripted assignment to

create an array element.

VisaClient>VisaClient.disableErrorOnRead (line 0)

Resource>Resource.writeread (line 803)

DummyInstr>DummyInstr.read (line 20)

DummyInstr>DummyInstr.readNtimes (line 27)

LiveEditorEvaluationHelperE1672381259>@(varargin)myInstr.readNtimes(varargin{:}) (line 7)

while running:

%Example script running the instrument readout in parallel

myInstr = DummyInstr("169.254.128.3") % <--- does NOT work

% myInstr = DummyInstrOldVISA('169.254.128.3') % <--- does work !

%%

nReads = 100;

waitTime = 0.001;

%Dummy call for a single process only

parFuncArray(1) = parfeval(gcp,@myInstr.readNtimes,1, nReads, waitTime);

[completedId,value] = fetchNext(parFuncArray);

Dummy Instrument class definition | visadev vs. old visa implementation:

classdef DummyInstr < handle % Does NOT WORK with parfeval!

properties

address string

visaDev

end

methods

function obj = DummyInstr(address)

arguments

address (1,1) string

end

obj.address = address;

obj.visaDev = visadev("TCPIP0::" + address + "::inst0::INSTR"); %assuming it doesn't exist yet

end

function result = read(obj)

resultStrings = obj.visaDev.writeread(':SENS:PRES?').strip.split; % Example SCPI read command

result = str2double(resultStrings(2)); % the numeric part of the result string

end

function outputArray = readNtimes(obj, nPoints, waitTime)

outputArray = NaN(nPoints,2);

tic;

for iPoint = 1:nPoints

outputArray(iPoint,1) = obj.read;

outputArray(iPoint,2) = toc;

pause(waitTime);

end

end

end

end

% The only real difference is (a) the initialization syntax, (b) the query vs. readwrite syntax and (c) the fact that

% I open and close the connection in the readNTimes function.

classdef DummyInstrOldVISA < handle % This works with parfeval!

properties

address

visaDev

end

methods

function obj = DummyInstrOldVISA(address)

arguments

address

end

obj.address = address;

obj.visaDev = visa('agilent', ['TCPIP::' obj.address '::INSTR']);

end

function result = read(obj)

%Here we assume the connection has been opened alreay

result = str2double(strrep(query(obj.visaDev, ':SENS:PRES?'),':SENS:PRES ',''));

end

function outputArray = readNtimes(obj, nPoints, waitTime)

outputArray = NaN(nPoints,2);

tic;

fopen(obj.visaDev); %% Difference to new visadev

for iPoint = 1:nPoints

outputArray(iPoint,1) = obj.read;

outputArray(iPoint,2) = toc;

pause(waitTime);

end

fclose(obj.visaDev); %% Difference to new visadev

end

end

end

[chrisw23]

I recommed to use device status subsystem (STB) to configure specific SRQ like MAV or OPC and on the Matlab site establish ServiceRequest listener to read out data. This avoids blocking behaviour reading data in a loop.

You also have the opportunity to use a vendor specific VISA library via its .Net API and wrap RawIO asynchronous methods.

BTW: Using one instrument session with parallel running cmd sequences (request/meas/readout) will not work. There will be race conditions in all states. Throughput can be increased by procesing data asap without using all blocking pause commands.

[Jakob Seidl]

Hi Chris,

I guess using SRQ with MAV would make sense when having a single GPIB bus where devices really cannot send data in parallel (as it’s a real Bus). However, our use case is based on TCP/IP via a network switch that handles the timing of requests. I don’t think any race conditions arise because each physical instrument is represented by its own class instance with its own data container for measurement data (that no other obj will access).