It is true that some of the APIs for our modular instruments use
components from the DAQ driver to talk to the hardware. This is
primarily for efficiency of development; for certain tasks, the
low-level programming of one of our DAQ boards and one of our
oscilloscope boards is very similar.
At th
It looks like this is a driver that Tektronix wrote and donated to the
Instrument Driver library. The VIs on the palette are a mix of
examples and instrument driver VIs, and the examples hard-code the
GPIB address. (The instrument driver VIs have the white background on
the icon, and the examples
I think I'm confused about what you are trying to do. Usually, you
configure remote devices you want to talk to. For example, if I have
an Ethernet-based Tektronix TDS 3054B scope that I want to talk to, I
can set up a VISA alias for its IP address (e.g.,
TCPIP::128.129.130.131::INSTR, for a VXI-
Hmm. You're right that we often use those terms interchangeably.
Technically, the driver is the piece of code that runs in the
operating system kernel that does the low-level programming of the I/O
hardware.
This low-level programming is somewhat complicated, so we create a
higher-level Applicat
First, I'd recommend that you try using VISA for serial I/O. It's
more robust.
It sounds like you might just be having problems with hardware flow
control. Do you have it enabled on your instrument? If not, I would
try enabling it, and enabling it with VISA in your application.
If you are gett
Can you explain what the difference is? What does the VISA name
control show? What does Windows show?
Brian
Yes, the provided VIs that work with wave files just like to treat
them as one enormous buffer, so that doesn't work very well for large
files.
Another approach would be to look at the wave file VIs and split them
apart. There's part that reads the header, and there's part that
reads the data. I
I agree with Dan's suggestion, but I have an additional question.
Are you reading large amounts of data, or small?
If large, then Dan's suggestion is sufficient.
If small, then I would follow Dan's suggestion, but also investigate
configuring your Reads and Writes to do I/O synchronously. (Ther
The VI you attached doesn't seem right. You only have one Initialize
function, and you are not wiring the correct string into it. It looks
like you're trying to wire "GPIB::13 19", which is not valid.
You need to have two different sets of Instrument Driver VIs.
Duplicate the three icons you hav
I think I understand. You don't need to have two different Initialize
functions; you can just place the regular Initialize function on your
diagram once.
To one Initialize, you wire one address, e.g., "GPIB0::13::INSTR", and
to the other, you wire the other address, e.g., wire
"GPIB0::19::INSTR".
I'm not entirely clear what it is you want to do. Do you want one
front panel to control all the generators in the same way all at once?
Or are you just wondering how you can specify which instrument each
instrument driver VI should talk to?
If it's the latter, you just call Initialize multiple t
Instrument I/O Assistant won't help you; it's for talking to
instruments connected through GPIB, Serial, and similar buses.
You need to use the Sound VIs. You can use the Example Finder to
search for "sound" and you should find several useful examples.
Brian
There are a couple of ways to talk to the parallel port in LabVIEW.
You can use NI-VISA to communicate with LPT1 (also known as, I think,
"ASRL::10::INSTR"). This will let you do straight reads and writes,
and assumes that the device uses pretty normal signaling. Under the
hood, NI-VISA is using
I think we need to learn more about your application. What instrument
vendor and model are you using? When you say that the subVI connects
for two seconds, is the two seconds spent inside of the ActiveX
object, or are you doing something in the subVI to wait two seconds?
If the two seconds is bei
LabVIEW can do VISA and NI-488.2 directly; you don't need C++ or VB.
First of all, you should see if there are instrument drivers available
for your instruments. There are thousands of free drivers available
on http://ni.com/idnet/. Search there first, because if you can find
a driver for any of
See my comments in your other posting of the same question, http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=5065000800A2D4&USEARCHCONTEXT_CATEGORY_0=_49_%24_6_&USEARCHCONTEXT_CATEGORY_S=0&UCATEGORY_0=_49_%24_6_&UCATEGORY_S=0";>here.
Brian
The strict answer to "Why?" is because we only implemented the special
initialization code for the Initialize function. "autoConnectToFirst"
is optional in VPP 3.2, and we chose not to implement it as a special
case.
You'll just need to fix the Call Library Node in your VI wrapper to
use the prop
You wrote, "I find it hard to believe that so many instrument did not
really meet the spec...".
I think you ascribe too much computing intelligence to these
instruments. Many of these devices run a simple "homemade" operating
system, or better, a commercial single-threaded embedded operating
syst
Be sure, when you build your application, that you check the checkbox
to include serial support. This will include the VISA serial support
in the resulting installer.
I suspect that you are getting an error somewhere in your application;
it's just not getting reported somehow.
Brian
I wonder if the timeout on Write is because the handshaking isn't
working. Suppose the device isn't handshaking the same way, or your
cable is bad. In that case, Write may just give up.
Brian
Could it be that you only have the Base version of LabVIEW? Only the
Full and Professional versions of LabVIEW have the Advanced Analysis
libraries.
Brian
As mentioned on our web site, the download version does not include
all of our drivers. You can request the CD version of the evaluation
software https://sine.ni.com/apps/we/nigb.main?code=GB_LVEVAL";>here,
and it includes the driver CD.
Alternatively, the latest versions of many of our drivers a
It looks like you are using the NI IVI Class Drivers, and have
configured them to use the Agilent IVI-C driver under the hood. For
some reason, it looks like the class drivers aren't happy with the
Agilent driver, and that's the cause of the error.
You should first confirm your IVI configuration
Dennis is right--you should use VISA.
The Device Control/Status function does not do what you want it to do.
Brian
I'm not an expert on the front panel data logging, so I'm not exactly
sure what's the best solution. It sounds like the VI has a reference
to the front panel datalogging file that you were using, and it's
unable to load this datalog file. I'm surprised that this is a fatal
error.
You should firs
I'll hazard a guess that you are reading data with VISA as a string.
Then you want to convert that (probably with Scan From String) into a
number. Then, you want to collect those numbers into an array.
We don't really have enough information to tell you the best way to do
this. Here are some ide
Error 37 is suspicious because it's not a VISA error. Can you confirm
that you are really using the LabVIEW 7 "Open Serial Driver"? (Look
inside that VI and see if it has VISA functions inside it. Make sure
your program is referencing the version from
vi.lib\instr\_sersup.llb.)
I am wondering i
You need to ensure that NI-VISA is installed on any machine that runs
the executable.
Brian
You do not have to use the defines in extcode.h, but you certainly can
if you want to.
The float64 is equivalent to CVI's "double", and the float32 is
equivalent to CVI's "float".
These correspond to the double- and single-precision types in the IEEE
Standard for Floating Point Arithmetic, IEEE-7
As Dennis points out, these VIs were initially created with the Import
CVI Instrument Driver utility. This utility programmatically scripts
the building of VIs from inside LabVIEW's C code (which is not an easy
thing to do). We script the VIs the way you describe to make the
scripting easier and
Ah, I think I understand.
Your ECU is sending a stream of six bytes...
FF,data1,data2,data3,data4,data5
And I guess it just does this continuously.
So, you probably want to continuously read the data and update a data
structure that shows all of your engineering data (such as what state
the thr
You do not need to write a C++ program to read data from an RS-232
port. You can use the "VISA Read" and "VISA Write" functions to read
and write from a serial port.
If you still want to write a C++ program for some purpose, you have a
couple of options. If you turn it into a shared library (e.g
The comments from the others are excellent, and worth pursuing. I
also checked Agilent's web site. In http://we.home.agilent.com/cgi-bin/bvpub/agilent/library/cp_LibraryFAQDetail.jsp?OID=536977078&NAV_ID=-536886896.536883195.03&LANGUAGE_CODE=eng&COUNTRY_CODE=ZZ";>this
article, they made it sound
If you aren't using VISA (e.g., using the pre-LV 7.0 "serpdrv" VIs),
then I suggest using VISA to improve performance.
If you are using VISA, you might also consider right clicking on your
VISA Read function and selecting "Do I/O Synchronously". This
optimizes for your situation--where you are re
You can use the "And" function with integer inputs. One of the inputs
comes from InPort, and the other is a constant hex 0x10. The result
of the "And" will also be a numeric. You can test this result with
the "=0?" function. If the result is zero, you do nothing. If the
result is non-zero, you
I don't know much about the 830 lock-in amplifier, but most
instruments use the same commands regardless of whether you use GPIB
or RS232.
So, I suggest that you download the LabVIEW driver from
http://ni.com/idnet/, and modify it to work with the serial port.
It may work with no changes. Or, yo
Rather than use VISA, you might consider using the Port I/O functions.
This would make for a more straightforward translation of your
program.
Brian
If I understand correctly, you have a string with those three bytes in
it.
You might consider using String to Byte Array. This will help with
the second and third bytes--it'll convert them to unsigned int8's.
The third byte is signed, but you can just convert that byte to an
int8 and it'll do th
Are you using the LabVIEW instrument driver? If not, go to
http://ni.com/idnet/, and search for "33120a". I downloaded the
LabVIEW Plug and Play driver--i.e., the native LV source code driver.
(There are also CVI and IVI drivers available.)
Anyway, if you download this driver, the VI you want is
Before I forget to ask, will you just be reading back individual
values, or will you get several values for any probes? I.e., will you
ever get something like this...
!Temp1987654321EndOfData
(where "98" is the first point of 16-bits, "76" the next, etc.) or
will it always just be a single point
Regarding the serial issue...
Are you using VISA or the "builtin" serial VIs? Are you using
hardware flow control?
If you aren't using flow control, then it's very likely that the
serial port isn't being serviced fast enough and bytes are being lost
because of this.
I think the "builtin" VIs (o
So it sounds like you want to send back a sequence of two-byte binary
data samples. Thus, you'll use the Type Cast function.
(When I talked about ASCII, I meant that encoded the value "142" as
three ASCII characters, '1', '4' and '2'. It sounds like you are not
going to encode your data this way
Regarding your string parsing...
Maybe I don't understand your protocol, but it looks to me like it's
just a simple query/response protocol. So I'm not sure what you mean
when you talk about a continuous stream of data.
It seems like you'd just send "?Temperature1\n" and immediately do a
VISA Re
The suggestion to go back and confirm that you have really installed
NI-DAQ is a good one. Here are some other thoughts.
Are you loading an application you built in an older version of
LabVIEW, and this is the first time you are loading it in 5.1.1?
Do you still have the older version around? Y
There is a date after which the evaluation versions refuse to run
because they're too old. (NI wants you to be evaluating the latest
version, not a three-year-old version.)
LabVIEW 6i is a little over three years old. Not sure when a 6.1
evaluation version came out; it may be using the 6i timeou
Utilities is spelled differently.
I guess I'm still finding this a surprising result and would like more
information. While the others are correct about the roles of the IEEE
specifications, both sets of LabVIEW functions (Traditional vs. 488.2)
are built on top of NI-488.2.
At the bus level, there's not really much difference in
I find this pretty surprising. Can you provide us with more
information?
Were you using an instrument driver? What instrument commands were
you sending? What errors did you get?
Thanks.
Brian
Actually, you can leave out the zero. "GPIB::10" is the same as
"GPIB0::10", and both are an abbreviation for "GPIB0::10::INSTR".
Brian
It depends on what you're trying to do. What options do you want to
set? Are you trying to make a multi-device bus out of RS-422?
One way to think of RS-422 is that it is just RS-232 with differential
electrical signals instead of grounded. (And it's got tighter
restrictions on voltage levels.)
By the way, the VIWaitOnEvent timeout error is normal. We
occasionally check for an event with a short timeout to see what's
going on with VISA.
What's wrong with using VISA? It's better (faster and more reliable)
than the old "builtin" serial VIs (using "serpdrv").
52 matches
Mail list logo
