I'd like to be able to programatically scan either a GPIB or TCPIP bus
to find connected instruments similar to how the TMTOOL or other similar
applications do (NI MAX, Agilent IO Libraries, etc).
I do not even know where to begin this process though as the instrument
control toolbox by itself only allows connections to known instruments.
Has someone out there done this before that could provide some
insight into the best way to accomplish what I want to do?
I'd like to be able to find the attached instruments on the bus, run the
*IDN? query to find the identifier and then report the results.
Thanks,
Jesse Lai
Subject: Re: Automatically scan for instruments on bus (GPIB or TCPIP)
Jesse Lai wrote:
> I'd like to be able to programatically scan either a GPIB or TCPIP bus
> to find connected instruments similar to how the TMTOOL or other similar
> applications do (NI MAX, Agilent IO Libraries, etc).
>
> I do not even know where to begin this process though as the instrument
> control toolbox by itself only allows connections to known instruments.
> Has someone out there done this before that could provide some
> insight into the best way to accomplish what I want to do?
>
> I'd like to be able to find the attached instruments on the bus, run the
> *IDN? query to find the identifier and then report the results.
>
> Thanks,
>
> Jesse Lai
Subject: Re: Automatically scan for instruments on bus (GPIB or TCPIP)
In article <PqGdnahZyrlBxgbanZ2dnUVZ_jWdnZ2d@comcast.com>,
Jesse Lai <someone@somewhere.com> wrote:
>Bump
>
>Jesse Lai wrote:
>> I'd like to be able to programatically scan either a GPIB or TCPIP bus
>> to find connected instruments similar to how the TMTOOL or other similar
>> applications do (NI MAX, Agilent IO Libraries, etc).
There is no such thing as a TCPIP bus.
The ease of finding instruments on a TCP/IP LAN (local area network)
varies with how the instruments are configured and upon whether
their operating system responds to broadcast messages. In the
general case, TCP/IP devices might have any of close to 15*2^31
different addresses that would each have to be tested individually
to detect the presense of an instrument on that address. If you are
assured that the addresses have been configured to be within a certain
range, you only have to scan that range -- quite practical if the
range is only 254 addresses, not so practical if the range is
65534 address, impractical for anything larger.
--
"History is a pile of debris" -- Laurie Anderson
Subject: Re: Automatically scan for instruments on bus (GPIB or TCPIP)
When I said TCPIP bus, of course its not a real bus, but it is similar
in meaning to the GPIB bus. Its just a way to describe instruments
connected via LAN.
If you look at TMTOOL in MATLAB, they have a scan for instruments tool
that scans the LAN for connected instruments. If you use some of
Agilent's tools, there is a similar feature. With Agilent's tools, it
can scan the LAN in a manner of seconds, so it is quite practical and
possible. I was hoping someone had some examples of an efficient way to
accomplish the task that I know is out there.
Commonly on a TCPIP "bus", the last octet is used, therefore you are
limited to really only about 254 possible addresses since the subnet
mask limits the others.
Walter Roberson wrote:
> In article <PqGdnahZyrlBxgbanZ2dnUVZ_jWdnZ2d@comcast.com>,
> Jesse Lai <someone@somewhere.com> wrote:
>> Bump
>>
>> Jesse Lai wrote:
>>> I'd like to be able to programatically scan either a GPIB or TCPIP bus
>>> to find connected instruments similar to how the TMTOOL or other similar
>>> applications do (NI MAX, Agilent IO Libraries, etc).
>
> There is no such thing as a TCPIP bus.
>
> The ease of finding instruments on a TCP/IP LAN (local area network)
> varies with how the instruments are configured and upon whether
> their operating system responds to broadcast messages. In the
> general case, TCP/IP devices might have any of close to 15*2^31
> different addresses that would each have to be tested individually
> to detect the presense of an instrument on that address. If you are
> assured that the addresses have been configured to be within a certain
> range, you only have to scan that range -- quite practical if the
> range is only 254 addresses, not so practical if the range is
> 65534 address, impractical for anything larger.
>
Subject: Re: Automatically scan for instruments on bus (GPIB or TCPIP)
Jesse Lai wrote on 26-Jan-08 09:26 :
[...]
> Commonly on a TCPIP "bus",
As Mr. Robinson tried so diligently to explain to you earlier, TCPIP is not a 'bus', it is a communication protocol. Also, the
acronym GPIB means 'general purpose interface bus', so TCPIP is not "...similar in meaning to the GPIB bus".
It seems unlikely you will be able to solve your problem if you cannot be bothered to understand fundamental terminology.
Subject: Re: Automatically scan for instruments on bus (GPIB or TCPIP)
D. Ismay wrote:
> Jesse Lai wrote on 26-Jan-08 09:26 :
> [...]
>> Commonly on a TCPIP "bus",
>
> As Mr. Robinson tried so diligently to explain to you earlier, TCPIP is
> not a 'bus', it is a communication protocol. Also, the acronym GPIB
> means 'general purpose interface bus', so TCPIP is not "...similar in
> meaning to the GPIB bus".
>
> It seems unlikely you will be able to solve your problem if you cannot
> be bothered to understand fundamental terminology.
I have already found a solution to my problem, now I just have to
compile a DLL for the code. I'm going to use NI's Measurement and
Automation Explorer as the repository for connected instruments just
like LabView does it.
I've found the correct .NET library calls from C# to obtain the list of
instruments on the various interfaces (GPIB, TCPIP, Serial, etc). I'll
compile it into a DLL, then call it from MATLAB.
Perhaps there is a better way to directly call .NET resources from
MATLAB? If not, I'll continue down this path.
Subject: Re: Automatically scan for instruments on bus (GPIB or TCPIP)
Jesse Lai <"jlai.[DELETETHIS]matlab"@gmail[NOSPAM].moc>
wrote in message
<nLqdnd10QJDNTAHanZ2dnUVZWhednZ2d@comcast.com>...
> D. Ismay wrote:
> > Jesse Lai wrote on 26-Jan-08 09:26 :
> > [...]
> >> Commonly on a TCPIP "bus",
> >
> > As Mr. Robinson tried so diligently to explain to you
earlier, TCPIP is
> > not a 'bus', it is a communication protocol. Also, the
acronym GPIB
> > means 'general purpose interface bus', so TCPIP is not
"...similar in
> > meaning to the GPIB bus".
> >
> > It seems unlikely you will be able to solve your problem
if you cannot
> > be bothered to understand fundamental terminology.
>
> I have already found a solution to my problem, now I just
have to
> compile a DLL for the code. I'm going to use NI's
Measurement and
> Automation Explorer as the repository for connected
instruments just
> like LabView does it.
>
> I've found the correct .NET library calls from C# to
obtain the list of
> instruments on the various interfaces (GPIB, TCPIP,
Serial, etc). I'll
> compile it into a DLL, then call it from MATLAB.
>
> Perhaps there is a better way to directly call .NET
resources from
> MATLAB? If not, I'll continue down this path.
Hi Jesse,
The way you get information about connected instruments is
to use 'instrhwinfo' command that ships with the Instrument
Control Toolbox.
info = instrhwinfo('gpib');
Will return structure info with all details (including
constructor to create GPIB object). Once you have an object,
you can pass *IDN? query and get the identification.
Similar commands you can use are:
infoVisa = instrhwinfo('visa','agilent');
infoTCPIP = instrhwinfo('tcpip');
infoUDP = instrhwinfo('udp');
infoSerial = instrhwinfo('serial');
help instrhwinfo should provide you with the documentation.
Public Submission Policy
NOTICE: Any content you submit to MATLAB Central, including personal information, is not subject to the protections which may be afforded information collected under other sections of The MathWorks, Inc. Web site. You are entirely responsible for
all content that you upload, post, e-mail, transmit or otherwise make available via MATLAB Central. The MathWorks does not control the content posted by visitors to MATLAB Central and, does not guarantee the accuracy, integrity, or quality of such content.
Under no circumstances will The MathWorks be liable in any way for any content not authored by The MathWorks, or any loss or damage of any kind incurred as a result of the use of any content posted, e-mailed, transmitted or otherwise made available
via MATLAB Central. Read the complete Disclaimer prior to use.