Rolf Kalbermatter

Damian

I take a while to do what? Computing the hierarchy for the 200 VIs or displaying the items in the tree?

It should not take you long to compute a VI hierarchy for just 200 VIs. Your algorithm might be improvable (search on the web and NI website for possible faster algorithm)

If it take too long to update the tree, you can use the defer panel update before you start updating the tree, this will speed thinks up significantly.

In regards to GetVIHierarchySiganture and GetVIHierarchyUserGUID, I never tried these, so I cant help here

PJM

It's just a guess but I have a feeling that the GetVIHierarchy... functions compute a signature of the entire hierarchy such that any changes to any VI in the hierarchy will likely result in a change of the VI hierarchy signature so that a tool can decide if some extra action such as saving (or maybe recompiling) needs to be done. I believe to remember that the signature is supposed to track almost any change to any VI in the hierarchy while the the GUID method is rather meant to only change on real user mods on any VI in the hierarchy.

Rolf Kalbermatter

Hi Jim,

I use LVDiff -- it only facilitates in comparing the two VIs by highlighting the differences. We cannot merge changes from one VI into another, like we can with text files (C/C++, for instance). Merging VIs automatically would be quite involved.

I work on and off on a few CVS managed projects including Wine and OpenG and even for text based programming merging is often not seamless. If you happen to have (even cosmetic changes) in the neighbourhood of changes made to the repository you end up with conflicts you have to merge manually too. As such the manual merging required with lvdiff isn't actually that much worse.

I like the check-in/check-out paradigm because my team mate then knows I am working on it. And he can either wait for me, or come talk to me. In update/commit, I am guessing we would end up manually merging changes from one into another.

I guess it all boils down to personal preference.. and/or company policy.

If your mate is working down the aisle this may be an interesting work model but with distributed development as is used in most Open Source projects this is not a good solution. And once you get used to the update/commit model the checkout/checkin model doesn't look that attractive anymore. And yes it is a big question of personal preference (and sometimes company policy) although real developers tend to ignore company policies quite easily for all kinds of reasons, even artificial ones ;-)

Rolf Kalbermatter

