Rolf Kalbermatter

QUOTE(robijn @ Jul 4 2007, 10:44 AM)

It seems like the C string parameter is now behaving slightly different on the DLL call. I have a function that requires a prealocated space, so I supply it with a string of sufficient length and tell the function in the next parameter how much space it is allowed to use. There is a difference between how LV 7.1.1 handles the returned string and how LV8.2 does that. The former leaves the string unbothered, even if there are null characters in it. LV 8.2 seems to think "it's a C string, so a 0 means end of string" and consequently it cuts the string just before this 0 character. This is usually good, but not always: often we knew that a C string was the same as a C U8 array so we used strings as medium to transfer bytes even if they could be zero. It seems we cannot do that anymore in LV8. Well, maybe it's better this way.

I was pretty sure that LabVIEW terminated strings on return on the first NULL character already in LabVIEW 7 and I think even in LabVIEW 6. I did rely in 6.x several times on that, so not sure why you would see something else. If that is not desired you need to use byte arrays.

Rolf Kalbermatter

QUOTE(PeterB @ Jul 4 2007, 07:50 AM)

Thanks for your reply Rolf, but I still don't get it :question:

In the LabVIEW project manager in the build specifications section (not from within Visual C etc), where do I specify to link in the VISSIM32.LIB file prior to compiling my LabVIEW shared library (DLL) under LabVIEW ?

You don't! LabVIEW can NOT do anything with lib and obj files. That is for C compilers only and even then you have to have lib and obj files that are compatible for your C compiler, eg. meaning they should have been created by the C compiler you want to use them with too. You can't create a LabVIEW DLL and hope that LabVIEW will link to your lib file magically. A LabVIEW DLL is really a LabVIEW LLB with very small exported C wrappers around those VIs inside the LLB. There is no way you can influence the C wrapper generation made through the LabWindows CVI runtime engine to somehow include your lib file and even if you could it wouldn't help either, as the wrapper code generation does not know how to link to other lib files than what is necessary to wrap the VIs such that they can be called as a DLL export function.

If this lib file is only an import library to the actual functionallity in a DLL then you could instead link to that DLL through the Call Library Node. Otherwise there will be no way around creating some C code to be put in a DLL and that can be called by LabVIEW that links with your lib file. In that case you need to create a DLL in Visual C, that you can call from LabVIEW and you want to include that lib file into that Visual C DLL project.

I hope I didn't confuse more than help but it's simple! If the actual functionality of your lib file is not located in a DLL file for which you have documentation and the API interface, then you WILL have to create a C DLL first.

Ok I reread the first post once more and I see that you want to create a DLL to be integrated in VisSim and that the DLL needs to link to vissim32.lib. This can't work without Visual C. In fact their statement that any environment that can create DLLs should work is mostly wrong. Besides Visual C there is only LabWindows CVI and proabably Borland C that can directly link with vissim32.lib. lib and obj files are binary files that can come in many flavors and Visual C will generate and require so called COFF format, while Borland will generate and prefer OMF format. LabWindows CVI used to support both formats for generation and linking but you needed to decide whith format you wanted during installation. LabVIEW can not generate obj files. What it can and does do is generating Visual C compatible import libraries for the LabVIEW generated DLLs. So what you can do if you need to generate Vissim callable DLLs that incorporate LabVIEW code is to generate the LabVIEW DLL and then generate another C DLL that also includes the lib file for vissim32.lib and your LabVIEW DLL import lib file.

Rolf Kalbermatter

QUOTE(PeterB @ Jul 3 2007, 11:49 PM)

Hi there,

