ShaunR

Perhaps Jason can confirm the algorithm. But I don't think the graph controls just decimate in the strictest sense. I think they do something like bi-linear filtering since small artifacts are not lost-as would be with pure decimation. Long term data logging is better served by a DB IMHO. Then it's just a one line query to decimate and you can have a history as big as your disk allows with no memory impact.

The issue is this. The risk is very high that they will try and renege of the agreement-they have all but admitted that. Even if you do put a watertight clause into the contract, it is highly likely they will contest it anyway. So you will need deep pockets to defend it in court to get the money you are owed. If it is a large corporation, they have departments dedicated to finding holes in contracts and arguing the toss of every penny. They will use it to get more concessions out of you by - nit-picking at best, by threatening at worst. The sort of corporation you want to do business with are those that only send contracts to their law dept as a last resort, not first resort. Which do you think they are? Your first defence should you choose to work with them, is of course, the clause in the contract (choose any from the open source contracts, they all disclaim liability). This is really a management bargaining tool, however, so you can point to it and say "that's not what we agreed". If it goes further than that, then you incur huge expense so you really need a company that is prepared to take that risk in the first place and not go further. Your last defence is Limited Liability Insurance or Professional Indemnity Insurance to stop them taking your house, car and dog if they win. That' the risk of all consultancy work. It's just better for your health, wallet and integrity to politely decline any companies that have a history of serial disputes with consultants, Get a good lawyer DISCLAIMER: Not legal advice, not a lawyer, not even particularly good programmer-make of it what you will

I suggest a you avoid them like the plague.

I too have never experienced it. But I remember Daklu writing an example (on lavag) to prove me wrong and that it does really happen.lol Maybe the Lavag historian can find it-I cannot currently I vaguely remember that the reason that I never see it, is because my workflow is to have all the VIs in memory. IIRC, when you change a typedef, the VIs not in memory are not updated,(of course) and so the change is not propagated., When they are next loaded labview isn't able to resolve the discrepancy and resets them to the zero value. LabVIEW is able to resolve the difference if the new value is at the end, but not in the middle. So I think I suggested having the old-style VI Tree just so that you could force LabVIEW to load all the VIs. Since my workflow is to produce examples that act as regression test harnesses, the examples keep all the VI hierarchy in memory so I never see it.

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.