Rolf Kalbermatter

in my program, i do use some property node, but none in the program using the "draw text in rec.vi".

and i didnt change this part of program, why cannt i build this time?

and my purpose to use the "draw text in rec.vi" is show some words in my picture.

I think in your case the second part of the message is the important part. For some reasons your VI has lost its diagram. Maybe you did set something wrong during the last build and the original VI was overwritten by the one build by the application builder which usually has no diagrams.

I would do a reinstall of LabVIEW to get the vi.lib VIs back into original state.

Rolf Kalbermatter

I had a quick look and didn't see anything in the license manager for this. Where did you find it?

The license manager is very stupid. It only enumerates the license files present in your system and shows their status. It also can invoke the activation wizard for a specific license so that you can get a valid license. All the license files present in your system (such as the whole bunch of possible LabVIEW development licenses or the NIIMAQ1394) get installed with the respective NI software either with demo or inactive status. The license activation then gets an autorization code from NI (either by secure web, fax or email) and adds that autorization to the existing license file, signing the whole file with a code to proof that it is a valid license. Then the license manager will recognize it and so will LabVIEW. But LabVIEW checks also for other valid licenses for which no standard license file gets installed together with LabVIEW. Those queries will fail just as if the license file had not been activated or properly signed and the feature will not be available.

Things I found that it checks for licenses are LabVIEW Scripting, XNode Development, Pocket PC, and Palm OS.

So now we just need to get those valid licenses to use these features ;-) Knowing that the whole licensing is based on FlexLM I have a feeling that you could force it without to much of a hassle but that would be illegal!

Rolf Kalbermatter

Has anyone attempted a hack of the license to find out if that may release the scripting?

If I would, I wouldn't tell! I like to sleep without being lifted off my bed in the middle of a night by a special police force ;-)

Rolf Kalbermatter

Has anyone experience connecting Yokogawa MX100 and LabVIEW ?

I have this problem...

I have got the LabVIEW driver from Yokogawa website and than started to built the LabVIEW program to take the data from MX100.

This MX100 has the capability to measure in 10 ms interval rate. Using I tried to make a loop with 10 ms period. And than I tried to change the coltage rapidly. But it seems the LabVIEW Program only can detect voltage change every 100 ms. I have used Yokogawa program and it worked.

But using Labview I can have other possibility to modify the program as I want.

So, if anyone has such experience , please please tell me...

I have been stucked in this problem for last days

Thanks in advanced.

The way the Yokagawa MX100 driver is constructed it may be almost impossible to get 10 ms update rates. They read in multiple times huge amounts of data for configuration, scaling and such both for the system and module level and write all that data back to the device too. I only managed to get everything working reasonably fast by diving deep in the driver and take it apart to optimize the number of buffer read and writes. However I'm only doing analog input here, so I couldn't specifically help you with your output problem and the code I have is not specifically neat or clean but just functional and very specific for the datalog problem I had at hand. Took me a day or so to understand the structure of the driver a bit and another day to get it working.

Rolf Kalbermatter

I'm trying to enter a tree control in an array, and I want the contents of each "tree" in the array to be different. However, whenever I add a string to the tree in one array cell, it shows up in the trees in all other array cells. Is there any way to "decouple" these trees?

I think an array of trees to be a bad UI solution. Aside of that it won't work in LabVIEW as you would like. A LabVIEW array element can only have different data for the individual elements in the array but shares all the attributes for every element. The data in a tree control is the tag of the currently selected node but the tree representation is really all constructed from attributes of the tree control and therefore will be the same for all array elements. But as said above I think you are trying to create an UI solution which will be anything than easy to understand for a potential user anyhow, so you really should reconsider your approach.

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