I would like to write a DLL with LabVIEW. The purpose of this DLL will be to act as a (shared memory) repository to allow data to be exchanged between my LabVIEW program and a VisSim program. (up until now I have used DDE to do this, but I would like to change the approach for a no. of reasons that I won't get into now)

Before I get into discussions about the finer details (i.e. UI thread, reentrant, mutex protection etc) I need to know if I can actually compile this DLL using LabVIEW so that VisSim gets what it needs.

Below you can see an extract from the VisSim user manual explaining how to write 3rd party DLLs that VisSim can call. It mentions .LIB and .OBJ files. When I have previously compiled DLLs using LabVIEW I have never needed to link in .LIB or .OBJ files before. Is that even possible with LabVIEW? If it isn't then can I just create an OBJ file from LabVIEW and link that to VISSIM32.LIB using another compiler ? (BTW the attached diagram shows a 'custom dialog box' which I don't need to use)

Well if you create a DLL you always link with lib and/or obj files unless you never use any library functions, be it LabVIEW External Code functions, C runtime functions, or Windows API functions. But in Visual C you don't need to specify the C runtime library and Windows API import library specifically since most of them are added by default to a project and the Visual C linker picks from them whatever he needs.

An obj file is the compiled form of a single .c or similar file and a lib file is just a collection of several obj files. EXEs and DLLs are the combination of all obj and lib files with some extra startup stub and possibly resources and other custom stuff put into.

Basically you want to add your custom library file to your project somehow. You can do this by adding it explicitedly to the files that your project consists of, or in the project settings add the name of the library under Linker Settings and also provide a path to the directory where Visual C can find that library.

Rolf Kalbermatter

QUOTE(communityguy @ Jun 29 2007, 03:27 PM)

I'm sure you've seen this but open up LabVIEW and your MyPictures folder and drag and drop an image from MyPictures into the VI icon in the upper right. I believe this ability began with LabVIEW 8 (don't quote me on that though! )

Actually it's more something like LabVIEW 5 or 6 . But it could have been BMP only (PICT etc on Mac) back then.

Rolf Kalbermatter

QUOTE(ZZZZZZ @ Jun 29 2007, 02:16 PM)

NI-Service Locator. (I googled it and everything tells me this is potential spyware too.

Though since I've not yet seen encrypted traffic from it, it may still be harmless.

But I'm just waiting for the day when NI start using SSL to encrypt any outbound communication like Google does and many other traffic analysis servers.)

There are only so many TCP-IP ports but each server/service that needs to be IPC accessible needs to have one. Now NI can't go and register 200 well known IP ports for itself as that would not be tolerated by others nor would it be possible at all. So NI, and MS LM etc does the same, deviced a Service Locator. All this service does is listening on a well known port for service registrations with service name and not well known port number and then other applications/services (LabVIEW, online HTML help, Time Synchronization Service, Domain Security Service, Logos data protocol which I think is the base for Data Socket and Shared Variables, etc) can ask this service locater for the not well known port number of another service. On Windows this service locater is a native executable installed as service, on other platforms it used to be a VI based TCP IP server.

Rolf Kalbermatter

QUOTE(vinamra @ Jun 28 2007, 10:44 PM)

Hi,

I need to know whether Labview software supports the following hardware and software,

Software information:

http://www.girder.nl/products.php?section=girder

Hardware information:

http://www.girder.nl/products.php?section=usbuirt

These need to be controlled for the Automation.

Thanks

I would say you have to ask the guys from Girder. LabVIEW can do just about anything you could do in Visual Basic or similar and a lot more so ask them if you can control their stuff in VB, if they haven't heard of LabVIEW. If they say it can then ask them for examples. I would guess that the Girder package might have an ActiveX Automation interface somehow that you could use.

As to the hardware it does not say if the IR Detector will be installed as a virtual COM port. So I have a hunch that it isn't and you will need to get some API (DLL or raw USB protocol stream) in order to control that device directly from within LabVIEW. Not sure what you could gain with that as you would still have to know about the data format of the different IR commands too, which I suppose are manyfold depending on the remote control manufacturer.

Rolf Kalbermatter

QUOTE(orko @ Jun 27 2007, 06:44 PM)

UPDATE:

--------

I've fixed the "Clean Up Wires.vi" utility so that it works with Undo and records modifications on the BD (prompts for save). I'm unsure though whether the desired undo behavior would be to undo each wire individually or to undo the whole cleanup in one shot. The current version works on each wire individually.

Each wire individually doesn't sound intuitive to me. Usually every user action is considered an Undo Transaction and selecting your wiring cleaner tool in the menu would seem to me one single user action. Imagine your tool doing 500 wire modifications and then the user realizes he wants to undo the operation just before he selected your tool. Ouch!!!!!!

Rolf Kalbermatter

QUOTE(orko @ Jun 27 2007, 04:06 PM)

Alright, this is baffling me.

Pulling an idea from my other post here, I'm trying to figure out how to tell LabVIEW that changes were made to the BD with the "CleanUp Wire" method.

1) I would like the utility in that post to notify LabVIEW that changes were made if it moves any wires, and prompt the user for a save on close. I thought that it would be as simple as to set the BD docmods to something non-zero, but that doesn't appear to work. I even tried to capture the docmod values after a normal "cleanup wire" action and set them to that value, and the asterisk never appears on the title bar Has anyone had any luck with this?

2) It would be very nice to be able to "Undo" the wire cleanup in case the end result isn't ideal. Were is the undo state information stored, and how do I insert my changes into it's "stack"?

