VISA without hardware?

[Ihr Name]

Hi!

Is there a way to use vi's that use VISA for communication with an
instrument without actually having this instrument? In other words: may
I be able to simulate such an instrument?

I want to catch the messages that VISA sends to the instrument and I
only want to use the vi as an "input dialog". Actually I don't need to
control a real instrument.

Any suggestions?

Thanks,
Tobias Brueckner.

[James Morrison/Joan Lester]

I don't think you can. VISA does not support simulate. What I do is have
a case around the VISA call and have the case controled by an input
'simulate' (a boolean).

Jim

Ihr Name wrote:

> Hi!
>
> Is there a way to use vi's that use VISA for communication with an
> instrument without actually having this instrument? In other words: may
> I be able to simulate such an instrument?
>
> I want to catch the messages that VISA sends to the instrument and I
> only want to use the vi as an "input dialog". Actually I don't need to
> control a real instrument.
>
> Any suggestions?
>
> Thanks,
> Tobias Brueckner.

[Tobias Brueckner]

Hi!

James Morrison/Joan Lester wrote:
>
> I don't think you can. VISA does not support simulate. What I do is have
> a case around the VISA call and have the case controled by an input
> 'simulate' (a boolean).

Ah, thanks.

But do you think it is possible to tell VISA to use an instrument
connected to the serial port and actually catch all messages that go to
this port? Because if you can interrupt this communication, you would be
able to respond just like a real instrument although no hardware is
involved.

Tobias Brueckner.

[Kevin_work]

Ihr Name wrote:

> Hi!
>
> Is there a way to use vi's that use VISA for communication with an
> instrument without actually having this instrument? In other words: may
> I be able to simulate such an instrument?
> Any suggestions?
>
> Thanks,
> Tobias Brueckner.

I think you should look at IVI, it allows for simulation of an instrument
without haveing to have the instrument connected.
Kevin Kent

[James Morrison/Joan Lester]

Yes, assuming IVI has the instrument class you defined. This is pretty
limited so far and IVI is not free....

I think you are looking at writing your own serial simulator. Maybe a state
machine that reacts to your inputs and responds with a simulated response
that matches the input. If you use the VISA call and no serial is there it
will error on you or time out because the serial buffer is empty.

Jim

"Kevin B. Kent" wrote:

> Ihr Name wrote:
>
> > Hi!
> >
> > Is there a way to use vi's that use VISA for communication with an
> > instrument without actually having this instrument? In other words: may
> > I be able to simulate such an instrument?
> > Any suggestions?
> >
> > Thanks,
> > Tobias Brueckner.
>
> I think you should look at IVI, i
t allows for simulation of an instrument
> without haveing to have the instrument connected.
> Kevin Kent

[Tobias Brueckner]

James Morrison/Joan Lester wrote:
>
> Yes, assuming IVI has the instrument class you defined. This is pretty
> limited so far and IVI is not free....

I allways thought that one can convert any LabWindows driver into an
IVI?

> I think you are looking at writing your own serial simulator. Maybe a state
> machine that reacts to your inputs and responds with a simulated response
> that matches the input. If you use the VISA call and no serial is there it
> will error on you or time out because the serial buffer is empty.

Yes, perhaps I should think about writing such a program.

But again thinking about the IVIs: is there a central function that
writes all the instrument commands to the hardware? I need those
commands that are sended to the inst
rument. In fact I want the user to
use a common panel to operate with the (simulated) instrument. And when
he uses a control I want to save those (VISA?) commands for later usage.

So would it be better to use an IVI or writing a "serial port listener"?

Thanks, Tobias Brueckner.

[James Morrison/Joan Lester]

I have never actually used IVI. I've been to the hands on demos and have read the
literature. We do mostly telecom stuff and the IVI drivers for these instruments
is in development or a ways off. I'm definately all for it but for now we have
made our own interchangeable drivers with simulation, state cacheing and
transaction logging. The latter I'm not sure if IVI does. But this is basically
writing to a file the command sent, time, instrument, etc.

I should also mention I am a LabVIEW user so I do not have the ability to create
my own IVI stuff which I believe you are correct in saying the CVI user can. I'll
have to look in to that a bit.

I'm not sure how good the IVI simulations are. Ours range from very extensive
state machines to simple one number answers, just depends on the situation. We
definately have found investing the time to build simulation into your code is
worth its weight in gold.

Jim

Tobias Brueckner wrote:

