ShaunR

I just tried it with a Delphi program and it worked fine. Make sure you create the file as "Shared" so the LabVIEW application can open it.

first decide if it's a library, Framework or Toolkit (I would suggest it is a framework since you have to write custom messages) IPC Message Framework/Library/Toolkit? (boring but descriptive ) Graphein Framework/Library/Toolkit? (I like this one ) Tiezi Framework/Library/Toolkit? K̄h̀awsar Framework/Library/Toolkit? (and other non English transliterations of message) The Doctors Message Framework/Library/Toolkit? Powells Post Office Framework/Library/Toolkit? Personally, I would stick with what you used to be happy with if it wasn't a typo.I fight with NI all the time about the tools network and you can say "no thanks, I'm happy as it is"!

Yes. I think you will be a little surprised when you come to do this as it probably isn't doing what you think it is (as Ned is trying to explain). Yes. It creates and then writes because you need something to read otherwise it would be an empty string or error (there is no CreateOrOpen equivalent). ...And Yes. "Open" is equivalent to OpenExisting(string mapName) in C#. Similarly, "Create File Map" is equivalent to CreateFromFile(String, FileMode, String, Int64) - I think they term it "persistent" mapping. Likewise, Create Memory Map equates to CreateNew(String, Int64, MemoryMappedFileAccess) which I think they term Non-Persistent mapping . I think that's right at least. The VIs use the windows API rather than .NET so the call names are bit different. So you'll create your file map in your C# probably using "CreateNew" with READ/WRITE permissions and a certain mapName (it doesn't have to be persistent and on disk) and then you'll "Open" it in LabVIEW (with READ permission) with whatever "mapName" string you gave it in the C# CreateNew method. Error -80002 just means it couldn't open a mapping either because a map with that name doesn't exist or because it doesn't have the permission to open it.

Events (or listeners) don't have constructors. It's a bit of a shame you have invested so much in C#. You could have just used this which probably does a lot of what you want. At least it could show you how to interface to it as a kind of tutorial. Ultimately you are going to hit a brick wall, though. .NET doesn't run on myRIO (Linux Real Time)

I'm going to go out on a limb here and make a wild assumption. You are trying to use the skeleton face tracking, right? So, because there is a C# example, you coded that up and got it working. Now you have some C# code that gets data from the SDK API, but want to get it into LabVIEW somehow. Am I close? Well. I think you have made things a little bit hard for yourself because you used C#. LabVIEW can interface directly with the API and you can use the callback function (.NET callback) to get the data into LabVIEW directly without jumping through hoops. The issue is you have isolated the data in your own monolithic program and now have to use some tricks that are quite advanced to get from there into LabVIEW. So you either write some C# code to re-transmit the events through your code to LabVIEW (which we have talked about, but isn't trivial) or just access the events directly and not bother with the C#. The SDK has the event KinectSensor.AllFramesReadyEvent. You should be able to hook that directly with the .NET callback and therefore you don't need to write your own events or messages in C# for LabVIEW (there are examples shipped with LabVIEW for demonstrating the callback - NET Event Callback for Calendar Control VI in \examples\comm\dotnet\Events.llb and NET Event Callback for DataWatcher VI in labview\examples\comm\dotnet\Events.llb).

Short progress update...... Having a bit of a problem with installers but hopefully will be uploaded next week.

Couldn't resist

Don't go sending nasty text stuff to me (I can only read pictures) There are examples of how to use the VIs for the two modes of operation (memory and files) and some details in the "context help". That's it for the docs . The secret ingredient you may need is PostLVUserEvent to address signaling from your C# module. I know little about C# apart from it's basically .NET (which I vehemently avoid as much as much as ActiveX) so you may be able to use a .NET callback instead if you compile it as an assembly. However, if you are going to do that then why bother with memory mapped files?

Ah. This is a completely different beast to DMA (Host to Target). Here is a LV version of memory mapped files (for windows) which will enable you to speak with your C# MMF in LV. You will be no closer to getting it into a myRIO, although you could replace the OS calls with those for the linux mmap if it's supported..

I don't think many will realise what a great Xmas present this is but I do and thank you for the change.

What a bizarre workflow. Are many people doing this? I leave code at - what could you call them? micro checkpoints?. Points in the day to day development that you can draw a line under and say "that bit is working". Maybe not enough of a leap forward to warrant a commit or tick off a milestone. Maybe even a test to "see if it flies" sort of thing, but a meaningful juncture in the development. If it means I have to go and have a coffee or chat with other developers for 1/2 an hour before the end of day-so be it. If it means an extra hour or so after the end of day, so be it. I suppose if you are a militant clock watcher, then I guess you just drop your tools when the bell rings regardless of the state of the code. I don't have any issues remembering where I am in the code on a day-to-day or week-to-week basis but for commits and at the end end of day, the code is never broken and the recently used lists usually has the last VIs and projects I was fiddling with.. It reminds me of an argument I had once about the trunk in SVN. A colleague said that it was ok for the trunk to be broken and waved some kind of book in my face that apparently was the word of god on the subject. My position was that he he was nuts and should stay away from my repositories but I fell short of telling him what I would do with the book if he broke any of my repository trunks

Python?