I've always respected your writings Rolf, but here you are missing the point. I agree with what you say about CompactRIO, fine product, works great, etc. I don't (didn't) have an external event that I wanted an NI generic solution. I have had multiple instances where companies I worked for (and two clients since becoming an independent integrator) had a need for a new, custom I/O card that no one made, anywhere. Specialized needs/applications, etc. CompactRIO did not exist then and would not have even remotely worked for any of these applications even if it had. What was needed, and built, was a custom card, initially ISA on the first app, then VME on the next, then PCI on the last two. Each one needed realtime response. I, or coworkers, ended up writing Ring 0 VxDs, then DLLs, then LabVIEW code, etc, to work everything out. I would have liked to have done everything in LabVIEW. I agree that trying to do this in the application layer is a rats nest nightmare. Thats not what I want(ed). I wanted to be able to write the proper device driver layers all in LabVIEW, including having the Kernel level (Ring 0 in old terms) ISR in LabVIEW. This is not race conditions, or other nasties, it has been done in C and other languages for decades. It WAS done in LabVIEW with the Harris NightHawk, but was not available on the PC or Mac architectures, ie something affordable, and it could have been. This still could be on QNX or Linux or OSX or even Windoze with one of the RT extensions, but that doesn't sell NI hardware does it. I first asked for this over 10 years ago and I know several other people who have also asked for it.

I think this is not really an option. You have worked with the DDK as you describe the situation or at least someone has done this for you so you should know how it is structured. Support for the DDK interface in LabVIEW is simply not a viable solution. All DDK binaries, import libraries, header files and other tools assume that the according software part is written in C and in certain situations even assembler. Creating bindings to access all this functionality from within the LabVIEW environment would be a project probably just as big as the whole NI-DAQ software or even bigger. Not to mention that LabVIEW is an application and Windows does not have any support for allowing applications to access Ring 0 functionality directly. I have no idea how this problem was solved with the Harris system but I suspect that it was far from a generic device driver interface which was directly available in LabVIEW but instead some (Harris developed) helper device driver which could be accessed from LabVIEW and which did translate between the kernel level and the LabVIEW application level a few things such as memory copies and probably translating interrupts into LabVIEW occurrences and such. As the Harris hardware was a closely controlled hardware and software platform with only a few parties if more than one at all involved in hardware, OS and device driver design it is probably a managable task to develop such a translation device driver. For a system such as a PC with its thousends and thousends of hardware and software manufacturers such a driver would always fail at least 50% of the possible target applications and with that is doomed to be a project that would cost way to much, not be applicable in a lot of potential cases and with that never gain enough momentum to ever possibly pay even a small amount of its development cost.

Writing device drivers is a pain in the ###### to do, but it is quite likely a lot cheaper than whatever such a generic device driver interface in LabVIEW would need to cost to pay for its development.

One possible option though which is not doing everything in LabVIEW but comes as close to it as it can come, would be to use the VISA interface to access a PCI hardware directly. It still will require you to know about your PCI interface everything you would need to know to develop the device driver as a kernel device driver and of course also quite some study of the direct hardware access interface in VISA but you could basically stay completely in LabVIEW to do this. It won't be able to reach the same performance as a kernel device driver optimized for your hardware but it is probably the easist and best solution if you don't want to deal with the Windows DDK at all. This option by the way has been in VISA since at least VISA 3.0.

Rolf Kalbermatter

Dear all,

I have developed an application and made a .exe (LV - 7.1 PDS)+ installer, the OS is Win XP. I have an ARM processor with WinCE OS running on it. Will my LabVIEW application run on it. Can I install the runtime engine in first case???

A normal LabVIEW application definitly and for sure will NOT run on an ARM Win CE system. LabVIEW is a compiler and creates machine code for the target CPU, for normal LabVIEW for Windows this is the i386 machine code. The ARM processor doesn't know what to do with those opcodes and Windows CE accordingly will refuse to load and start that executable. Theoretically the LabVIEW PDA mopdule for Pocket PC could support Windows CE, as Pocket PC is a newer version of Windows CE, but I have my doubts about if that really will work as there are differences between Pocket PC and Windows CE too.

Rolf Kalbermatter

I wouldn

I heared about the possibility to use LV controls (such as graphs) in other languages (such as Visual Basic) using ActiveX (without using Measurement Studio)

Do anybody know how can I do that?

Thanks

This can't work as you describe it. LabVIEW controls are almost all implemented in a LabVIEW native format and can't be accessed through ActiveX. You can however buy ComponentWorks from NI which supports similar control elements than what you have in LabVIEW. Another option is to put your VIs with the Application Builder into a DLL and call them as functions in your other language. This will however still display the entire front panel as a separate window and not as a control on the window surface of your foreign application.

Rolf Kalbermatter

Hey there,

I got the problem that I need to "send" image data (format bmp, jpg, tif, ...) to the graphics adapter to the VGA-port for example with a Laptop.

To the VGA-port a kind of small "beamer" is connected and I need to see only the file I send there and not the whole screen (Desktop). The Desktop remains visible on the laptop monitor.

As the VGA-port is not treated like the other communication ports (RS232, GPIB, ethernet, usb..) I did not find any example and I suppose it wont be that easy to realize.

Windows does not support accessing the video interface directly from an application. You will have to use windows (as the name of the OS suggests :-)

Seriously, forget about going to do what you want in the way you describe. Instead configure your notebook display adapter to split the desktop into two monitors, one on the built in display and the other on the external VGA interface. If you notebook graphics adapter does not support this your options are gone. You will need a notbook whose graphics adapter can control the external VGA port as a separate monitor.

Now in LabVIEW execute the "App.Display.All Monitors" property node. The first cluster in the array should be your primary display and the second one (and more if any) are your secondary display(s).

Now create a VI on which you display your image in a picture control and change its desktop position to values inside the rectangle returned in the second array element of the "App.Display.All Monitors" property node.

Rolf Kalbermatter

Hmm, I'm always one to appreciate more power. Could you give a few more details on specific items/capabilities you feel LabVIEW does not yet support that you see in other languages?

One that I have always wanted was to be able to hook a VI to run on a specific hardware interrupt, ie to use the VI as an interrupt handler. Yes, there are work arounds here, and I have used them, such as writing a VXD and having it set a LabVIEW occurence, but I am talking about real, preemptive INT handling.

There was a LabVIEW system on Concurrent/Harris NightHawk and PowerHawk computers years ago. NI worked with Concurrent to make a modified LabVIEW realtime version that did true preemption, but it was pricey and only ran on the Harris CPUs.

For companies that do a lot of hardware work this would be great.

Hmm, with the new CompactRIO you can bascially get even better reaction on external events then you ever could get with any preemtive multitasking or whatever OS solution. And with its price it really beats any potential specialized hardware/OS platform who might be able to support such a feature. Preemptive real interrupt handling in the user application level is something any non-specialized (aka very expensive RT OS) can't handle without throwing the whole system into a miriad of race conditions and other nastities.

Rolf Kalbermatter

Hi, the following figure shows that difference, when I flatten a constant (32-bit Integer),the type string is same as the document detailed. but, I change it to Control, the type string is also changed! I don't understand the othen data. I can not find help with NI document. What is meaning of this data?

Thanks.

There is a data type format documentation PDF file from NI explaining it all. Basically the label (if any) is part of the type string. In your case I would think you labeled the control or constant as "Numeric 2" while the other is simply unlabeled (quite typical for constants). The first int16 defines the number of bytes in the "type string" and is of course different to account for the additional bytes for the label and the difference in the second is in the high order byte which is according to NI not documented. In reality it contains flags about the control such as if it is a control or an indicator and several other internal flags you won't need to know.

Rolf Kalbermatter

Has anyone ever seen this error upon start-up in LabVIEW 6.1.1?

"Error 6 error creating temporary LVSB resource"

This just started occuring on a machine with XP Pro SP2 operating system. The strange part is that for admistrator accounts logged in on the "university campus domain" LabVIEW starts without a hitch. For Users logged into the Local computer domain Labview displays the preceding error then shuts down.

The access priveleges menu is missing under the properties for Labview6i.exe.

A re-install of Labview did not solve this issue.

Thanks in advance for your assistance

When LabVIEW loads any VIs containing CINs or sometimes also other files, it extracts certain file components such as the CIN code resource from the VI and writes it in the temporary folder to load it from there. Obvious solution would be to adjust the temporary folder setting for the affected users to point to a directory they have write access to or probably less easy, change the standard temporary folder access rights to allow those users write access to it.

Rolf Kalbermatter

Perhaps I missed a discussion somewhere - has there been an announcement from NI about formally supporting scripting and a licensing scheme for its use? I'm not doubting you, of all the people on LAVA or Info-LV (outside of NI) you would probably know.

David,

No official announcement has been made. But Brian seems to have talked to someone from NI who did confirm my suspisions. I for myself have come to that conclusion after having searched for the new INI key to enable scripting but I instead came across some routines that also control the other licensing in LabVIEW.

Rolf Kalbermatter

Dear LVers,

I am seaching for a way to implement a ActiveX dll with structures in LabVIEW.

When I try to call a method with the Invoke Node functionality in LabVIEW the function name

is visible (grayed) but not selectable ...

I know, we could write a wrapper, but I hope there is any other solution.

I'm afraid not. ActiveX does not support marshalling arbitrary structure data. Since LabVIEW does completely rely on the COM infrastructure to setup and configure ActiveX nodes correctly according to the information in the type library it can't create the correct type mapping due to lack of support for defining structure types in the underlaying COM architecture. .Net seems to have support for structure definitions but that is of little help here.

Rolf Kalbermatter

I don't have much insight but that sounds like a pretty practical idea to have an inventory system.

Have you talked w/ NI about this? I wonder what those ModInst VI's are actually for, because it doesn't make sense that they wouldn't find your hardware if that's what they were for. Obviously whatever MAX uses to enumerate the hardware devices would get you the info you're looking for and it's a question of whether or not those enumeration functions are available in LabVIEW through some interface.

I don't have the ModInst files handy at the moment but it might be interesting if they use some DLL's (from MAX or something)... to see if the DLL's have other functions that might do what you want.

MAX uses a COM like infrastructure to enumerate those devices. Each type of hardware interface has a DLL implementing a resource enumerator and property manager of some sort. This DLL knows how to invoke the low level interface specifiek enumerator functions of the respective interface library, which are different for every interface.

The enumeration interface for the old NI-DAQ for instance was accessible through the DLL nicfq32.dll and its LabVIEW implementation was inside the NI-DAQ channel viewer support library in project/_res.llb in LabVIEW 6.1 and earlier. Of course password protected and as such almost useless.

Rolf Kalbermatter

I see the same thing. This behaviour does not happen if 'Read Lines' is not checked...

Probably a bug caused by the "agressive optimization" added to LabVIEW 8 according to some marketing hype I remember to have heard of. I would rather not have an utterly optimized LabVIEW compiler but a reliable one instead.

Rolf Kalbermatter

Hi there everyone,

First posting, so here goes...

Does anyone know if there's a workaround the normal "Call Library Function" such that you can pass in a path/string to the .dll file you want to call, instead of it being fixed in the Properties page at design time?

I've a need to read a customer specific path from a registry key (which I can do no problems), and then call a standard set of functions in a .dll file this the key points to. The function names can be specified at design time in the properies page.

The reason behind the required is that there will be a number of these keys all pointing to "different" .dlls. All of which have the same functions/data types, although they do different things going on behind the scenes. Obviously, all of the dll's (should) have been written to the same function/parameter standards, so there should be no problem in interfacing to different copies of the "same" thing.

Well with the much talked about scripting there is a way to change the path, but there is a big BUT or better two. You can only invoke scripting operations on VIs which are in edit mode so your VI containing the Call Library Node would need to be loaded dynamically, you would have to walk the VI object tree for the Call Library Node primitive change its path and then reopen it as strict type def again dynamically to invoke it with the Call by Reference Node. All in all a lot of work and in LAbVIEW 8 scripting is not available anymore without a license for this feature.

Rolf Kalbermatter

That document has been deleted. What it said? It's possible to use remote panels with Mozilla the same that with Netscape?

Saludos,

Aitor

If you check on the NI site for "remote Mozilla"you will find a number of articles. Yes Mozilla works the same as Netscape, but Firefox seems to be a differnt story. Not sure if LabVIEW 8 fixes that and has support for Firefox but earlier LabVIEW versions seem not to have support for Firefox for some obscure reasons. I would have expected Firefox to have the same plugin interface than Mozilla but that isn't so apparently.

Rolf Kalbermatter

Can I run NI OPC Server on realtime systems? I am would like to run Modbus TCPIP on a realtime system without a remote windows PC.

What are my options??

OPC probably never will run on real time. OPC is based on OLE and that is a huge system to add to a real time environment. As such it is probably not possible to create an OLE system that would not throw off any real time determinsme from the system. Also OLE is a closely protected core technology of Windows and Microsoft won't give out the source code just to anyone to port it to a competitive real time environment, even if porting it to a real time environment would technically be possible, what I highly doubt.

So your options are actually to go with a completely VI based ModBus library. There are several Alliance Members that sell VI based ModBus libraries and NI recently developed one based on the ModVIEW library from CIT Engineering where I work. I'm not sure what NIs plans and conditions are for this library but you can also checkout http://www.citengineering.com/pagesEN/products/modbus.aspx.

Rolf Kalbermatter

Further Additions:

I've found the following phrase on internet:

"Furthermore INPROC COM objects are not listed among the exports, as pointers to

their exported functions are returned by the factory objects."

that probably is why I can't see the functions in labview.

Also in "Dependancy Walker" software I can't see the functions that I need.

Now the question is: How can I handle Inproc COM Objects with Labview?

Is it possible to use a C++ compiler to connect to this DLL and to be recompiled

as Labview friendly DLL? Can someone give me directions?

This DLL is a COM DLL and therefore does not export functions to call directly. As such the Call Library Node won't work. If the DLL contains a so called type library or at least is installed with a type library you have a chance to use the Active X interface in LabVIEW.

However Active X comes in two flavours. One are Active X Controls which provide some form of user interface and can be inserted in the Active X Container in LabVIEW. The other flavour are Automation Objects without any UI component and they can not be put in an Active X container. Instead you place an Active X refnum on the front panel and then browse from there to the actual object you want to use. Then you wire that refnum to the Open Automation Refnum function which calls the OLE function to instantiate the desired object through the DLL proviced object factory in DllGetClassObject().

Once Open Automation Refnum returns successfully you should be able to wire it to the Property Node or Method Node to select the approriate property to access or method to execute. Don't forget to close the refnum at the end with Close Refnum to avoid memory leaks.

Rolf Kalbermatter

So if I understand, you can create scripting tools in 7.1 and open a copy in 8.0 and it will work, but you cannot create new scripting tools or modify them in 8.0?

I was looking into this lately and the scripting seems to be another feature which is put behind the new licensing scheme (together with XNodeDevelopment it seems). So there are really only two ways to get scripting in LabVIEW 8.0. The first is to get a license from NI to do that and activate it in the license manager, and the second would be illegal.

Rolf Kalbermatter

I've updated all the links to Jim's new posted location. It should work now. BTW, I used Firefox default download system and it worked the first time, perfectly. :thumbup:

Yep, Firefox download worked well too. Wouldn't ever have tried the same with IE though. Even 50MB files used to be a one out of ten chance to work.

Rolf Kalbermatter

It worked fine for me on the first try. I guess you already primed it for me huh? :thumbup:

I guess the drivers portion is not included with the download eh? It prompted me for it. BUT, this time, the installer doesn't abort the installation if the driver CD is missing. Unlike 7.1 which uninstalled everything if you didn't have the driver CD.

It doesn't seem to work overseas. Whatever serial number I could come up with from all the different SSP shipments etc. it kept telling me that it is an invalid serial number for the product I try to activate. NI support wasn't very clear but claimed that it doesn't work yet and I should just continue to use evaluation mode until I receive the proper SSP shipment. But that dialog at startup is for sure annoying.

Rolf Kalbermatter

Problem solved! (sort of)

Loaded VISA on the slave computer and now it works.

This prompts the question, Why doesn't the installer bundle up VISA?

Because in all LabVIEW versions up to 7.1 the application builder has no possibility to add VISA or any other IO library installer such as NI-DAQ, NI-488, etc. They all do come with the apropriate hardware or can be downloaed from the NI site or copied from the Device Driver CD-ROM. In the case of VISA or even worse NI-DAQ it is not very likely, that everybody would want his installer bloated with 100ds of MBs of driver installation, which someone might have to reinstall anyhow because there has been a new driver version released since you built your app.

Rolf Kalbermatter

I was wondering if anyone has had any experience yet with LV8 being installed on a machine co-existent with previous versions of LV. Since now that LV8 will seemingly have better project orientation and structure, how will that effect currently organized projects in other versions, particularly while coexistent on the same computer? Are there any discovered "gotcha's"?

In other words, can we expect LV8 to play nice with its older siblings in the same house, so to speak...

Yet another concern is for coexistent add-on tools and tool-kits, libraries, modules (e.g. vision, motion, DAQ, etc.).

This is not really a question about upgrading LV, (NI details published in "Upgrade Notes"), but rather a concern regarding coexistence during a methodical or slow migration (or in some cases, perhaps no migration).

Any early thoughts, comments, concerns, or suggestions?

Thanks,

Kevin Thompson

LabVIEW itself has been always a nice citizen as far as undesired interaction with other installations on the same machine is concerned. I do not expect any difference with LabVIEW 8 unless the packagers at NI somehow messed up and built a bug in the installer.

With add-on toolkits it is sometimes a different story. All native LabVIEW add-on toolkits should be fine but others such as IMAQ can be a bit problematic in certain cases. You may sometimes need to install certain bug fixes and definitely allow the Toolkit installer to also install compatibility VIs for older LabVIEW version into their respective directory.

With drivers you have to be carefull to allow the driver installation (for instance NI-DAQ) to upgrade the (DAQ) VIs in the older LabVIEW systems, to sometimes allow them to continue to work with the new driver.

These last two points where a Toolkit or driver for LabVIEW version X may also include VI libraries for LabVIEW version X-1,2,.. installations requires however that the older LabVIEW version is already installed on the system. Installing older versions of LabVIEW after newer versions is not a very good idea.

Rolf Kalbermatter

I can hardly imagine a program that is not wider or taller than my screen. Only the loading in saving of the variables take together more than the screen. And the terminals (I dont use terminals in the code, only variables ( for better overview)) plus the initialisation with the property nodes take nearly a 2nd screen.

But thanks for advise, I will try to get rid of code using subVI's, So I have to make a lot more of my variables global.

The solution to this are subVIs and state machines and in my case also LV 2 style globals to encapsulate specific data and its operation on them. With this you can always get diagrams that fit onto a 1024*756 screens. My LabVIEW programs involving sometimes 800 and more VIs of all sorts of complexity seldom go over this margin and if they do it is only about the outer case or loop structure on one or two sides but never real code.

An no, this does not require globals at all. I only use globals for some simple status variables such as a global application abort and application constants but never for other data variables. If I have to grade a diagram made by someone else, any globals other than simple booleans, or application constants automatically give negative points. So does not using state machines for user interface handling or not using subVIs. (and spaghetti code also scores high in my negative list).

Rolf Kalbermatter

Now, I work on a user interface. I have created a runtime menu for the job. The follow job is that create a tool bar for some sub-menus in common use. LV can do this?

Using Axtivex, I have created a windows toolbar, but the toolbar can't relate to the runtime menu.

So I want to know a method that can create toolbar related to runtime menu like Visual C++.

Thanks a lot!

There is no native toolbar functionality built into LabVIEW yet. You will have to create the toolbar by adding small customized buttons to the upper border of your front panel and adding event support in your event handler for each of those buttons to trigger the corresponding action in your UI state machine.

Rolf Kalbermattet