-
Posts
3,904 -
Joined
-
Last visited
-
Days Won
269
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Rolf Kalbermatter
-
-
That's the theoretical part of it. But in a practical situation the data acquisition is handled by dedicated hardware, so it's already paralleled and multiprocessed. Besides, analysis demands much more computing power than acquisition (seen from the PC), so the end result is still max 50% utilization of the PC's dual core processor.
I have yet not seen that LV uses both cores within one loop (maybe it uses several threads, but never both cores). This means that it is *extremely* hard to write an analysis package that uses both cores effectively, since you have to prallelize it by hand.
To detach the user interface from the rest of the program therefore seems to me to be the only thing that the dual cores can be used for in a practical setting. But then, this can be very useful in sutuations where you have lots of graphs and stuff, and guaranties 100% responsiveness.
Data acqusition is not just hardware. The data needs to be transfered by a kernel driver into some intermediate buffer and from there into the application buffer. At least the last operation will be executed in the context of an application thread and can contain scaling (DAQmx channels) and other things too. So there is certainly something a core could be doing eventhough it is for a large part IO/memory related and therefore not the best candidate to be parallelized with multiple cores or CPUs unless you would have separate memory busses too.
LabVIEW will not control the cores directly but instead use OS threads. How the OS distributes threads onto multiple cores is almost completely out of control of LabVIEW and can actually be tweaked by a power user.
So while multiple independant loops will allow LabVIEW to distribute each loop to a differnt thread it is usually very counterproductive to start distributing related code to multiple threads especially if data flow commands a certain execution order. Instead of just continuing execution of a logical dta flow LabVIEW has to suspend a thread and wait for the correct thread to be activated by the OS to continue the logical data flow. In addition to the costly execution context switch you are forcing onto a logical data flow, you incure additional delays since the OS might decide to activate a different thread first than the one that would suit the dataflow best.
However if you have a single loop with subVIs you could assign different execution systems to these subVIs and LabVIEW would be forced in that way to use a different thread. But please note that this will only really have any positive effect if you happen to have two different subVIs in the same loop that do both a computationally expensive operation.
Without subVIs parallelisme in LabVIEW is limited. All built in nodes that do not have some kind of wait or timeout function are exectued synchronously and in the same thread as the diagram they are contained in since their typical execution time is quite small in comparison to the context switch overhead to let the OS switch between multiple threads.
Most LabVIEW applications I write have anything from 2 to 6 or more parallel loops in the main diagram although sometimes some or all of the loops are located in specific subVIs that are called by the main VI once and terminate automatically all when the application wants to shutdown. This has never given me bad surprises (provided you do a proper design before you start with the actual coding) but results in applications that do DAQ, Analysis, logging, test sequence execution, image acquisition and instrument control all in parallel and still have an utterly responsive user interface.
Rolf Kalbermatter
-
Is it LabVIEW-based? Any chance of it ever becomming public? Or even better still, becomming part of the save routine in LabVIEW?
But it is already part of the save routine! That is why you get those error dialogs when saving VIs.
And sometimes recompiling (shift-run tool) the VI helps but often deleting the offending object is the only course. I haven't seen it often since about LabVIEW 6.1 but can't really comment to much about LabVIEW 8.0.x. It's possible that LabVIEW 8 introduced new ways to create insane objects.
Rolf Kalbermatter
-
Unfortunately, that still doesn't work. I'm completely baffled.
That's also part of my problem: I have failed to replicate it.
That made me think I might be able to do something by removing and the control and adding it back, but no dice.
All these things point actually in the same direction: You have somewhere in your COMPLEX UI VI some code that resets these properties. It might be a aproperty node that you added at some point, then resized the Event structure or some case, so that it fell of into invisible area. Or some execution logic in your state machine that causes this at initilisation. I've been there and done that too and almost pulled my hair over it before I realized
my own fault.
For invisible elements try to open the Error Window under Window->Show Error List and check the show warnings check box. Then go to the VI in question and hit de wanring triangle besides the run button. If it's about the executiona logic of your VI you probably will need to single step or at least work through your intialisation logic with breakpoints until you see where exactly the property gets reset.
Rolf Kalbermatter
-
EDIT: Well, I've found out that I actually do have more precision in my results than I orginally thought; however, there is still a problem which may actually be the expected result of computer arithmetic. The conversion function will convert a string such as "+5.748901924922E+002" into the number 574.8901977539. Is this just a result of the inherent lack of extreme percision in floating point numbers represented by a computer? I know the amount of precision one can achive is limited, but I didn't think this number would reach that limit, though I could very well be wrong. Once again, thanks in advance for any and all assistance.
As a reference (it's actually mentioned in the online manuals too somewhere) a single precsion number can be only accurate to about 7 significant digits while a double precision number can be accurate to about 15 significant digits.
Rolf Kalbermatter
-
Thanks rolfk, but I don't want to change the global cursor, I just want to get the global cursor's status.
Then read the entire MSDN article pointed to in the previous post! It mentions that GetCursor is only for the applciation cursor while there is a GetCursorInfo or similar function that will give you the global cursor (at least if you are not using an archeological Windows version).
Rolf Kalbermatter
-
I am attempting to read Matlab Binary Files into LabView and am having difficulty.
Anyone have a Sub Vi that is capable of reading Matlab Files stored in binary (.dat)?
The files are too large to use Ascii.
Any help is appreciated.
I think there are such VIs on the NI site. Try to locate them there. I haven't used them but a collegue got them in the past. They were limited in the data types supported but adding new datatypes didn't seem to difficult with a little digging.
Rolf Kalbermatter
-
Well i don't see my issue anymore after rebuilding from scratch, although I haven't added one nasty private property.
I am working on a toolbar next to the open panels which move with the active panel.
I hoped at LV8 there was finally a way to add your own button to the tool bar but no! :thumbdown:
Ton
I don't think LabVIEW will add support for modyfying it's toolbar anytime soon. But with the new splitter pane you can create your own very nice toolbars in LabVIEW 8 quite easily.
Rolf Kalbermatter
-
Did you see the ultimate LabVIEW Geek questions for this week (6)
If you save a VI to a previous version, and then open the saved VI in that previous version, why does LabVIEW add an * next to the VI name, indicating that there are unsaved changes? (Correct answer worth: 30 points)
The new version removes the block diagram and the compiled code so the old version can rebuild it from the machine code only
Wow LabVIEW contains actually a reverse compiler
. Now everyone that saves his VIs with password or no diagram at all is simply buggered ;-)
Hmm, not sure how that differs from the first really. Still needs a reverse compiler and I just so much like this new extraSuperSecretTool.The new version compiles the old version, but it can't actually save the block diagram in the correct form for the old version
The new version can write the block diagram in the correct form for the old version, but it can't actually compile the old version
Naaa! This last one is to simple. It can't possibly be this! ;-)
Rolf Kalbermatter
-
I heard that NI has dropped the Qubix platform - maybe they found an existing COTS system that was comparable - might just be a rumour though...
PS: Welcome back Mike
We missed you!
The latest news I heard are the same. NI seems to have dropped the idea to think about how to commercialise the Cubix platform. So it's a nice idea but it will probably never be sold in that form. Maybe an opportunity for a third party. With the LabVIEW Embedded Developer platform this would be very feasable, although I wonder about the commercial benefit of such, if even NI doesn't sees a chance to make it a profitable thing.
Rolf Kalbermatter
-
From what I could gather from the googled 2IHG7FZ8 article, it was saying that the full duplex is only an issue with a crossover cable and that with a hub it works fine. Did you take it that way?
I'm seeing the exact same results every single time, with both a crossover cable or using a hub.
This is only really true for modern hubs. Older dual-mode hubs frequently had trouble to auto negotiate the correct speed and/or handshaking too.
Rolf Kalbermatter
-
Thanks all, I have made one "GetCurrsor" sample attached, but, it is not well, as the cursor turns to "busy" status, and the back count is not changed. the count can changed at labVIEW front panel only, if the cursor is out of labVIEW front panel, it is no response. is anything wrong ?
please help to point out.
Changing the global cursor is not such a simple exercise. Basically Windows maintains a cursor state for each application and changes it accordingly whenever the cursor changes into a screen area owned by a different application. And in the case of LabVIEW it gets rather nasty for the application cursor. LabVIEW has the habit of resetting the cursor frequently to what it thinks it should be. But if you use LabVIEW 8 then you have already functions in the palatte to change the cursor state for at least LabVIEW.
To change the global cursor consistently I'm afraid you would end up having to write some hook function again.
Rolf Kalbermatter
-
Thanks Rolf Kalbermatter, but I am not familiar with C language of this controlling . So, anybody can help to make a DLL or a sample will be great appreciation.
Maybe that would be a chance to learn C? It's still THE engineering programming language and won't go away anywhere soon. Having some knowledge about C programming will always be an added bonus in almost any engineering profession where you even remotely need to get your hands on a computer.
I'm not volunteering to write this thing for you, sorry. It's going to be a time consuming exercise in any case and to get it work exactly as you envision it will probably get a hard exercise for someone else than yourself.
Rolf Kalbermatter
-
Yet, if you use URL and enter www.ni.com, it flips to 16% male and 84% female. Either the girls just want to know what us guys are talking about, or Microsoft still has a ways to go. Maybe their adCenter folks should try Googling for the answer! :laugh:
Maybe not
Most of people at the NI marketing department used to be female back when I was in Austin some 14 years ago, and they were very nice folk to be with
. Not sure if that has significantly changed.
Rolf Kalbermatter
-
I am looking for ideas that can help with an application that will eventually be
1) deployed to RT targets (preferably 7.1)
2) Will produce multiple large data files that will exceed 2Gig each.
If this was Windows only I could use HDF5 or the Large File functions from OpenG (THank you Rolf!)
BUT
HDF5 is not supported in RT (any version).
The only idea I have so far is to "divide and conquer" (write multiple files instead of just one file).
All ideas or suggestions will be greatly appreciated!
Ben
The file IO APIs the Large File package uses are standard Windows 32bit APIs. The only reason this might not work is that the underlying RT OS and its WinAPI implementation does not support files bigger than 2GB at all. If that's the case there is absolutely nothing you could do in the application itself and maybe that is why HDF5 is not supported.
Rolf Kalbermatter
-
I'm revisiting a cFP project I've been away from for a year, and I no longer have access to the hardware until the few days when I go onsite to deploy an update.
I want to add watchdogs to the cFP code, but can't seem to find decent info and with no cFP controller I can't play. Don't want to be implimenting new features in the deployment time. I have several loops, and ideally would like one watchdog per loop so if any loop hangs the whole thing reboots. Can I do this simply by having multiple "Watchdog Configure" nodes and wiring the watchdogIDs to whack nodes in the individual loops? I've had a play with the VIs on Windows but they do nothing, so I'm not sure that being able to code this on Windows without getting broken wires actually means anything.
I haven't played with the watchdogs on cFP and don't have one handy to play with but I'm afraid there is only one wtachdog hardware resource on the cFP. Either trying to open more than one will not work at all or if it does it may reset the watchdog on every access which means you would only fail if ALL your loops stop.
A better aproach may be to wire up a small LV2 style global that allows your loops to open a reference to some internal state (an array index might work). On every reset store the actual timestamp in the apropriate index and evaluate all timestamps to have not elapsed more than your set value. The whole thing might be a little bit involved in logic to make sure to reset the actual watchdog apropriately but it could definitely be made to work.
Rolf Kalbermatter
-
So far I've only run LV for Linux 7.0 under PCLOS. (A Mandriva based distro)
It seems to work well for the most part, although I still haven't got the Example Finder working.
Damn Small Linux is another of my favorite distros. It breathed new life into my old and well loved Toshiba laptop. I had assumed that I needed KDE or Gnome to run LV. But perhaps not.
I kinda doubt that LV4L will run on my old 266 laptop. But under DSL it might have a chance. I'll post updates if I get anywhere with it.
In principle LabVIEW should only use XWindow and therefore should be independant of the Window manager and Desktop environment used so should run on any system that has an XWindow server. There have been however some trouble in the past letting LabVIEW run on dummy XWindow servers that only provide some sort of text output (to save resources for applications that could run as headless systems) and I'm not sure there has been any work done to improve on that.
Rolf Kalbermatter
-
I am unfamiliar with what you mean by "inlined". Could you expound on that?
I wouild really like to understand the last element, since it gave me the most trouble. I may re-write the dll's handling of data like you suggest, but foresee having to be able to interface with pre-defined dll's that I do not have the source to, so let me take a stab at your example setup:
Inlined means that a C compiler will simply reserve the necessary amount of bytes for any fixed size data element in the structure itself.
An example
struct {
int val1;
int array[];
}
will represent a structure with 8 bytes length first the val1 integer and then a 32 bit pointer
struct {
int val1;
int array[100];
}
will represent a structure with 404 bytes length, again the val1 integer and the 100 array elements directly following.
Similarily an array
int arr[10][10]
inside a structure will represent a memory area of 400 bytes (10 * 10 * 4 bytes) directly in the structure.
In LabVIEW you would create a cluster of 100 integer elements for this.
An array
int arr[][] would really mean a pointer to an array of pointers instead.
In C multidimensional arrays are a little bit strange if not to say inconsistent. As you can see fixed size arrays look in the organization similar to what the data area of a LabVIEW array does (but a LabVIEW array is always a handle to the data) while non-fixed size multi-dimensional arrays are really hard to deal with.
Element1: I32
Element2: cluster of ( 1D array of U8 with field length set to min length=4, padded with zeros ) (can I just use a string here?)
[\quote]
No a LabVIEW string is always variable sized (except in some embedded development environments) and therefore a handle, so creating a cluster with a string inside will always create a C structure that no normal C code will be compatible with. You could teach your C code to deal with LabVIEW data types directly but that usually requires a good understanding of the LabVIEW datatypes (generally you should have read the External Code Reference Manual from the cover page to the last page ;-) and understand most of it too)
Rolf Kalbermatter
-
I need to change the modified Date and Time of a file.
I think that the attached code is going in the right direction. I am trying to do this by making a call to kernal32.dll.
The problem I have is formating the data type to pass to the dll for the Date/Time.
Any help would be great.
Roger
There is a VI File Info.vi in the OpenG Toolkit file package that allows to change the modification date and creation date of a file provided the current user has enough privileges for the file in question.
The prototype you are showing in your VI is VisualBasic syntax and not very helpful for LabVIEW purposes. LabVIEW is strictly typed just as C is and needs to be configured to match the expected C types exactly. If I remember right then FILETIME is a 64bit integer or a long long. This can be achieved directly in LabVIEW 8 with the (u)int64 but in LabVIEW before 8.0 you would have to create a cluster of two (u)int32 and pass that instead.
Rolf Kalbermatter
-
Thanks Rolf, yup, I have searched MSDN, but I haven't got any info about my goal :headbang:
you wrote "have to install a global filter hook for the events you want to block" is this handle only ? haven't any simple way to reach it ?
just call an or two APIs ?
The SetWindowsHookEx function takes as one of the paramaters a callback function. This is a function pointer and can only really be confortable done in C so you will have to write a DLL in C that does the hooking. The callback function will inspect the message passed to it and either modify some parameters, deny handling of the message altogether or allow handling of the message unaltered. The return value of your callback function determines if the message should be further handled or not.
It's a low level work area and if your callback function does the wrong thing you can get your Windows system in a rather hard to control state. (Ctrl-Alt-Del) may be your only friend then or the reset button.
Rolf Kalbermatter
-
Hi,
Yes there's an API for OpenOffice.org that can be downloaded from api.openoffice.org as chrisdavis says. I've installed the OpenOffice 2.0 SDK in my computer.At first glance it's possible to communicate with OpenOffice.org by many different programming languages (C++, C#, java...). With LabVIEW it would be possible too because there's ActiveX and classes of .NET but the Developer's Guide has got 1141 pages in PDF format and it seems to be quite difficult.
So, and this the reason of this topic: Why theres is a LabVIEW Report Generation Toolkit for Microsoft Office and not for OpenOffice.org.
As Chris said demand is the key issue with NI. But another issue is that OpenOffice was not a well known topic at all back when the report generation toolkit was created. Otherwise chances are that at least a basic interface to OO may already have been built into by an enthuastic NI developer. Several of the example libraries and toolkits started out as a private pet project of someone inside NI and sometimes even outside of NI.
Rolf Kalbermatter
-
It would be nice for reporting and documentation to have programmatic access to the FIND Dialog and it's output. I know we can do some of this using scripting, but until NI opens the 8.x+ goodie bag we are stuck with 7.x and kludgy porting up to 8.
1. Create report of locations of item X
2. Boolean searches of items near each other
3. Reporting of LV and DLL calls to cross reference with doc's on the C code in external libraries
4. Various other searches
5. Saving of these in text files, spreadsheets when modifying older code
As far as I'm aware a large part of the find uitlity is not exposed at all to the LabVIEW diagram. Maybe that changed in LabVIEW 8 but in earlier versions the Find utility was a LabVIEW internal dialog that had direct access to all internal methods of LabVIEW without having to go through a VI server interface.
Rolf Kalbermatter
-
Nice work from JdP indeed. This is what most Windows programmers do not seem to like very much but which is very common on Unix. Just call the other program directly with some parameters. It keeps everything rather simple by using standardized interfaces, leaves specific functionality to the tools that can do them best and follows the KISS principle.
Although I'd still love to see (someone else) create a nice OutLook &/or Thunderbird API,
Right, I undersign the (someone else
) part! I'm not a masochist and doing Active X on MS Office applications is aiming for a moving target! Not much fun at all!
Rolf Kalbermatter
-
HI
I have a full version 8.0 of labview and want to use the vision utilities which fall under vision and motion.
However I see this function:
Color Utilities Palette
(Vision-->Vision Utilities...)
IMAQ Color Image To Array
the documentation says that tehre are other function salso which convert a 2D array t o image and some other functions.
I tried but didnt find it and also tried to see if some more CD need to be installed.
Please help me in finding out these functions
Thanks
Some very minimalistic Vision VI functions are installed by NI-IMAQ the driver software for National Instruments image acquisition boards. Those functions allow NI-IMAQ to give you an image back into LabVIEW but that is about it. The Vision Development Toolkit is a much broader library that contains all the VIs that you could possibly dream of.
Rolf Kalbermatter
-
Hello all,
I'm familiar with passing simple integer and string values into CINs, but I'm just getting started with passing structures and would appreciate a helping hand.
My dll has a structure as follows:
typedef struct test
{
int num;
unsigned char name[4];
int dnum[16];
unsigned char flet;
char aname[16][256];
}
Test;
I'm trying to build a typedef'd cluster control that I can use to pass data in and out of a function in my DLL that uses the above. I had fairly good luck in doing this with another structure that held only integer returns (no arrays), but I haven't been able to get this one nailed down.
You got quite a bit wrong here!
First the arrays you have are all fixed size so they are inlined as such and represent nothing like a pointer.
You would need a cluster with following setup:
int32 num
cluster of 4 uInt8 name
cluster of 16 int32 dnum
uInt8 flet
cluster of 16 * 256 uInt8 aname
Especially the last one is not very convinient to do and I personally would treat the entire structure as an array of unsigned bytes passed as a C array pointer and write VIs that insert an retrieve the according information from that byte stream.
Rolf Kalbermatter
How to "protect" non-commercial library against commercial use
in LAVA Lounge
Posted
Apart from some more or less well written VIs to access specific USB and similar keys I'm not aware of much in this direction. The problem as I see it is how much do you want to spend to protect your software?
Usually LabVIEW is not used for high volume applications (it's runtime licensing while quite liberal nowadays does not always lend itself well for this) and therefore a license protection that costs days and weeks of development time is not likely to recover its own costs. And license management is a trade of its own with most of what is on the markt nowadays being more of a solution to fend of the casual copier than a way to really dwart the determined hacker.
And lets be honest, the only fool proof copy protection is to lock up your software in a safe, destroy any backup copies and throw away the key to the safe
So what is it you want to prevent and how much is it worth to you? If it is about not allowing to run your software by people that would anyhow never buy your software, then honestly every single dollar spent into copy protection is simply lost money. If it is about the fun to have copy protection built into your application, it's the same. Only if you can make a valid case that software will be bought thanks to copy protection can you start to look into spending money for this if you want to think commercial.
As for me I'm much more likely to buy a LabVIEW add-on toolkit with a honest price that uses no copy protection than using an overpriced toolkit illegally at all. And a copy protected software always gets 10 minus points in my opinion if I have to evaluate such software. I may still buy it but then it needs to be a LOT better than its competition.
Rolf Kalbermatter