Ah Yes. Sorry. Kind of slipped off the radar what with Xmas and everything. Yes, yes, yes. I actually have a later version which updates Transport.lvlib shipped with the latest version (for Version 1.1). That gives dispatcher the compression (zlib) and compression/timestamp information like so. The Get Subscribers was removed as it was not intended for Users (more for internal use - which it never was) and just leaks information that could be exploited. There were a few more tweaks and bug fixes (including the one reported) so there will be an update. I'm just umming and arring about an installer (e.g. putting into a VIPM package) ATM. I've been burned badly by VIPM so am tempted to use my wizard instead. So once the grog has worn of and the hangovers have subsided; I'll upload (just after Xmas but before the new year).

Be careful. The table is here. NI just say they haven't tested on those platforms. I know for a fact that even LV2009 works on 8.1 and it is difficult to see why any of them wouldn't although addons, toolkits and DAQ may be sensitive. Even 2014 is only listed as "Partial" so just be aware of the specific claims.

You do know that your managers will probably read this, right? I think consolidation is your key argument in this kind of environment. The premise is that it is cost effective to rationalise/consolodate the myriad of versions into one version for production benfits. As NI don't sell any other versions than the latest, that means upgrading to 2014 at time of writing. Shame eh? First step. Talk to the NI rep and find out how much it will cost to consolidate all the versions and how much discount he can apply (important for the bean counters later). Push him hard as he will want the sale as much as you want to upgrade so he is a great ally here and you can use some of his sales BS when you argue later internally. Get him to give you two quotes. One with the prices for upgrading individually (which is a single seat full licence per person-don't forget all your addons) and the other with his best offer. This is the accountancy "saving" you can show the bean counters later Make sure an SSP is also included as an optional line item. Then onto the convincing Espouse the merits of a single platform and the advantages of having a single version in terms of maintenance, deployment and upgrading test facilities. A powerful argument here for production is downtime. Center the argument around cost saving in terms of product not being produced (rather than programmer effort -you are cheap, product is not ). Point out that whilst upgrades are being tested; they have to be tested for each version (multiplying test station downtime by LV versions). The corollary is that a single platform only needs to be verified and signed off once and can be deployed to multiple stations (Replication of effort across multiple disciplines). Really emphasise the effective cost of sign-off too. That multiple disciplines must be involved so deployment resource is multiplied outside of just a puny software engineer and may involve expensive resources like quality engineers, production and maintenance engineers as well as the great god Project Manager. Basically you argue that everyone (production, quality, management, maintenance, bottom line) will benefit if they upgrade and look what a fantastic offer NI have come up with for a one-time consolidation package (show the two quotes) I think you get the gist. Once you have argued those kinds of points with management and techie types, then you can woo the bean counters with all the free goodies you will get that they would have to buy anyway but you can get for free if they do this "one time consolidation" like "Database Connectivity, Desktop Execution, Report Generation, Unit Test Framework, and the VI Analyzer Toolkit." (thanks for the list Hooovahh ) Show them the quotes as what they have to pay if they do it now or when they have to later. Explain that if they get the SSP too, we will not have to worry about this again next year and we can roll it on ad-infinitum (this is a different budget ) . Any counter arguments, steer towards the SSP. This is your sacrificial "feature" which you may get if you are really smooth, but really not that bothered if you don't. Just make sure you steer all financial arguments towards buying or not buying that to deflect from consideration of the upgrade. I hate politics.

Sorry Jack. Everything will be fine if only we had X,Y Z is just adding more goo to a sticky mess. I think this discussion needs to be taken to another thread so as not to derail the OP (any further?) as there are some very simple premises here that are being conflated.

The source is available from sourceforge as well as the executable.

@JackDunaway Great analysis with which I agree with 99.9% (except for your first sentence). You are skirting around a couple of fundamental issues, not directly to do with LVLibs but with LVPOOP and are the reasons why LVLIbs fall short of expectations. I think you have seen and hinted at, but not articulated, though. 1. it is impossible to create LVPOOP components with zero static linking (this is trivial with an open VI and a LLB full of functions which can be loaded and unloaded dynamically). 2. A function per VI is a purely semantic imposition for dynamic dispatch. 3. With the exception of namespacing with paths, classical labview programmers only have similar issues by bad architectural design rather than language imposition and can always avoid the issues by best practices and frameworks. Food for thought: If huge amounts of analysis and tribal knowledge is required to not write bloated, unscalable and buggy code with a certain tool. Is it not a better strategy to just not use that tool?

Absolutely. I think most of the file stuff is in the Win32FileIO the only extra would be a Device IO wrapper for mounting and unmounting for which the c code gives the prototype. Might even be able to use memory mapping, I've never tried it with a raw image but it may be possible to map the device.

From Windows? (I presume, since you mention Cygwin). Easiest is probably win32diskimager but it may be too manual for your test system. If you have gone to the extent of installing Cygwin, then I would try to figure out why dd didn't work (don't forget to unmount before trying with dd).

OK. I'll take a look at the weekend.

Well. If you abandon LVLibs, you will only have a directory of VIs which are very easy to cross link and not as easy to distribute or organise as well as no namespacing or private scope. If you want scope, put them in a class. For dynamic loading plugin distros, LLBs are great because they are monolithic containers that don't load everything into memory unless linked or loaded explicity . For identical to LVLib without the [arbitrary] bits you don't want-probably asking too much.

They fell out of favour because they hide VIs from source control rather than any bugs or funny behviours. However, VIPM can pack directories into LLBs so it's not that much of an issue anymore for most people (can keep directories for development if its an issue). Your animosity towards them is unfounded

Unless VIPM is involved, I Use LLBs instead.

Find the IE shortcut in the start menu. Right click on it and select properties. There is a field for you to define a shortcut key which is currently set to None..