ShaunR

You haven't told the Configure Serial Port which resource to use. Right click on the top left corner terminal and create a constant. Then select your serial port from the list. Put the serial port initialise outside the loop (and don't forget to close it when the loop stops) You should get it working with the Serial port examples first. Then you will see how to use the VIs correctly.

Just to expand on lvbs points. If you build source plugins. i.e. plugins with diagrams so they can be recompiled on the target system when invoked from an executable. Then you must turn off compiled code separation for that VI otherwise you will get the Error 59: “The source file’s compiled code has been separated, and this version of LabVIEW does not have access to separated compiled code. And just to reiterate a point that some people often forget. The global compiled code option only applies for "New Files" so checking it won't change all the existing files to use this method. You have to go and change each VIs setting individually and recompile. DISCLAIMER: The above are not "issues" as such. Just additional things that you have to bear in mind when using the option and may fit into the the grannys' eggs category.

Yes. I should do the rest of my posts (unfortunately I have only started about 3 topics ..... ever ) Just saves people reading the entire thread as it has run its course and the link contains the solution if they want to get the code..

After just over a year, someone has claimed the first prize. The original proposer for the competition is in a bit of a quandary . When the competition was set 5 btc was worth about $75. Now they are worth about $3000 The deadline was set for when 5 working solutions were submitted, however, there has been only one and the OP has now closed the contest. Kudos to the guy who had to write native labview code to handle big numbers and eliptic curve multiplication, which is no mean feat..

Of course - Rolf wrote it. Zlib uses a "running" Adler32. See here for an good explanation of the difference.

Exactly. If we are going to put type information in the JSON stream purely for readability and type checking, shouldn't we also put type information about EXT, DB, SGL, etc.? This just looks to me like a solution looking for a problem.

You know that "refnum" is short for "reference number", right? A file refnum is just a number. In fact. It is the file reference returned by the OS. Same with, for example, TCPIP. It just strikes me that this is a bit like adding the TypeDef information into the JSON stream (e.g Control. TypeDef, StrictTypeDef) which is interesting, but not useful. Let's assume that having specific LabVIEW reference types defined as objects is desirable. What does the LVType:ByteStream give you that the cluster wired as the "template" doesn't? How will you be able to tell that a DAQ Task ID is a UserDefinedRefnumTag rather than a physical channel? What will the cluster template for the variant decoding look like? DAQ Task IDs are not refnums. In fact,they are the same for all IO (like VISA) - a typed string like "path". If you plonk a DAQ Property Node onto a diagram you can quite happily connect a string to the "ref" input (which stands for reference, not refnum). You'll see a conversion dot as it gets converted to the Task ID type-same goes for VISA references. Are these "pre-thoughts" to object serialisation? Here, There Be Monsters.

They don't need to as the equivalent of refnums in other languages are pointers (generally) and therefore integers. It is only because LabVIEW is strictly typed that they get their own type.

Refnums are numerical types in all languages (even labVIEW). However, Whilst it may be "convenient", I have reservations about injecting labview specific formatting into a language agnostic serialisation.What if a string contains "=>" ?

I paste code snippets from C, ini files and SQL on the diagram so, # isn't a good choice for me. Not saying you can't. Just saying it's an arbitrary choice what to use as an identifier and this particular one has drawbacks (and you can't change it). Using the built in system won't get me any benefits. In fact it will limit it's use to LV2013+ (I use 2009 by choice). Besides, PP doesn't just do tags. You can also see if VIs have default icons, are broken,descriptions and history filled out, FP hints, descriptions etc. Tags are just a small part. and everything else requires opening the VI anyway.

Hashes are not a good choice as people use it as a shortcut for "number" or "hash" and it adds noise to the listings. The "tags" are definable in the PP, so you can use what you like but they have to be enclosed (tag), [tag], (my favourite) ~tag~, #tag# etc. But you could have #tags (methinks there are too many twitterers - or is that twits - at NI) Additionally you can assign different tags, different meanings. For example I use [tag] as "Requirements" (ala the NI requirements thingy) for calculation requirements coverage. I really must get around to productionising it. It's the "help" document that's putting me off as it will be huge due to the features, which are easy to use, but take a lot of words to explain-like the plug-in system and custom queries.

