ShaunR

Shaun, if you were interested, this VI would be a great addition to OpenG. I will contact you offline to follow up.

If it needs to be a direct replacement for the normal trim. Here she is......

You're right. I didn't look closely enough at the code inside the loop and I flipped its logic. It happens to me sometimes.

Yes. Hunting edge cases is not what I would consider a fun activity in my current state.

OK. enough is enough eh? I've uploaded the fixed version.

Shaun, if you were interested, this VI would be a great addition to OpenG. I will contact you offline to follow up.

Knock yerself out. Do I get a fee package manager professional

I was watching "The Gadget Show" earlier where they were they were trying to get a football to break the sound barrier...yeah right

Anyhoo.

One of their attempts was using a high-g-gun that is usually used for crash testing to shoot cars along a rail (this is at MIRA) . They attached a football boot to it and shot the sled at a ball.They didn't say, but it looks to me like LV. Only Labview programmers are able to come up with these sorts of colour schemes for UIs

The Gadget Show Video

It appears about 3/4 of the way through.

Yeah I know. you can't build it.....but couldn't resist

I completely agree. We simply wanted the possibility for legal accountability (even at an extra cost), as this is necessary for certain applications and industries. We wanted 3rd party products (especially the top tier) to have the possibility of being used in the same strict environments as LabVIEW.

Those industries/companies that demand support, do so as a separate contract from the product. Some (for example) require 24 hr call-out and dedicated telephone numbers and contact names. As such accountability (legal or social) has nothing to do with the original product; II is a separate contract drawn up by the two involved parties and, accountable in it's own right.

