Using CIN for the first time - where are the files??

[gnottage@my-deja.com]

Hi,

I'm hoping to create a CIN with LV4.1 and MS
VC++6, and have run into problems as I can't find
the following files (I have no Cintools
directory!):

cin.obj
labview.lib
lvsb.lib
lvsbmain.def

I just have a standard install as I only use a
serial port for data entry. I was hoping to use
dll's written in Visual C++, but LabVIEW seems
not to be able to handle multiple strings (or
even a single string) as a return. This is
basically so new products can be supported
without distibuting a CD every time to every user.

I hope someone can point me in the right
direction...

Gavin Nottage


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

[Stefan Tauche]

Hi,

labview sure can handle a string as return from a CIN, i think you'll
have to use an input string (file with space or the like) which is long
enough to take the CINs output. You can use the LV-string as a normal
char*-Pointer in C.
But in no case without the stuff in ./cintools. Maybe you didn't check
this during installation ?

Regards
Stefan 😉

--
|| Stefan Tauche Infineon Technologies AG, Munich
|| A Siemens Corporate
||
|| Email: stefan.tauche@No-spam.infineon.com
\\=========(remove No-Spam from address to reply)==========

[Greg_McKaskle2]

> I'm hoping to create a CIN with LV4.1 and MS
> VC++6, and have run into problems as I can't find
> the following files (I have no Cintools
> directory!):
>

Do you know whether you have the Base edition? CIN
tools are a part of the Full and Pro, but not base.

>
> I just have a standard install as I only use a
> serial port for data entry. I was hoping to use
> dll's written in Visual C++, but LabVIEW seems
> not to be able to handle multiple strings (or
> even a single string) as a return. This is
> basically so new products can be supported
> without distibuting a CD every time to every user.
>

Later versions of LabVIEW do support return values
as strings. The manual states for sure, but I believe
the pointer is assumed to be a constructed pointer
that doesn't
need to be freed. That is the problem
with returning strings in C code, is that there is
ambiguity as to whether free should be called on it.

For that reason, early versions of the DLL node just
didn't offer it. If this DLL is for LabVIEW or can
have entrypoints especially for LabVIEW, then you
can pass in a LV string -- a resizable handle -- which
you can resize and fill the data into. This is the
type of string that will ultimately flow down the wire
anyway, and it is more efficient to have the DLL use
it too.

Greg McKaskle

[B & C Duffey]

Greg McKaskle wrote in message <3772247A.BE7F45E1@austin.rr.com>...
...
>Do you know whether you have the Base edition? CIN
>tools are a part of the Full and Pro, but not base.
>


This really irks me - I see no rational for why the basic version of LabVIEW
does not include the CIN tools, of course ALL versions of LabVIEW have the
support to link external code and dlls. CIN interface Tools IMHO is a basic
feature of LabVIEW and not including CIN tools in the Base version is just a
marketing gimmic to justify the higher price of the Full and Pro versions
(which BTW is more than justifed by the other components included in those
versions).

And speaking of features that should be included in even the most basic
version of LabVIEW how about the App builder. I h
ave purchased the App
builder with every version of LabVIEW I have used, and it was a bitter pill
to swallow each time. You would never put up with a C++ compiler that
couldn't make executable files why do we have to pay an extra ~ $1k to do
what the most basic compilers can do.

The App builder is a great product that really adds to the usability and
possibilities of LabVIEW - but PLEASE ! The App builder is another case of
sellers market syndrome - basically as a consumer wanting to use LabVIEW I
have NO choice.

Sorry to vent but the CIN Tools thing bit me before.

Chris Duffey
Lead Instrumentation Engineer
Northrop Grumman Integrated Aerostructures Sector
duffech@mail.northgrum.com

[Greg_McKaskle2]

> This really irks me - I see no rational for why the basic version of LabVIEW
> does not include the CIN tools, of course ALL versions of LabVIEW have the
> support to link external code and dlls. CIN interface Tools IMHO is a basic
> feature of LabVIEW and not including CIN tools in the Base version is just a
> marketing gimmic to justify the higher price of the Full and Pro versions
> (which BTW is more than justifed by the other components included in those
> versions).
>

The base version of LV didn't exist until LV went from the Mac to the PC.
At that point the price wasn't raised, but it was decided to sell
a less expensive version with fewer features. The previous package
had everything in it and the new package was to cost half to price; so

features needed to be arbitrarily split out. At that point there was
no support for DLLs/Call Library. When these features were added, it
was arbitrarily decided to put the DLL in the base package. Way more
people want to call a DLL than know how to build one or compile C code;
so it was decided to put it in the base package. You have to admit that
CINs are an advanced feature. If NI were trying to be greedy, no new
functionality would go into the base package, but lots of features do.
NI doesn't remove functionality from the base package either, we add to
it.

....
>
> The App builder is a great product that really adds to the usability and
> possibilities of LabVIEW...

Well said. I don't want to argue about the price of the product. I was
trying to help with a CIN question.

Greg McKaskle

[gnottage@my-deja.com]

I believe the version I use is the base one (although I do have the app
builder, as I see it as essential). If it m,ens an upgrade to use the
CIN stuff, then I think I wont bother, as my company is quite tight
when it comes to spending huge ammounts on development software (even
if the end product justifies it.

Therefore if anyone has knowlegde of passing back (multiple) strings
from a (Visual C++) dll in LabVIEW, I would greatly appreciate help!

As an aside, the standard LabVIEW I ahve seems to be a ble to support
GPIB and VISA etc, which I doubt that many people use - si I'd quite
like to see a base version which has the kind of features most
programmers would want and not the specialised data aquisition on which
LabVIEW was origin
ally designed. A market shift if you want - they
could sell a lot of them...

Gavin NOttage


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.