http://forums.lavag.org/index.php?act=attach&type=post&id=6245

Thanks for any help.

Have you tried these?

Rolf Kalbermatter

QUOTE(yen @ Jun 26 2007, 02:35 PM)

After more than 750 posts, I think an introduction is in order.

I don't want to repost, so you can just read the details http://forums.ni.com/ni/board/message?board.id=BreakPoint&message.id=3870' target="_blank">here.

Nice to see you finally :-) A big mystery lifted and now we can all go back to our work and finally continue to write great programs.

You did create a big enigma over at the dark side. And it was fun to read those that were mulling over what sex this overactive forum member might be. Unfortunately I won't make it to NI Week this year but have fun there. Shouldn't really be to hard with all those people from here and other LabVIEW related places.

Rolf Kalbermatter

QUOTE(Sherif @ Jun 26 2007, 10:05 AM)

Sherif Farouk (",)

" Help someone when he is in trouble and he will remember you when he is in trouble again"

Well that is so true for some people! :-)

Rolf Kalbermatter

QUOTE(Nullllll @ Jun 24 2007, 07:07 AM)

<br />i want 2 open the Barbi dor by labview , have my daq card i have digital I/O , but the door is small , how can i open it by relay?<br /> THE OUTPUT OF RELAY GOES TO WHAT?<br />

Has the door of your home any mechanisme to control it at all???? I mean this is the most basic question and I haven't seen mentioning you anything in detail about that fact yet. You ask about if you should use a motor, yes and that tells me it hasn't such a mechanisme built in so maybe you should try to contact the tech workshop at your place first and talk with them about the mechanical construction to allow your door to be opened at all. Then when they have given you a solution to open that door somehow we can talk further about how to control it from LabVIEW.

Rolf Kalbermatter

QUOTE(Aristos Queue @ Jun 22 2007, 08:18 PM)

The probe would have to be the VI that *opens* the refnum. A refnum goes invalid when the VI that opened the refnum goes idle even if you pass that refnum to some other VI by some means. The other VI can be using that refnum and the number will start returning errors for invalid refnum when the original VI goes idle.

With something like the queue or notifier refnums, you might be able to look up the item's name and open a new reference to the same item. But for file refnums and similar, there's only one refnum and when it goes stale, there's no other way to get the reference.

Actually there is a primitive somewhere that returns the file name for a given file refnum. So it would be possible to find out the file name and open a new refnum to that file, provided the access and deny rights from the initial open allow for that.

Rolf Kalbermatter

QUOTE(Thang Nguyen @ Jun 22 2007, 01:58 PM)

Rolfk,