As was pointed out before with the Linux example, There is nothing to stop a 3rd party entering into a contract to supplying support for an open source product and, indeed, there is nothing prohibitive about purchasing a product without support. It is a company policy restriction (like acceptable licenses - some companies don't allow open source at all) and that will change from one company to the next.

So the possibility is already there - It is possible to draw up a support contract regardless if you are the provider or not.

. That's just a bug,

Does it have a CAR?

2. Accountability

The response helps them resolve their current issue. But if the provider doesn't respond or the issue isn't resolved, there needs to be some accountability for the product.

This is good point. But .....

if I pay monies for a product then there are certain responsibilities that the provider must adhere to by law. This is true of not only tangible product but things like services too. If support is offered as a product or, if it is an inclusive part of a product (as stated in their literature), then the provider is bound to provide that service and is legally accountable to the terms of that service.

However, if it is not offered in this way, then the provider is only "socially" accountable and is under no obligation to provide that service and, if it is supplied, it is as a "value-added" service rather than a "rightful" one, with much less stringent responsibilities. From this definition, open source products are a socially accountable products and are no different than equivalent commercial offerings and the metric can be considered by customer satisfaction and review.

Does it trim whitespace and everything else as well?

Nope.

It works fine, but for 1 edge case.

I didn't look at the code, only the screenshot, but to expand on vugie's answer:

1. If there's no leading or trailing white space, I believe it will keep going until it finds the first WS and trim the text before/after it as well.
2. If there is no WS at all, I believe it will trim the entire string.

The function doesn't detect whites-paces, rather it detects non-white-spaces.

1. It will stop at the first and last non white-space. So it will return the string at offset 0 of length = length and never gets to see any within the string.
2. If there are no white-spaces at all then it will halt at offset=0 and length will equal length (length - 0 - 0) so it will return the entire string

Are we bored yet

That's true, but my point is that "resizable" applies to more than just whether or not there are resize handles. On OS X there is no such thing as "maximized" in the sense of not having borders. That concept just doesn't exist. Also, in Windows 7 you can grab a title bar from a maximized window and drag it somewhere else to unmaximize and then move it. There's no such thing as "maximized and not umaximizable", and If the size can change then it is resizable. Maximizing and unmaximizing changes the size, therefore if a window is maximizable it must be resizable. Like I said, this is just how it works. You can't be "maximized" if you're not resizable. The best you can do is try the steps I listed above.

Indeed. If it s maximisable then it is resizeable. But if it is maximised. it might not be resizable. The behaviour you are describing in Windows 7 is a feature of Aero that can be turned off or may not be available on some systems (and doesn't doesn't exist in XP, Vista and probably not in linux either)

I think what the OP is seeing is this.......

Create a new VI and put something in it so that it will run continuously.

Uncheck the VI properties "Allow User To Minimise Window" and Allow "User To Resize Window"

Turn off the Aero Snap

Maximise the VI.

Run the VI.

You should now have a full screen window that you cannot resize or move. and there are no minimise and no restore/maximise buttons. So far so good.

Double click on the title-bar.

It restores and now you are stuck with a non-resizeable, non-maximized (able) window. Well in 2009 at least.

BUG !!!!

Anyone spotted it yet?

Sure you can. Just unmaximize it. That's a resize. You can only be in a maximized state if your window is resizable because you can't get into a maximized state without maximizing, and maximizing is itself an act of resizing. That's just the way Windows and Linux (and presumably OS X) work, and at the very least that's the way LabVIEW works.

Hmm.

Whaaaat?

The point I was making (don't know id you were answering it or not...lol) Was that when maximized, there are no grab-handles so you cannot grab a border and resize a window You must first "restore" it then you get your handles back and can resize it..

To guarantee a response time requires resources, budgets and funding to be specifically allocated to that goal. For most companies, the resource is already in place as it is considered as an integral part of a company as an accounts or purchasing department s are. Free software (not trial or shareware, but truly.free of charge and royalties) in this environment is really a loss-leader - a gateway to sales for paid products and it is the companies interest to use existing support structures to capitalise on this and a proportion of the cost of a paid product is calculated to provide this support.. I think that is reflected in that (as far as I'm aware) all "Gold Compatible" are paid-for products with only 1 exception.

However. Open source software (like the OpenG) is a non-commercial environment. As such, there are no allocated resources, budgets or funds. There is no existing support infrastructure. There is only community/personal pride, commitment to self improvement and a willingness to share; often at personal cost in both time and monies. Of course. There may not be a team of 30 engineers on the end of a telephone and the software might only be created and supported by a lone individual, but in my experience the support response is far superior as you are actually interfacing with a technical specialist rather than a telephone jocky and they have a vested interest in the product - not your wallet .

But the biggest advantage is it has source code, and that empowers the user to be able to support themselves in a way that they cannot with proprietary, closed-source products so reliance on a fast support response is greatly diminished..

What does it actually mean "2-day turn around time on technical support". Is that to resolve an issue (I don't think anyone can guarantee that given time-zone differences). Is it to get an automated response to an email enquiry (It doesn't mean my problem will be solved). How does a 2 day support turn-around make some software more "compatible"?

I think the Standard and Silver have the right idea - Peer tested and reviewed. If you view the "Compatible" award system as a measure of excellence then I think the issue of support is a bit moot since it is catered for within reviews. If another measure (or alternative) is required to distinguish Gold from Silver, then perhaps it should be relevant to the quality, number of commendations, platform dependence or whether it comes with source?

I think if it was a quality metric, then the OpenG tools would be (and should be) Gold.

Oh. And is "Compatible With LabVIEW" the right name? Surely all software written in LabVIEw is "Compatible" (versioning aside)

Maximized implies resizable.

Errrrm

If you maximize internet explorer using the Maximize/restore button you can't resize it

I don't mean to be hammering on you about this--I'm genuinely curious. I did a lot of Six Sigma work from 1997 through ~2005 in manufacturing-related business, but I've never quite grasped how to apply the principles to software development.

The 6 sig part is fairly straight forward and pretty well documented with templates you can apply. The hard part is the defect metrics (as applied to the software code rather than the project) and defining what they are and methods of measuring them (GUIs especially). This is especially difficult for for LabVIEW as most knowledgeable sources talk about base code size where every 100 lines is about 1 function point and we already know that it's hard to equate text lines to G. I prefer numbers of VI's with weightings for collections every 200K (directory size) since it's easy to measure and validate. But I'm sure there is a more formal way of doing it.

The Wikilibrary has a good article with some useful views on the subject.

It's much easier when you can get a ruler out and measure something

Greetings,

I recently purchased a DigitalPersona U.are.U 4500 fingerprint scanner and would like to integrate it into labview for various purposes. Using the free SDK that DP provides I was able to quickly create some test code (attached here) but thus far I am unable to get it to work. Specifically I am using their ActiveX external code but I am not necessarily tied into that as they also provide .NET and few others in their SDK for interop.

Can anyone shed some light on what I am doing wrong? I am guessing it has something to do with the event handler.

Just some background

Fingerprint scanner

SDK download

Any help is greatly appreciated.

Well. Theres a lengthy form for downloading the sdk and you didn't include the call-back vi (was that supplied by the sdk?) so my input is probably going to be limited......but.

What are you expecting it to do?

Your while loop is just going to go round until you press the button, thats all you have really asked it to do. Unless there is communication from the call-back event to your VI (via a queue, event or something similar), you aren't going to be able to get any info back from it when it is actioned. A callback is called asynchronously and is a separate process to your VI

The first thing I would check is that the call-back is actually being called. You can do that easily just by putting a dialogue prompt in it so that if it is called a dialogue will appear. If that works, then you can uses an event or queue to send whatever information is received (in the callback) back to your main VI.

(I'm from up north BTW)

Artois ?

Hi,

I have been trying to catch up on interesting topics I have put to one side in the past and have spent a fun day reading about state machines and different architectures, I still have a great deal more to read and learn.

I keep coming across the term Macros / Marco state in a number of the topics and I am not fully sure I understand this term.

With regards to the JKI state machine, I think the Marco states are states where no work is actually done but new state transitions are push on the existing queue of states so that can easily find them. I have searched on Lava for this term and though it has lead me to reading a lot more threads about QSM & SM I still have not found out what people mean when using this term.

Any explanation would be appreciated.

regards

Dannyt

A macro state is just a single sate that represents other multiple states (an alias if you like). Commonly, this would be things like initialisation/finalisation where (for example) the Init state could be an alias for Load Settings, Clear Display and then Set Window Position etc. But the term isn't limited to SMs , Excel has "Macro recording", for example, which will assign a single command to a number of operations that you do and will"replay" them back when executed (either by hitting a hot-key or explicitly running the macro)

It's common to think of a project as finished when two things occur: when all the requirements are met, and when the quality it acceptable.

Or when the warrantee period has expired

I. regarding threads, when is the thread released? Usually a thread gets resources and thus, when it is inactive those resources are wasted and that might slow down the design.

Just to clarify this a bit which might make thing a bit clearer for you.

Labview allocates a fixed number of threads when it starts the environment. As such, you (the programmer) neither create nor destroy threads and labview uses this "pool' to schedule tasks from your program. Again, which tasks are scheduled are up to Labview although you have a small amount of control with the "Execution Subsystem".

If you are really worried about the mechanics of threading LV then I would suggest reading Multi-threading In LabVIEW. But for most Labview programmers, it's not a consideration any more than indexing past the end of an array is (you can't ).

I seem to be having some problems with the search function when searching for two or more words (for example <unit test>) - the first page comes up correctly, but when clicking for the second page, the number of results increases, and the listings are no longer in order, and no longer necessarily contain both words. If the two words are in quotes (e.g. "unit test") then it seems to work ok.

I've never had any success with the search either. I use Google to find stuff in here

Any clue how I can use this in LabVIEW? This call is in the .NET 4 framework. I installed that version of .NET but I don't see it as an option when configuring the Invoke Node in LabVIEW. I don't see any of the .NET 4 calls at all. And yes, I rebooted the computer.

Try importing this to a diagram.

Ooops. REalised you're using 8.x

Here's the vi saved to previous

The intermediary DLL is not so much a seperate DLL as the combination of the original zlib source code with the additional zip support that is now official part of the contribution directory but used to be just an optional component by someone else, and on top of that some utility functions to help support with LabVIEW integration. I could have left that all in separate DLLs but since I had to modify some zlib header files anyhow (to make the functions cdecl instead of stdcall as they used to be in older versions on Windows, and later on to decorate the exported functions with my own prefix to workaround naming clashes in the cRIO systems with empty stubs included in the system image) I decided to derive from the concept of providing fully original DLLs. And since the entire build process already was required anyhow for the additional LabVIEW specific part it wasn't really much extra work. In fact it makes building the shared library easier and also the packaging and distribution since only one shared library is required. The drawback is that merging in new zlib/zip versions is a little bit more complicated but last time when I added the new zlib version to it, the actual merging was done in less than an hour since I still only have to manually check and adapt two of the header files.

I didn't mean for you to defend the decision (apologies if it came across that way). I as just commenting on the fact that many people use an intermediary DLL which makes it difficult for me to just plop the latest version, pre-compiled library, when there's an update.

But I think it's great that you are investigating the x64 since it's prevented me from using the library in the past. LV now comes shipped with zip file support, but it doesn't enable in memory compression which I believe yours does support

Well changing only the offsets into 64 bit integers won't work. You also need to change the calls to use the 64 bit versions of the functions. If they simply changed the offsets to just support 64 bits, backwards compatibility would be broken. A 64 bit integer is passed to a function in two 32 Bit addresses on the stack so changing all 32 Bit offsets into 64 Bits only, it would seem strange that you could even run an entire chain of VIs as this mismatch should mess up the stack alignment. Although thinking about it, the functions are all cdecl and that means the caller cleans up the stack afterward so it may work ok anyhow, if there are no other parameters after the offset in the parameter list.

Like all OpenG libraries it's all on SourceForge.

I did download and create the zlib from here a while ago (has x32 & x64 object assemblies). Not sure if it will do over 2GB (don't see why it shouldn't). But the issue here is that you use an intermediary DLL lvzip.dll so it's not a simple replace as I assumed originally.l Although I'm not sure why (maybe speed?); I have seen it a lot with labview interfaces to dll's.

Actually 64Bit and support for >2GB ZIP archives are two distinct issue. I have in the current HEAD integrated a new version of zlib which would support 64Bit offsets internally which is what is required to support archives containing more than 2GB components. The same version also SHOULD be compilable as 64Bit code. While these two things happen to be incorporated in a working way in the current ZLIB library, they are not equivalent and even not really related.

I have come across some snatch in compiling the LVZIP DLL for 64 Bit and haven't really spent much more time on this until now. Well I can compile the code but it crashes and since I don't have a 64 Bit system at hand with a compatible source level debugger and LabVIEW installation (they both also need to be 64Bits) I can't at the moment debug it. The code as it is in the repository would apart from that crash be fully 64 bit capable and should also be able to handle >2GB components although that is nothing I have ever tested nor have thought to test so far.

So the OpenG library as it is in the repository SHOULD be able to handle >2GB files but that will also need re-factoring of some VIs to allow for 64 bit integers wherever offsets are passed to and from the DLL functions (those 64 bit capable functions have a special 64 postfix.

Indeed they are different issues .But LV x64 cannot load x32 dll's so even if the 32 bit dll is compiled with u64 pointers; it won't work in LV64 (which I think is why the OP was asking for an x64 dll). Anything that relies on dll's needs to be supplied with both and detect the bitness to work on both platforms (either on install or on the fly).

But I did play with the 32bit one when the OP asked, and by replacing all the I32 controls and coercions for u64 (in the write) actually got it to write a 4.3 GB file without complaining (quite surprised, although I can't see how the content would be valid.). The LV file functions are u64 so the coercions were causing it to throw the file error. But then it failed on the finalisation. The result was I could write a 4.3GB invalid file . Since finalisation was a direct call, there wasn't much further I could go without delving into the C source and thought I'd leave it to the expert .

Which repository?

It's great to hear your looking into x64

Just to clarify the interim fix for this:

1. Locate and open SQLite_Query-Transaction.VI (It is in the "Query" Virtual folder under "Core".
2. Right-click on the case structure (there is only one)
3. Select "Make This Case True" from the popup menu
4. Save the VI

It should now work as intended.

Correction of this bug will also have a knock-on effect on SQLite Delete Column.vi and SQLite_Rename Column.vi causing them to fail.

In each of these VIs there is a boolean (True) wired to the SQLite_Query-Transaction.vi. This boolean needs to be deleted.

The VIS will then work correctly.