> James Morrison/Joan Lester wrote:
> >
> > Yes, assuming IVI has the instrument class you defined. This is pretty
> > limited so far and IVI is not free....
>
> I allways thought that one can convert any LabWindows driver into an
> IVI?
>
> > I think you are looking at writing your own serial simulator. Maybe a state
> > machine that reacts to your inputs and responds with a simulated response
> > that matches the input. If you use the VISA call and no serial is there it
> > will error on you or time out because the serial buffer is empty.
>
> Yes, perhaps I should think about writing such a program.
>
> But again thinking about the IVIs: is there a central function that
> writes all the instrument commands to the hardware? I need those
> commands that are sended to the instrument. In fact I want the user to
> use a common panel to operate with the (simulated) instrument. And when
> he uses a control I want to save those (VISA?) commands for later usage.
>
> So would it be better to use an IVI or writing a "serial port listener"?
>
> Thanks, Tobias Brueckner.

[Tobias Brueckner]

James Morrison/Joan Lester wrote:
>

(snip)

> I'm not sure how good the IVI simulations are. Ours range from very extensive
> state machines to simple one number answers, just depends on the situation. We
> definately have found investing the time to build simulation into your code is
> worth its weight in gold.

In the meantime I took a closer look at IVI and I don't know if it is
the right thing for me. It would be nice to use common LabView device
panels to create VISA commands because the user knows how to use these
panels. If I want to use the IVIs then I have to rebuild all the panels
we want to support.

So I think there are two ways (for both I have to use VISA and write
data to the serial port):

a) I write a program
that catches all data send to the serial port and
that simulates an instrument. Writing such a program might be a little
difficult, I think.

b) I use a null modem cable: VISA writes all it's data to one serial
port and I read it by another port. The reading might be performed by
another LabVIEW program. (Thanks to Alan Brause for this suggestion!)

I don't know which way to choose but I'll read a little more docs to
find a solution.

Thanks to you all,
Tobias Brueckner.

[ks2]

Tobias Brueckner wrote:
>James Morrison/Joan Lester wrote:>> >>(snip)>>> I'm not sure how good the
IVI simulations are. Ours range from very extensive>> state machines to
simple one number answers, just depends on the situation. We>> definately
have found investing the time to build simulation into your code is>> worth
its weight in gold.>>In the meantime I took a closer look at IVI and I don't
know if it is>the right thing for me. It would be nice to use common LabView
device>panels to create VISA commands because the user knows how to use these>panels.
If I want to use the IVIs then I have to rebuild all the panels>we want to
support.>>So I think there are two ways (for both I have to use VISA and
w
rite>data to the serial port):>>a) I write a program that catches all data
send to the serial port and>that simulates an instrument. Writing such a
program might be a little>difficult, I think.>>b) I use a null modem cable:
VISA writes all it's data to one serial>port and I read it by another port.
The reading might be performed by>another LabVIEW program. (Thanks to Alan
Brause for this suggestion!)>>I don't know which way to choose but I'll read
a little more docs to>find a solution.>>Thanks to you all,>Tobias Brueckner.

Tobias,

On the first issue, monitoring the calls, you can use NI-SPY which installs
with VISA to monitor 488.2 and VISA calls ... including the data that is
sent. When you do run this you have to make sure that you launch NI-SPY before
launching the application.

The second issue you mentioned may be a little troublesome if you're using
another application. The serial drivers only allow one application to communciate
through the port at a time so you'd have to do b
oth the writing and reading
in the same app. An alternative would be to go from COM1 to COM2 and have
the other application read from COM2.

Good luck.
Kamran Shah
National Instruments

[Johannes Niess]

"Kamran Shah" writes:


[...]

>
> The second issue you mentioned may be a little troublesome if you're using
> another application. The serial drivers only allow one application to communciate
> through the port at a time so you'd have to do both the writing and reading
> in the same app. An alternative would be to go from COM1 to COM2 and have
> the other application read from COM2.
>
> Good luck.
> Kamran Shah
> National Instruments

Kamran,

Newbies in this news group might take all words coming from NI as
true, so I'd like to clarify you:

It's allowed to use one serial port from different applications, VI's
and even multiple times in the same VI. To get usefull data for the
differ
ent usages you need some way of access arbitration. I use a
named semaphore (which gets locked and unlocked), because VISA locking
depends on the session, not the port. In the end you do I/O procedures
one at a time, but delay between different I/O processes is in the
order of miliseconds.

I use an external RS231/RS485 converter and I run control loops for
the different devices in parallel (with semaphore locking). Data flow
programming has big advantages here.

Johannes Niess