Thank you so much,

The reason I have to call the open twice because at the first time it cannot open the connection. In my program, I allow user retrive the connection with the device if it cannot open the connection automatically. If the connection does not open, there will be a dialog allow user to call this VI again, then it works. The only problem is it cannot work in the executable file. That make me confuse.

Base on your solution, I will try to close the connection before open it.

Could you tell me where did you fix in the library or can you remake it in the LabVIEW 8.2? I use LV 8.2.1.

Thang Nguyen

Not sure about your problem. Since it is UDP, routing should probably not be a problem. It either works (if it is on the same subnet) or it won't. However maybe your network, device or whatever could be slow and the default timeout won't work. Ever tried to increase the timeout?

And about the LabVIEW version, higher LabVIEW versions can open lower version VIs. They have the diagram and all so you can do that conversion simply yourself. The changes were mostly in DNET UDP Get Devices.vi apart from some minor cosmetic ones. Do a VI compare on that one to see the difference.

Rolf Kalbermatter

QUOTE(Thang Nguyen @ Jun 22 2007, 12:08 PM)

Hi,

My project requires to connect with a Direct Logic PLC base on the UDP protocal. I have the driver for the PLC.

The communication is started by initialize the UDP communication and generate a connection ID. If I need to read something form the PCL by using the driver VIs, I need to connect this VI with this connection ID. The program works fine before building executable file. I have normal connection, although I have to initialize the connection with the PLC two times. I think the problem because of the UDP protocal. Then when program runs, I can get all of the data I need.

The issuse is after I build the executable file. I cannot initialize the connection anymore. I attach here the error message.

I don't understand why there is a different between program run based on executable file and based on compile form the code. Is it the problem with the driver library? I use this VI by open the functions palette, then click select a VI, then browse to the VI in the llb.

Please help me on this issue. Highly appreciate your time.

Thank you so much,

Thang Nguyen

Welcome to this library from yours truly. Why you would have to call the Open twice I'm not exactly shure. It isn't necessary for me and most probably is the cause for your runtime error since error 60 means that there is already a connection open to that specific address/port pair.

Also I recently found a bug in this library that prevented it to work with PLC Direct systems equiped with the ECOM100 interface. Attached version (LabVIEW 7.1) fixes that so that it also works with that module.

Also your attachment wouldn't help anyone not having the library much as it is missing utility functions located dnetudpu.llb.

Rolf Kalbermatter

QUOTE(yen @ Jun 19 2007, 04:18 PM)

I didn't care about the acknowledgement, I simply really do not understand the need for an installer.

Is placing the LV RTE in a folder THAT complicated or does the installer do other things as well?

What I did in the past was an experiment, so I didn't dig deep into this, but I believe in the near future I will need to do this, so I definitely appreciate the details. It simply didn't strike me as being complicated.

I do this for the Autorun program on CDs that installs my application (whose installer does use the normal NI installer technology). Basically it depends on the LabVIEW version but I use for this 7.1 and need following files:

dir

autorun.exe obviously my LabVIEW autorun program

autorun.ini just for having the HideRootWindow=True

lvapp.rsc

lvrt.dll

mesa.dll Probably only necessary since I use the "modern" 3D controls there

vidialog.rsc

models

box_inc.ptc This is the graphics definition for the modern 3D buttons that are used

Obviously if you go and use other 3D controls you will have to include more files from the models directory. Other things that could be necessary are lvstring.rsc (LabVIEW error messages and many more), lvobject.rsc (for other LabVIEW controls), lvpng.dll and lvjpeg.dll if you make use of jpeg or png functionality, lvanlys.dll for Advanced Analysis functions, but this won't really work as it also needs an intall of the MAth Kernal Library and that is also a question of correct registry settings for LabVIEW to be able to find that). If you use IMAQ too you also should forget about trying to get this all right yourself. It is not trivial at all.

