Rolf Kalbermatter

QUOTE(Aristos Queue @ Jun 1 2007, 09:41 AM)

We are not using any intermediate language.

At least not yet . And probably never for the already existing platforms.

Rolf Kalbermatter

QUOTE(Ulrich @ Mar 8 2007, 09:52 AM)

Hi,

my colleague always laughs at LabVIEW. He says that I'm just painting pictures similar to powerpoint foils. He prefers HP Basic where he is "close to the hardware".

I'm glad that LabVIEW is close to the hardware so if have time to program the important things

Ouch! HP Basic! I thought that is dead for a long time. I have never been a fan of any Basic, but HP Basic was definitely not the best one I've seen.

Rolf Kalbermatter

QUOTE(LV Punk @ May 29 2007, 06:23 AM)

Every time I see LabVIEW discussed in the world at large, I get all tingley

It pops up most often when discussing parallel programming difficulties. Also, the people discussing it know how to write it out properly (LabVIEW)!

http://developers.slashdot.org/article.pl?sid=07/05/29/0058246' target="_blank">http://developers.slashdot.org/article.pl?...7/05/29/0058246

There will be always people liking something and others not. Heck give me VB and I start to bitch just as bad as one or two of those comments (and I obviously don't agree with them about LabVIEW).

While some comments about LabVIEW have a point or two that is valid, it is mostly just opinions. But then that is what /. is mostly about. And the rest goes about how hard it is to get parallelisme in procedural languages. Not a big surprise to anyone.

Rolf Kalbermatter

QUOTE(Aristos Queue @ Jun 4 2007, 05:46 PM)

With a while loop, it gets reallocated on each iteration to grow as needed.

Actually I think LabVIEW is smarter than that! If I remember correctly LabVIEW is reallocating the output array on While Loops in 2^x steps, meaning it doubles the array size each time it gets to small and resizes it one last time at the end.

Otherwise a While Loop with auto-indexing would have little or no advantage over one with a Build Array primitive inside.

QUOTE(eaolson @ Jun 5 2007, 03:48 PM)

This is mainly about memory consumption. The earlier example won't really make any difference here as they both will require a complete buffer for the floating point array and integer array at the same time. But if you have a loop that produces somehow lets say a double precision number (the random generator) and you want to have an integer instead, converting inside the loop will only use 8 bytes + the output integer array while converting it outside will first generate a complete double precision array before converting it to an integer array. This is not so much about execution speed, probably only a little difference, as more about memory consumption.

Rolf Kalbermatter

QUOTE(Aristos Queue @ Jun 10 2007, 10:58 PM)

No. I'm not sure why Rolf thinks the assembly code isn't in there somewhere. The assembly code for all the VIs is definitely in the EXE. The initial code is going to start the EXE, and then start executing "clumps" of assembly as they become available to the thread scheduler (the top-level VI schedules its initial clumps to run... as each clump's inputs become available, they join the list of clumps that can get executed). LV doesn't have a call stack for subroutines -- just the scheduler picking up a clump, executing it, then scheduling the next batch of clumps. Anyway, the long and short of it, there is assembly code in there for the VIs. I don't know why you're not seeing it.

This is probably the sort of information that you're not supposed to know -- because you're not supposed to be reverse engineering the assembly according to the license agreement -- but I figured I'd tell you because I don't want some rumor to start up that LV is somehow an intermediate interpreted language like JAVA. That sort of nonsense would just contribute to perceptions -- right or wrong -- of LV as not a real language and too slow for real work. LabVIEW is a compiled language.

Of course the machine code (not assembl(y)er code as that is what a disassembler will create or an assembler will use to generate the machine code!) is there but inside the VI that is inside the LLB and that is somewhere inside the executable. Any disassembler I know of will only find code that is located in segements specifically marked as code segments. And its disassembly starts at the normal executable entry point and goes from there. Code embedded in some ways in the resources or as in LabVIEW in some proprietary binary structures won't be found at all. So the output from disassembling a LabVIEW executable only shows the startup stub that launches the LabVIEW runtime library. Only the LabVIEW development environment (well not in 8.2 anymore it seems) and runtime system knows how to locate the VIs inside the executable and from there extract the machine code embedded in there.

QUOTE(Ben @ Jun 11 2007, 07:41 AM)

Well, as has been pointed out already, for required inputs the subVI won't need to check if the input was wired and provide a replacement default value if it wasn't, since it can savely assume that there is a value at all times (otherwise the VI couldn't have been called obviously). So I guess it is this little extra code that makes the difference in execution time and probably will also result in a few bytes less machine code for required inputs.

And no, making non-required inputs required just for the purpose of saving a few nanoseconds execution time won't be a useful thing to do as the convinience of not having to wire an input if it is usually not necessary makes a lot of sense to me.

Rolf Kalbermatter

QUOTE(yen @ Jun 11 2007, 02:36 PM)

Setting the FP.State property to Hidden should NOT minimize the window. It should make it disappear immediately. If you're still seeing a button in the taskbar, that's because LV creates a second window by default (if I remember correctly, it is precisely to keep the application open).

Not exactly! That second task bar button is a "hidden" window that serves internally in LabVIEW as message dispatcher to help LabVIEW with asynchronous operations and such. With Win32 this wouldn't strictly be necessary I guess as threading could solve that too, but this was implemented for Win3.1, as having windows message queues was the only way to achieve some sort of multitasking back then. Removing it would probably have all kinds of strange effects and require a lot of work to make LabVIEW behave in all aspects the same as it did, so nobody went that path so far.

To make that second task bar button disappear you can add the HideRootWindow=True key to you labview.ini and all your executable ini files.

As to the OP question, my splash screens simply terminate AFTER they launched (Run) the main window AND made sure it's window was open, which the main window will do after having initialized everything.

Rolf Kalbermatter

QUOTE(Val Brown @ Jun 2 2007, 05:29 AM)

That's simply not my experience and, for that reason alone, I think it's important to NOT preclude access to serpdrv. Don't make it "easy" to use -- OK. Give preference to VISA in forums, etc -- OK. Don't support serpdrv -- OK, and nothing new. But what is the real reason that it has to be precluded?

If someone could answer THAT then I might rest a lot easier in this. But until then, I'm going to continue to be a small voice in support of continued choice -- even if it means knowing the back door means to use it.

As already mentioned it is old code in the LabVIEW source code together with a just as old external file. It won't be adapted in any way to support new platforms, the tools to create the old serpdrv file are long outdated (serpdrv being similar to an LSB in some ways), it is sooner or later going to break on OS revisions, does not support many features of serial ports (port enumeration etc.) and so on.

With the device manager in the Macintosh OS being completely different nowadays, the only reason to keep that code in LabVIEW is by now serpdrv. Nothing else can and will make use of it.

While the actual code in LabVIEW probably does not account for more than a few 10kB, it is always a good idea to keep an eye out on things that can be removed. As it is LabVIEW has mostly just continued to grow from a 4 MB executable in 5.1 to a more than 20MB executable already in 8.21.

While serial port communication isn't always trivial, fact is that VISA works very well for me in all applications that I have. If your code needs the old serpdrv to work correctly there is something wrong with it and you better start to schedule some time to look for a rewrite instead of waiting until it is breaking somehow, which will be always at a moment you have 20 other projects too that need to be finished yesterday.

Rolf Kalbermatter

QUOTE(karim @ Jun 10 2007, 04:53 PM)

i want to use example for read from serial port ,

but i need known what is the condition for correct reading(from 8051 serial port comm)

I would say the existence of a serial port is one of the most important "conditions". Not really something that is always there nowadays in modern computers.

Honestly, be a bit more specific about what you want to know. What do you want to do? What doesn't work if any and what have you tried so far?

Rolf Kalbermatter

QUOTE(Jim Kring @ Jun 7 2007, 11:02 PM)

Uh oh... it sounds like you just violated your license agreement

Sorry I'm lazy, but does the SOFTWARE also include executables created with LabVIEW or just LabVIEW itself?

QUOTE(Jeff Plotzke @ Jun 7 2007, 08:53 PM)

Your test shows most probably nothing. The only code your dissassembler can see is the startup stub that loads the LabVIEW runtime system and then passes the reference to the internal LLB to that. The machine code located in the VIs inside that LLB, can only be located and invoked by LabVIEW. There is no disassembler that could possibly know how to find the LLB, not to speak about the VIs inside it nor the LabVIEW generated machine code in each VI.

Basically every LabVIEW executable of a given LabVIEW version will give you exactly the same assembly code.

Rolf Kalbermatter

QUOTE(Wolfram @ May 29 2007, 10:01 AM)

Generating objects programmatically is a feature that is called scripting. This is a hidden feature

that can be enabled by a special LabVIEW.ini entry (reserved only for NI).

In LabVIEW 7.1.1 this feature can be made visible by adding the keyword "SuperPrivateScriptingFeatureVisible=True" in the LabVIEW.ini.

Have a look into the "rusty nails" -> "scripting" topic in this forum.

Unfortunately this keyword does not work any more. NI has changed this in LabVIEW 8.0

While this is all correct there is one extra caveat. You can not use scripting for changing VIs that are non idle. This means to do what the OP would want you would have to write a different VI that loads the VI to modify into memory, modifies it and only after all modifications are done, does start it. And whenever you want to change it again the VI needs to be stopped, modified and restarted. Basically not something I would ever consider to do.

Rolf Kalbermatter

QUOTE(george seifert @ May 21 2007, 02:43 PM)

I posted this as a reply on another thread, but maybe nobody saw it. I hope someone can help because I need to call a Perl script from LV.

I just tried LVPerl and get the following error "TCP Open Connection in Open Perl Connection.vi". The Open Perl Connection.vi says that the remote port must match Perl's. How do I know what port to use for Perl?

George

Well first some sort of perl server must be running. How this is done and where it is I do not know. It could be a special proxy server app or it could be a build in server in the Perl interpreter. What port it will use will depend on the server that provides that interface and unless you spcify this when starting up the server application (or in some ini file configuration) it will use a more or less application specific arbitrary default port.

So find out what will provide this TCP/IP server interface to your Perl environment (Active State Perl or maybe a Unix Perl?), find out its default port or define the one you want to use in the configuration or startup command, and make sure that application is already running when you try to connect to it.

Rolf Kalbermatter

QUOTE(PJM_labview @ Jan 15 2007, 03:42 PM)

I would argue that this is a bug. I have come to expect the behavior that Michael mentioned (fit as you drag) in LV 8.0x. If this this not a bug, then where was it documented that this was changed? I don't remember reading anything about it in the upgrades notes. If there are 2 possible behaviors, then I would expect to be able to access both programatically. In my opinion, resizing the windows content after you have finished resizing the Panel is the wrong behavior. I can not, on the top of my head, think on any applications that follow this behavior in windows.

PJM

I think I can see the logic about doing it the new way in order to avoid extensive UI redrawing during a window resize, but agree that the old behaviour was better. However it may have been a glitch in 8.0 because as far as I remember did earlier versions also not dynamically resize the front panel objects during window resize.

Unless I had only one control that needed to resize and nothing else that needed to move on the front panel I have always done this so far myself in the panel resize event case and that gives a very smooth effect, although I do need to test that this still works in LabVIEW 8.2.

Rolf Kalbermatter

QUOTE(Hieutq @ May 18 2007, 11:06 AM)

I used PDA Module 82. but Evaluation version. All application download to PDA can't use more 5 minute.

hix hix.

I'm doing a soft ues PDA Module.

Help me activate it.

hieutq@gmail.com

Thank all...

How about buying a license form NI?

Rolf Kalbermatter

QUOTE(Darren @ Apr 24 2007, 06:00 PM)

There are a couple of internal errors in LabVIEW called "DWarns" and "DAborts". You'll get that dialog on launch if a DWarn or a DAbort occurred on the previous run of LabVIEW. A DAbort is a crash, but a DWarn could be some internal error that LabVIEW logged, but LabVIEW was still able to continue operating normally. If you click the "Investigate Internal Error Now" option, you'll be taken to a webpage that will perform a search of the NI Support site to see if that internal error has any KnowledgeBase entries associated with it. Assuming your error does not, you can submit your log file to NI Tech Support, who sends all of these error reports on to LabVIEW R&D. If you can reproduce the DWarn/DAbort with some simple steps, it would also be helpful to submit a sample VI (if applicable) along with the error log.

Hope this clears up the issue, let me know if you still have any questions.

-D

In that respect just something that came up on Info-LabVIEW again. It would be useful to add to the error translation routine that handles file IO an explicit DWarn call when a "generic IO Error" gets generated. Not sure if DWarn can do that now but a complete stack trace with it would be fine too.

This would allow the LabVIEW R&D guys to possibly get a better feeling, which strange or obscure Windows API error resulted in a generic IO error. They are not likely to be very common errors, (or they would have been translated in a more useful error code) and the according log would give some better hints to the developers where to look for the cause of this error.

Of course there are other errors (for example network routines) that can end up in some sort of catch all unexpected errors into a single generic XXXX error.

Rolf Kalbermatter

QUOTE(TiT @ May 17 2007, 12:42 PM)

Hi,

Does it actually work if you build 2 EXEs and run them on the same PC

I've checked my LabVIEW options VI server settings... everything is enabled.

First "localhost" will NEVER be accepted, neither in LV code nor in EXE.

Then "+IP address" will be accepted but then no VI name will work... :headbang:

After a couple of lost hours I can't have a clear overview of such a basic thing... I really feel stupid, I guess there is a wrong setting somewhere else than in the VI... but where ?

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

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

If you want to run the two exes on the same computer you should not use the same IP port number. Only one application (and even thread) can open a specific IP port on a machine at the same time, so the second executable that starts up will fail to initialize a VI server instance if it is run on the same machine. Should probably still allow the second app to access the first app as client but otherwise around can't work as the second app has no properly initilialized VI server.

Rolf Kalbermatter

QUOTE(rkesmodel @ May 16 2007, 10:41 PM)

Dave,

Interesting link. However, the main problem that Paulo will have is that when LabVIEW accesses a flash drive it keeps a reference open to the drive until LV is completely shut down. There are several programs that will do this (even some MS ones). They will keep a reference open to the last drive they accessed. The only way I have found around this behaviour is to either shut down the offending program or access a different drive (do not know if this works w/LV). Aslo, many of us are CLN 'challenged' and the article is so much Greek .

Anyone have a solution out there?

I don't think it is an application thing really. It is the more likely the "current directory" Windows maintains on a per process base. Various Windows APIs such as the File Dialog box do adjust the current directory to the last directory accessed. So that is where the notion of applications locking a drive may come from.

Another one is that LabVIEW keeps a handle to DLLs open as soon as they got loaded into memory until the application closes down completely. I'm sure the new LabVIEW 8.2.1 feature to define the DLL path dynamically at runtime for Call Library Nodes can actually remove that annoyence once the VI accessing that DLL has gone idle.

Rolf Kalbermatter

QUOTE(Bryan @ Apr 29 2007, 04:41 AM)

What if one wanted to use the parallel port on a computer anyway to save money, or for a home project or something of the like? I've thought of doing something like that just to do it. It would be cool (or IS cool if it already has been done) for someone to write a LabVIEW driver for the parallel port. I know I'm risking someone saying "Cool! How 'bout you do that?" (it happens a LOT here at work), but it would be something neat for people interested in creating something for a home project or in case someone just is set on using a parallel port anyway.

Programming a parallel port with direct IO access VIs is possible but not trivial at all. Apart from differences between computers in setup and differences in what mode a parallel port is initialised in the BIOS that can change how you have to access that port, there is one other important issue here. While notebooks nowadays seldom or never have a built in parallel port anymore (and serial ports too!!) there are even desktop systems that come without a built-in parallel port anymore. So in terms of ease of use and overal compatibility a low cost USB DAQ device is certainly a lot more friendly for nowadays modern systems and will get even more unavoidable in the future. While you can plugin a cheap 10$ parallel port PCI card in a desktop this is usually no option for notebooks too.

Rolf Kalbermatter

QUOTE(Bryan @ May 16 2007, 06:01 AM)

Yeah, I've thought of that. I haven't been able to get LabVIEW and other support applications I need to all install on DSL and run in RAM. I have 62+ machines that I'd like to have up and running the same application all at the same time. I don't really want to have to buy 62+ USB sticks to accomplish that task.

I'd really just like to get something up so that I can run a LabVIEW executable and install GE's "vmisft" software onto it (since my LabVIEW application depends on it to access the VME bus).

Inasmuch as I would like to do this in LabVIEW, I'm afraid I may have to go an alternative route and get some sort of linux-only solution where I have a linux C-application that does the features I'd need, which is essentially to receive, parse, execute and respond to commands I send to the computer over the network. Unfortunately, with my little knowledge of c-programming in Linux, I may have to consult one of our resident Linux gurus for help with this.

Well, I guess the 62+ USB sticks would be the cheapest solution in terms of both hardware and time investment. Installing a LabVIEW executable on that boot image makes everything even more feasable as a whole LabVIEW development environment might actually require some of the larger sticks, not to mention the legal licensing issues that would simply require you to buy one license per USB stick. As to the costs of a USB stick for test reasons I would bet that the ease of use of just plugin the stick, boot up the computer and start the test is going to be a real money safer after just two or three test runs of so many computers. I can not see where the cost for such a solution possibly can be a major showstopper, for a project that involves a military contract with very strict configuration control. If the additional one time investment of 30$ per system is to much I guess every minute spend on this forum to find an alternative solution will be already unproductive too.

Rolf Kalbermatter

QUOTE(Eugen Graf @ May 16 2007, 07:23 PM)

It's a legal download. You can ask german labviewer.

Eugen

It is indeed legal but the text says "Commercial use not allowed!" This is a version of LabVIEW 6.1, fully authorised by NI, to be distributed with the German computer magazine ct, but with the limitation that it can not be used for commercial projects. The Windows version is on their DVD that comes with their 11/07 issue (it's a biweekly edition).

In my opinion this is the single best German computer magazine and has been so for almost two decades already. They never would do anything illegal, although they sometimes have articles about technical issues that could allow someone to use them for illegal activities, but at the same time it educates the reader about how to prevent such illegal activites too, and that is clearly the main aim for them.

Please note that it is just the plain FDS. Ni Toolkits, Application Builder, etc. which would be mostly things that go clearly into commercial use anyhow.

Rolf Kalbermatter

QUOTE(Jim Kring @ May 15 2007, 04:50 PM)

I upgraded to 8.2.1, recently, and my visaconf.ini is still in the same old location (C:\VXIPNP\WinNT\NIvisa\visaconf.ini).

It is but it contains almost nothing in comparison to earlier versions. This is with VISA 4.1 and MAX 4.2.

Rolf Kalbermatter

QUOTE(george seifert @ May 3 2007, 01:02 PM)

I just tried the exe on my PC (Dell) and it works fine. The PC that hangs is an HP. We had to start buying HP PCs and some of them have been giving us problems. Some wouldn't recoginize NI DAQ cards. I'm suspecting now that this is a PC issue.

George

It's a kernel driver issue in combination with your PC hardware or more properly your BIOS. I've seen HP BIOSes creating strange things lately a few times. A few months back I tried to install a PCI-1407 card in a HP PC and decided to also install the greatest and newest NI-IMAQ with it. The card simply didn't work. It showed up in the device manager but with an exclamation mark and indicating an error 10 had occured.

While dealing with NI support about that I happened to try an older NI-IMAQ that I had from an old setup (Ver 2.5.1 or so) in comparison to Ver 3.6 and everything worked alright. Later that day I got a message from NI that the issue was known and could be resolved by downloading and installing a new BIOS for the HP computer according to this http://digital.ni.com/public.nsf/websearch/F69AB8D3B7C0261F8625723E007205FF?OpenDocument' target="_blank">Knowledge Base Article. I didn't go through the hassle of installing a new BIOS since it now worked and also because I was at a customer site with firewalled internet access and optaining the BIOS would have been problematic.

Rolf Kalbermatter

QUOTE(zampala @ May 1 2007, 04:46 AM)

I have installed labview 7.1 on a Fedora Core 6 machine, but when trying to launch labview from command line I get a

glibc detected realloc(): invalid next size

or something like that. glibc version is 2.5

anyone can help me out?

On a suse 10.1 install labview runs ok, but my GPIB-USB-HS shows an orange Ready LED light, never turning into green. Of course there's no communication between the pc and the instrument. The same interface is working fine under win. USB permission issues?? but working as root does not do any better either.

any suggestions?

Fedora or Suse makes no difference, I just would like to have labview running on linux...

thanks in advance

mirko

Have you checked that NI-488 drivers for Linux support your GPIB interface? While the actual register interface is very common for all NI GPIB interfaces, the actual connection to it (PCI, ENET, USB etc needs to be specifically supported by the NI-488 driver for this to ever work. I would guess that NI-488 for Linux does not support all possible GPIB interface busses yet or maybe there is a newer release that does. Check out the NI site for this.

Rolf Kalbermatter

QUOTE(Bryan @ Apr 20 2007, 07:12 AM)

I'm not familiar with using BootROM or any type of network image booting, so I'll have to read up on it. All of my linux stuff I'm pretty much learning as I go. Would this require me to permanently change things in the BIOS? I'm assuming it would as I would have to somehow tell the computer not to use the image on it's local drive at boot, which would require me to go into each computer's BIOS and force it to look for a network image instead of using the installed local image.

My intent is to disturb the hardware/firmware the least amount possible. This would be done on equipment for a military contract and thier configuration control is very strict. If I change anything it may have to go through a documentation and possibly an approval process. The software engineering group boots from a USB device on these units frequently, I'm essentially going in through the same method as they do, but with different software and a different USB device.

With >1GB USB sticks getting very common why not install an image of an OS with LabVIEW installation on them. If they can boot from there you should be able to do so too. Just need a stick that supports booting from.

And then it should be quite simple to create as many of those sticks as you might need to get to test all machines in parallel. Not completely free but USB sticks don't cost that much anymore. You could even go with a smaller stick for DSL I think although not sure what are the smallest that support booting up.

Alternatively you could use such a stick to boot up the system into a minimal configuration that connects to the network and downloads everything else necessary to the local RAM disk.

Rolf Kalbermatter

QUOTE(Aitor Solar @ Apr 23 2007, 07:35 AM)

It also works with the [text] suffix if you put the end slash: "www.google.com/" . Usually the web browser corrects that; my fault.

Anyway, I think LV shouldn't crash if I ask for text with something that is not text. An error code is OK, but a crash...

Saludos,

Aitor

OpenG has a VI that does this all in G. Works quite well and much less likely to create crashes :-)

Please not that this VI does just what it is asked. Meaning if you ask it to get a certain page that has a redirection it will do so which will only return a short status message and some redirection code which you need to parse and use to get the real page.

Rolf Kalbermatter

QUOTE(Michael_Aivaliotis @ Apr 22 2007, 05:59 PM)

If you know, then why ask? If you have the VI's in your palette then try them. What are you looking for?

LabVIEW 3000 with AI and mind reader interface. It just reads the developers mind and creates everything as it finds it there. The AI is necessary to overcome fuzzy, non-existing and wrong knowledge about what the developer thinks she/he needs.

Rolf Kalbermatter