Hi SDietrich It seems the libpq.dll has a load of other dependencies. When loading, it couldn't find libintl.dll. Looking at the website, the binary download is 44 MB so there are a few more than just libintl.dll. I downloaded the zip and there were a few wxwidgets DLLs that you probably don't need, but there were the libeay, zip and a few other binaries (including libintl.dll). For an out-of-the-box experience, some of those will need to be bundled too.

Simplest way is to use vbscript to press buttons on the FP.

Maybe create it as a plugin filter for Bitman. I always found Vugies Bitman is far superior in rendering performance for anything I do in 2D.

Hi SDietrich. The DLL isn't in the package so I couldn't check, but I looked at the CFLNs and they are set to re-entrant. So did you compile with "--enable-thread-safety"? (otherwise it will have to be run in the UI thread). A note in the description of exactly what platforms/labview versions you are supporting would also be useful (Windows, Linux, Mac, VxWorks etc) For Windows users it would also be of benefit if you say whether you are supplying just the 32 bit or both 32 bit and 64 bit DLL (LabVIEW x64 cannot load 32 bit binaries and vice versa). jgcode is the Lavag Tools Network admin. Send him a PM and he can advise on how to get it on the tools network under the Lavag banner.

The scene object has anti-aliasing which is used in the 3D Graph Controls. Create a scene object and select "Specials>Anti-aliasing"

I think the OpenG Scan Variant From String is obsolete since JSON to Variant can handle all types now (apart from refnum and path-which are easily added). We should consider removing the OpenG Scan Variant From String completely. I would also suggest that for the unknown data type we output a string type and raise a warning rather than an error..

So that's a no then-there is no equivalent (I also couldn't find one listed). You have to write a wrapper whether your choice is DLL or .NET assembly.

Labview has no way to create callbacks that can be called from external code (the exception being some .NET functions). You need to create a dll wrapper that supplies the callback function and proxy it via a LV prototype (e.g. an event using PostLVUserEvent) which can then be used to get the callback data. If there is an equivalent .NET function, you maybe able to use the callback primitive in the .NET pallet to interface to it.

If you are as impressed with Inno Setup as I am (couldn't live without it). you might consider a donation.

Use the OpenG variant config to save the clusters to a normal ini-file then run this on it (you might want a little more error checking). Split-Ini.vi

Edit: Yes. What Phillip said.

I concur. Make sure you get the GUI which is separate (Inno Setup is the script engine).

Well. The ant-pedant in me ( ) would qualify that in respect to it is inherently secure at the application boundary. There is no software defence for a post-it note of the password on the monitor. Copying is not an issue, per se. It is the clearing of the memory locations and I don't know either way if LabVIEw does that. It is, however, swings and roundabouts since the key has to exist at some moment in time, in memory, so it is a case of reducing the persistence so that capturing at exactly the right moment on random off-chance is unlikely (not impossible, just unlikely). Of course. If there is zero cleanup, the keys can still exist for quite some time even after the application has terminated making them much easier to capture (until the OS decides it needs it for something else). So LabVIEW probably doesn't score well on that front. But more generally you get more bang for your buck by defending the edge (application/OS/network/buliding) and reducing the opportunities and attack vectors rather than trying to mitigate aspects that require enormous effort and skill levels to make the attack effective. Saying that. The SQLite API does clear all its keys immediately after use, but that's not a lot of consolation if LabVIEW holds on to the un-hashed password string like a drowning man to a buoy Probably the best you could hope for is that LabVIEW clears its memory when it exits so then at least an attacker would have to have the software running after you have entered the password. However, if your secret data is so secret that you are worried about determined adversaries getting the keys from memory, it is better that they just don't get to run your software at all (lock the office door).