ShaunR

Indeed, the zlib library or more generally the zip addition to it do not use mbcs functions. And that has a good reason, as the maintainers of that library want to make the library compilable on as many systems as possible including embedded targets. Those often don't have mbcs support at all.

 

However I'll be having a look at it, since the main part of the naming generation is actually done on the LabVIEW diagram, and that may be in fact more relevant here than anything inside zlib. There might be a relatively small fix to the LabVIEW diagram itself or the thin zlib wrapper that could allow for MBCS names in the zip archive.

And 64 bit support?

I'm not aware of any conditions that would disallow transfering the ownership of a LabVIEW license to someone else. And in most places such a provision in the license agreement would be null and void.

 

However you need to make sure that you do get the ownership. Simply buying a CD ROM and a license serial number from anywhere might not really give you any rights. I would insist on a document that names the serial number, states the previous owner and also grants an irrecoverable transfer of ownership of that  license and serial number to you. Otherwise you may try to register the software at NI and then get told that you are not the rightful owner and when disputing that, the previous owner suddenly may claim to still own the license.

 

I do know for sure that NI does actually care about ownership and has in the past contacted us about licenses that we have originally purchased and sold as part of a whole project, when the actual end user did register the serial number as their own, since the registering entity did not match the purchasing entity.

 

Transfer. If you have a named user license, computer based license, debug license, or if the SOFTWARE is

Multiple Access Software, you may transfer the SOFTWARE to a third party provided that you notify NI in writing

of such transfer (including the name and location of such third party), such third party accepts the terms and

conditions of this Agreement, and after such transfer, you do not retain any copies of the SOFTWARE (including

all Upgrades that you may have received) nor retain any of the written materials accompanying the SOFTWARE.

NI may, in its discretion, charge you a fee for the transfer of the SOFTWARE. If you have a VLP License, a

Surviving VLP License, a concurrent use license, an academic license (including a student edition license), a

Measurement Studio compile-only, or a debug license, the license is non-transferable and you may not, without

the prior written consent of NI or its affiliates, distribute or otherwise provide the SOFTWARE to any third party or

(with respect to a VLP License or a Surviving VLP License) to any of your sites or facilities not expressly

identified in the applicable documents from NI. If you have any licenses under the EP, such licenses are

non-transferable and you may not, without the prior written consent of NI or an authorized NI Affiliate distribute or

otherwise provide the SOFTWARE to any third party or to any of your sites or facilities other than an EP

Location.

 

reference

(emphasis added)

One can have a “Hardware” actor, that is the only process to actually communicate with the actual hardware.  That actor pulls from the hardware, but pushes status changes to other actors.  [AQ may be thinking of this “Hardware” actor rather than the actual hardware.]

Indeed. So you are getting the status directly from the device as and when you need it rather than "remembering" state in the software. It doesn't matter what the method of transmission through the software is (actors, events, queues, notifiers or whatever-a good point to again whinge about not being able to hook up VISA refs to the event structure ).

Agree with Intaris, though I prefer push over pull:

I don't encourage interrogating the HW. Instead let it push changes up to the UI when they happen. The UI just announces "I am connecting" or "I am disconnecting". After that, it is the HW's job to tell the UI about state changes. The benefit here is that you, the designer, do not ever get in the mindset of your UI holding and waiting for information from the HW, which leads to long pauses in your UI responses.

Unless your hardware uses push streaming (rare as rocking-horse droppings). The hardware cannot tell the UI since it will be CMD->RESP.

Thank you todd!  

 

Hooovahh, another question for you.  Why did you include a "stop" event case?  Couldn't you have just wired the stop button to the "or" function outside the event structure, but inside the while loop?  Just to be clear, I'm not criticizing, just curious.  Maybe I'm missing something is all haha.

To paraphrase Hoover............