LabVIEW 8.x makes this all also a bit more complicated as the numbers of files that the LabVIEW rt system absolutely needs are growing with each version again.

Rolf Kalbermatter

QUOTE(Justin Goeres @ Jun 18 2007, 01:33 PM)

Basically, what it amounted to (he surmised) was that Microsoft was paranoid about being accused of misappropriating GPL software into their products. Sort of the "1% Doctrine" of software licensing . This was about 4 or 5 years ago now. I don't know whether it's still true.

Well it might have had to do with the fact that they misappropriated the BSD socket implementation when they wrote the TCP/IP socket library for Windows NT. As silly as it sounds considering that socket library was under the BSD license, they simply "forgot" to follow just about the only requirement that the BSD license asks for, namely to mention in the docs about the software origins.

That they might be a bit paranoid about GPL I could understand. After all I'm sure the FSF wouldn't stay silent when they had reasonable suspicion that MS violated their license. But the whole idea about being contaminated just by having seen code under a certain license is rather something that MS promoted themself indirectly in the first place through thier shared source license.

Rolf Kalbermatter

QUOTE(Eugen Graf @ Jun 14 2007, 02:56 PM)

Yes, you are right, ActiveX is windows specific interface. Can you tell me how I can build in a LV element(e.g. controls) in other programms using DLL?

Eugen

To cut it even shorter you can't really. LabVIEW controls are just that: LabVIEW controls. As far as Windows is concerned they are just a few graphic lines inside a LabVIEW window. The closest you can get is embedding a LabVIEW front panel inside another Windows window, ActiveX or not. And that has some very tricky implications, one of them being message queue thread starving if you don't do it exactly right.

Basically I would not think it worth the trouble to try it and yes I did attempt this a few years back, but with newer LabVIEW versions I would not expect this to having gotten easier, rather the opposite.

Rolf Kalbermatter

QUOTE(njkirchner @ Jun 16 2007, 07:04 PM)

I can't say for certain, but it's most likely to match up w/ a quirk in the core of the picture control. I'm sorry I came up on this thread late, but I have a simple radar sweep program I'll try to dig out for y'all

it uses the picture control

It's not a quirk. It's a convention. The picture control expects 16bit aligned scan lines. Windows bitmaps expect 32bit aligned scan lines. This is called padding and as with anything about bitmap formats these are simply conventions used for some simplification/speed up of certain operations. For nowadays computers this probably doesn't really make any big difference anymore but it could have a big impact a few years ago.

Rolf Kalbermatter

QUOTE(Karissap @ Jun 12 2007, 11:07 PM)

Otherwise, it is faster to write the algorithm in something like C, and call the dll in LabVIEW. See http://forums.lavag.org/index.php?showtopic=3291' target="_blank">this thread

This statement is wrong in more than one way.

First LabVIEW does not necessarily have to be significantly slower than C. It will never be faster provided you use comparable algorithmes but much slower is a statement that holds simply not true for many algorithmes.

I've done bitmap import and export back in ~94 completely in LabVIEW including supporting simple compression schemes such as RLE etc and the routines where actually faster than calling Windows 3.1 16 bit APIs for doing the same.

The problem in LabVIEW is almost always not that it is in itself slow but that it is so easy to come up with a terrible algorithme that usually seems to do what you want but with a bad performance. Doing the same in C you do need to have a good understanding of what you want to do, how you are going to do it and how the C compiler will deal with certain thngs in your code. All this is most often absent when I see someone implementing an algorithme in LabVIEW and complaining afterwards about its performance.

Also it is wrong in that writing an algortihme in C is never going to be faster than doing it in LabVIEW. It's runtime performance can be and does sometimes be significantly faster but the implementation is definitely a different thing. Of course assuming that you know both LabVIEW and C equelly well.

Rolf Kalbermatter

QUOTE(crelf @ Jun 14 2007, 02:08 PM)

I share your jubilation, but with a little more temperance: I've been asked a number of times about a Windows to Linux migration, but when I've pressed the customer as to why, the reply is usually one of the following:

• I don't know why, but I've heard that Linux is cool!
  
• I use Linux at home, and if you do the migration management will be forced to look at Linux more closely
  
• Linux is cool because <insert a list of cool features here that are completely irrelevant to the project at hand>
  

These type of projects are invariably squashed.

I have had one other reason in the past for a huge Datalogger application I had developed for them:

We use Linux for just about anything else in our automation departement except for desktop PCs in adminstration.

But even that didn't get the project finally ported as the application had to be installed on notebooks and the low budget notebooks they used back then were not very well supported by Linux. Just for clarification this was back when LabVIEW 6.0 and 6.1 were still the actual development version. Nowadays I'm sure it would be almost a no brainer to do, but after some 6 or 7 years of being used to Windows it's not likely they will want to change to Linux that fast anymore for that application.

Rolf Kalbermatter

QUOTE(ragglefrock @ Jun 14 2007, 11:28 PM)

I agree with that in principle, but I don't think the default value created by the VI with an unwired terminal would be a constant value. Maybe copied from a constant, but not a constant itself. Here I'm just guessing, but it's the basis of my original answer.

I'm pretty much sure you are right here. Wouldn't make sense trying to use a constant value directly as default input value instead of allocating the necessary memory space and initializing it accordingly. As such it could of course have a serious impact if the controls default data was not one of LabVIEWs default default data but rather an 100 MB data array.

Rolf Kalbermatter

QUOTE(Eugen Graf @ Jun 14 2007, 04:56 PM)

Have anybody work with WDM ? It's possible to create a driver for capturing video devices and use this in LV?

My collegue created an ActiveX (ocx) with Borland C++ and I use it succesfully in LV, but I want to create my own driver without using ActiveX.

I haven't exactly done this but it is not impossible. A WDM driver is however a driver that uses an object oriented architecture. Not something you could directly access in LabVIEW. Also a WDM driver runs in the context of the Windows kernel.

What this all means is you will have to write a user space DLL, that does access the WDM driver and provides a standard C API to be called by LabVIEW.

Rolf Kalbermatter

QUOTE(PaulG. @ Jun 12 2007, 08:30 AM)

BASIC is a sentimental favorite of mine. I learned it years ago on my Commodore Vic 20. I knew I loved to program ... but was stuck in the world of hardware engineering. Then I discovered LV in '96. :thumbup: Now I can do both.

Ohh those good old days with my C64. But then I didn't really do much with it's Basic. Was learning Pascal for my vocational education and didn't feel Basic could keep up with it. Even dabbled into C64 assembly for a short amount to try to do the really funny things, but my younger brother was way better at that.

Later did a Turbo Pascal program during an internship and immediately after that got exposed to LabVIEW in 1992 and felt at easy with it the first instant. Even did at some point rewrite in LabVIEW the app I had done for the most part of my 4 months internship in something like half a day. Of course it had been an app reading in acquired data from binary disk files and displaying them in a wafeform graph. Doing that in Turbo Pascal had been a major thing to do as I had to write the code to draw a complete waveform graph on screen and then rewrite it to a plotter in HPGL. Ok I didn't do the HPGL part in LabVIEW :-) at all. Printing out the front panel was good enough.

Rolf Kalbermatter

QUOTE(crelf @ Jun 12 2007, 08:09 AM)

I agree, but I'd like to know whether it is nanoseconds, as you suggest...

Will with nowadays MultiGigaHz CPUs it is definitely more in the order of a few 100 ns than many us.

Rolf Kalbermatter

QUOTE(dbyers3 @ Jun 12 2007, 09:08 AM)

Disreguard,... My other test machines work fine on this code. Just one machine doesn't. Probably screwedup gov OS. :worship:

Could be a policy setting disallowing the change of the desktop background. Window policy editor does allow a myriad of settings being changed, that control such things as this.

Rolf Kalbermatter