With a stop button only. If you click the X button on the form (as users have been trained to do). Your panel will disappear (so can't get to the stop button) but your VI will still be running.

ShaunR - How do you know that math there? Also, I'm more or less using a range (halfway between each semitone +/- 1 Hz) to show the note.  Sounds a little weird maybe, but I usually keep my guitar in tune but don't always know what note I play.  So there's a chance that these notes played won't be EXACTLY what the frequency of a note actually is.  So how can I use this math to keep my ranges?

Google is your friend But looking at the javascript source here should help you out

As for ranges. Well. They key is to convert your measured frequency to numbers of semitones from a base frequency. You are not counting in frequency, rather, semitones so round up or down fractions of semitones/crotchets/quavers/lemons/whatever (just be consistent).

@Hoover.

Glad I don't work for you.lol.

Well. The case statement is looking a bit unwieldy.

You can take advantage of the fact that an octave is 2^n of the fundamental and a semitone is the 12th root of 2 (or about 1.059)since you are only interested in the fundamental frequency. Then you should be able to calculate directly and represent it as a bit pattern.

For those things, it would be very handy to have access to ALL the Hardware settings right away. It COULD ping the Hardware Interface for those settings as needed... I don't know. This is very new to me, too.

That is that with hardware settings, you should always rely on the device to tell you what you can and can't do. If you start restricting user input values before sending to the device, you very quickly end up trying to replicate the device logic which can get very complex. With this in mind, it becomes just a case of setting max/min values to the controls. Additionally, most modern devices give readable error responses, so usually you only need to bubble them back to the UI.

Similarly. When it comes to device state. You should not try and maintain it in the software, rather, interrogate any state information as and when you need it. Maintaining device state in the software will vastly over complicate your code and lead to hard-to-debug disparities between the actual device state and that of your software. This situation is totally avoidable and means that very simple recovery procedures can be facilitated without complex code and the code can reflect state without logic.

If you bear in mind these "rules-of-thumb". You devices will do all the hard-work and greatly simplify your code as well as being far more robust.

Shaun,

 

OTS preferably.

 

 

thanks,

 

 

Neville.

I've always rolled my own. However. I've heard some good things about this one but from C# programmers rather than labview (they have an eval kit).

Hi Everyone,

 

Does anyone have any recommendations for using a USB-based security dongle with a LabVIEW 2011 application?  This would be for a Windows 7 application.

 

Ease of use with LabVIEW?

Cool features?

Any negatives?

 

Thanks,

 

Neville.

You looking for "off-the-shelf" or "roll-your-own"?

To be honest, I'm not sure about my position to Bitcoin itself. I tried to understand what it was about by visiting the forum there, but don't really got a clear picture. From some of the remarks there, it seems to be used by some folks in somewhat questionable ways. But then anything that represents some value in some form, even virtual currency or items in online games, is quickly attracting some folks who have more than questionable intent. So that alone is certainly not a criterium if the the idea of Bitcoin could be considered legitimate.

 

However it seems to me some form of online virtual currency that only exists by the gratitude of people believing that it represents some value. That in itself is an interesting concept and in fact not so much different than even our official currencies we pay with all the time, and probably even more real than derivatives on stock exchange markets. However who controls the creation of that value? In other words how are Bitcoins created? And I'm not so much interested in the technical details here as is already mentioned in this thread by the formula, than the process and procedure that controls the creation. If it could be created by anyone in any number it would obviously loose all value.

Well. Leaving aside the economic arguments for now.....

The big thing about bitcoin is there is no centralised accountancy, it is almost an instantaneous peer-to-peer transfer. And it is extremely hard to trace (anonymity). A few years ago you might argue that the latter was only a benefit to criminals. With current events (SOPA, Snoopers Charter et. al.) many ordinary folk feel that they need to protect their privacy. Many economies are also being sucked dry by corporate interests and other monetary systems have arisen to combat this so people are looking for alternative strategies. Bitcoins are gaining popularity mainly because of these two points and you could say it's filling a need at the right time.

Bitcoins obtain their "value" from scarcity (limited maximum number of 21 x 10^6) and by the energy consumed in generating them (electricity to run a bitcoin miner). There are a couple of bitcoin "exchanges" where you can convert bitcoins to fiat which is probably a more understandable, although flawed,  measure of value (as of writing 1 bitcoin~= 14 Euros).

...... But on to the interesting stuff ......

Bitcoins are "mined" (that's the terminology) just as resources (like gold) are. Instead of digging a hole, however, a computationally expensive algorithm (a hash) is used by a Bitcoin Miner. This is synonymous with password "cracking" in computational terms, but the intent is quite different. Whilst in the early days you could mine with a fairly low spec PC. The "difficulty" has progressed to the point where you now need dedicated hardware-usually racks of GPUs in the 10s of Giga-hashes per second. (This has led to an argument that early adopters gain a significant wealth advantage, but let's stick to the interesting stuff )

The design of the bitcoin system is such that there is a maximum of 21 million that can ever be created (currently there are approximately 10M in circulation). A bitcoin itself is just a history of transactions (the block chain) from the "base" bitcoin block and the difficulty in "cracking" the hash changes in relation to the rate at which bitcoins are mined. (I should also point out that bitcoins are not mined singularly, but in batches). The number of coins in the batch (currently 50 at this time) also reduces as more bitcoins are mined meaning that the cost/BC (electricity consumed) increases with more bitcoins in circulation.

You can get a more concise overview here.

Suffice to say. On the surface it looks fairly straightforward (just money, right?) but the deeper you go, the more you realise just how much thought has gone into the system and how technically elegant it is (and not a banker in sight!). I can see a couple of issues that need to be resolved (bitcoins can be destroyed but not recreated and defence against a party taking over 50% of the network). But it does look very promising and certainly has gained the attention of the authorities.

There are no takers for 5 BTC?

I thought you would have finished it by now

Well. We are so OT.........what the hell:

What do you mean by "send it to the RT Task"? Can you show how this is used in your larger project? Generally I wouldn't recommend writing it that way; it's better not to put indicators inside structures if they are connected to subVI outputs. A somewhat simpler approach would be this:

Blinken-modified.png

That said, I don't actually see a logic problem with your original approach, so I suspect the problem may be further up.

Another alternative:

I know cars are overused in analogies, but if I buy a car, and the manufacturer of the car says in the manual I'm not allowed to modify their copyrighted design by painting it another color, I can still do so. It's still my car. If the manufacturer goes that route with the copyright, they might be able to prevent me from then selling my car, but otherwise I can modify my car however I want. (as long as it's not violating any laws that would exist anyway.)  How is software any different in this respect? It's my computer, and while I may not own the rights to the software, that particular copy is still mine, as it exists only on hardware 100% owned by me.

 

Car analogies are disingenuous. You buy a car and ownership is transferred via a document with a signature. With software you buy it but you don't own it! You buy the right to use it.

If nothing else, you commit a crime by promising to abide by the EULA and then not doing so. That's called lying.

That's not a "crime". It (the EULA) is a civil offense and last I heard, lying wasn't a crime unless you were in a court under oath.

The war that's raging about whether pirating/copying is stealing will not be resolved on forums and, I don't think it will even be resolved in courts (as bizarre as it may sound). The argument on one-side is that an "opportunity" has been denied and needs to be recompensed to the amount that "could" have been obtained. The argument on the other; that an "opportunity" has no value, cannot be proven and cannot be "stealing" since it was never realised or owned.

Which side you sit on depends a lot on your world view and whether you prize cooperation over ownership. One is a communal view, while the other is feudal. History tells us that they are generally orthogonal and each rises to be the "norm" at various times. Again. Historically, cooperation has been the most common and invariably when the greatest leaps in human progress occur.

Might I suggest we move all these to the "Licencing" thread where they belong?

It appears that the latter posts of this thread on the QSM (Producer/Consumer) discuss the kind of thing I'm talking about. One more satisfactory solution to using the QSM which was discussed is to ensure you keep the public message queue and internal functions queue separate. This way the QSM can enqueue its own sequence of states internally when a public message is received to tell it to do so. By adding a check for an external interrupt on each iteration of the QSM loop, a sequence can also be interrupted by a public message. This snippet of code from Daklu in that thread shows the kind of thing.

 

What I'm interested to know is what forum members such as Daklu, who have said they would seek an alternative to the QSM in any scenario, would implement as an alternative to achieve the same functionality? i.e. You need to be able to trigger a sequence to run, but it should also be possible to interrupt it (can't just be subVI'd as it would lock the QMH loop until it completes).

I'd use normal VI sequencing and dynamically launch it. If you want to stop it just Abort/close the VI. Quite often there will be a "controller" to launch/abort which the rest of the system messages to, effectively making it a module with an API.

Maybe you guys are a little too hard on this fellow.  Personally I enjoy unusual 'educational' threads like this.  Actually some of my favorite

threads ended up with someone getting kicked off the list

I don't think we are being hard. Just providing fair warning. It's not us he needs to worry about

Restrictions. You may not: (i) reverse engineer, decompile, or disassemble the SOFTWARE (except to the extent

such foregoing restriction is expressly prohibited by applicable law); (ii) use the SOFTWARE to gain access to

unencrypted data in a manner that defeats the digital content protection provided in the SOFTWARE;

Licence

出る杭は打たれる。

Perhaps you mean this: bitcoinaddress = base58encode(ripemd160(sha256(secp256k1(privatekey)))).

Protected wouldn't make any sense in this case since it really would be just *one* VI, and protected implies at least two. So I think you're vote is the same as mine that there's not much use in a feature like this coming into the language. Like I said, it was something that cropped up when I was playing around, and I was trying to figure out if it had any utility. None so far.

Well. On a slightly more esoteric point. You say in the OP that that it is like a local variable. Here you are talking about a single VI.

I think you need to define the context of what you think a VI represents.

For example. you can have multiple methods in other languages and they do not require a single file per property/method.to access the storage In labview you must have a VI (file) per method/properties that you wish to manipulate from the cluster (storage).

Taking my previous statement about "static". In other languages I could put a static variable in one of the methods to count the number of times that method/function had been called. This would translate (I think) into a single VI method with local (to that VI) storage outside the purview of the cluster (i.e. only accessable inside the function but could be exposed via a terminal of that VI - the return value in other languages). Is this a similar scenario to what you are describing here? Or am I really out there in my understanding?

A private key in the context of Bitcoin is a secret number that allows bitcoins to be spent. Every Bitcoin address has a matching private key, which is saved in the wallet file of the person who owns the balance. The private key is mathematically related to the Bitcoin address, and is designed so that the Bitcoin address can be calculated from the private key, but importantly, the same cannot be done in reverse.

Source

but can it please be accompanied by a response on the topic?

It was in response to your comment on protected (should be flogged etc). It is stating that private (generally) is not a "good" thing IMO for the fore-mentioned reasons. You are wishing to make fields "uber private". If that is off-topic then so is Jacks.

What you don't get is that I do use OOP extensively. I use it in PHP and delphi. I just don't like it in LV. So I am a little bemused that my thoughts invalidate any comment because I'm a classical LV programmer..

So back to "Any proposals for utility for private-to-one-VI fields of an object?"., Yeah. If you're going to do it (I can't see a use case apart from bringing it in to line with other languages in the same sense I can't see the need for a static equivalent). Make them protected not private or give us a choice how to scope them with protected being an option!

Shaun: That whole argument is why you would use protected *accessors*. Those can be overridden to provide alternate behaviors. Fields can't be.

Accessors, fields, data or lemons. It doesn't matter. The point I was trying to make is that if a user wants to modify/abuse my code to get the desired behaviour; they should be able to without editing it. By making it a protected rather than private lemon, they can and is making a conscious decision to do so by writing additional code rather than messing with mine.

By all means "hide" data and functions. But don't lock them away so they need a crowbar to make it do what they want.

No. This would be the opposite... *uber* private, where not even the other methods of the parent class know about this data. Protected and community scope data is an abomination against nature. Flog yourself with your mouse whenever you find yourself desiring it. This will either beat the desire out of you or at the very least destroy your mouse so you cannot contaminate your fellow programmers.

Community scope. Meh. Still don't really understand what that is for. However. Protected? I don't desire it. I demand it.

In other languages I never declare "private". I always declare "Protected".

The reasoning goes like this.......

If someone is going to use my class then it must do what they want it to do (not necessarily what I think they might want to do or what I have designed it to do). If I declare a private function.(or variable for that matter) then I am denying them the option to make it work the way they want it (and don't talk to me about "FINAL"). However. Regardless of me making it private, they will hack the class to bend it do their will and, ultimately, modify my code (which I have spent a lot of time testing). At this point we get into arguments since the onus is always on the supplier to prove that the problem isn't with their code.when things go wrong. Eventually you figure out they have hacked it and you get into the ....... "You shouldn't have modified it because.....I modified it because.... You modified it therefore I'm not fixing your code" .... ad nauseam.

Declaring as "Protected", however, does not deny them the opportunity of modifying the bahaviour of my class and, more importantly, if they want to modify it to bend to their will; can inherit and not trash my clean and tested code to do it (we'll ignore the fact you also end up with multiple variants of subtly different code). Sure, they can break the functionality that I have carefully considered. But that is a problem with their code, not mine and I can prove it by making them go back to the original without overrides/extends etc. If they then say that they modified it. I can tell them they should have overridden so go away and try again.

.Net assemblies should not be placed in the system32 folder. The .Net loader will not pick them up from there. Instead they need to be placed in the GAC (Global Assembly Cache) or in the directory where the executable of the calling process is located. In the case of LabVIEW development environment, the better place is the actual project directory as LabVIEW registers that as well with .Net when loading a .Net assembly from within a project context.

Thanks for the detailed explanation. I avoid.NET a (and ActiveX) like the plague, so I was taking pot shot at a path issue.

But if possible .Net assemblies should be installed into the GAC by an installer.

Added to my list of "reasons (excuses) not to use .NET"