Leaderboard

Hi, I figured people here may be more interested in this project. I have some cool graph extensions I'm building in an open source project, which make some nice graphical overlays for XY graphs and waveform graphs in LabVIEW. I've got a github page where you can grab the code, support the project or just have a look at some of the same screenshots. Everything updates live in the graph, so you really need to see it, to get how it all works, so here you go: https://github.com/unipsycho/Graph-Extensions-LabVIEW Please star follow the project if you want to see this developed and I'd appreciate any feedback or ideas to extend it further. The markers are very much IN development right now, so no where near finished, but the tools can still be seen working. THANKS!

Well. A bit off topic but deserves a response. Two points here. . They have already figured out how to identify and merge differences. In fact they figured it out a long time ago, then stopped. That's 80% of the problem already solved, IMO. I've said before and I'll say it again. I don't care that the features I want are hard. It's closed source, paid-for software so it's up to NI to figure out how to make it happen; not for you or I to be technical apologists for them. Anything is possible with enough resources, time and the will to do it. The only thing lacking is the last one. As far as I can tell,. NI stopped doing hard or interesting stuff in LabVIEW around 2009 (maybe even 8.x) and have been serving us IDE placebos ever since - just look at whats been implemented from the idea exchange!

Okay a couple more things I learned. The first is something already does happen when you change the type on your VIM, two VIs are ran, <LV Install>\resource\GenericLabVIEW\GenericLabVIEW_AdaptToInputs.vi and optionally <LV Install>\resource\GenericLabVIEW\GenericLabVIEW_GenerateCode.vi If you look at some of the XNodes posted in the code repository they follow the same design. Basically if you re-wire a normal XNode, then the adapt ability is ran. Now if the data type of a terminal you cared about changed, you may need to go regenerate the code. Just like our XNodes, this VIM works in a similar way and these two VIs are ran, with the second one being optional. Next I also discovered something that basically breaks VIMs, but I think they are intended to allow for making some inputs adaptive, and some not. Imagine you have a delete from array, like the OpenG ones. It takes an array of something, and an array of indexes. If you turn this into a VIM both inputs are adaptive, but that isn't what you really want, indexes should always be an array of I32. Well if you put on your front panel of a VI a control named "Generic LabVIEW:Adapt To Type States", have the data type be a 2D array where columns 0 is control labels, and column 1 defines what that control should be. I believe FT means fixed, and unspecified are adaptive (which is why all inputs are adaptive by default). Of course when I go to use this it doesn't do some other things properly, like icon, and terminals aren't right so this isn't very useful yet, but I was just so excited I had to share, even if it doesn't do anything yet. Of course even if you do get some inputs adaptive and some fixed, you still have the issue of limiting some inputs to say scalar, or say 1D array but no other size. That again is where the flexibility of XNodes is needed at the moment.

I think it is a Linux cultural thing compounded by young basement hackers, personally. I saw a discussion somewhere where an application developer likened most programs written by Linux people today to a game called "Mount Your Friends". Seeing the go-to "architecture" (and I use the term loosely) of writing applications is to pipe and string together, program after program and hack upon hack , with the mantra "it works so it must be good" - I'm inclined to agree with them The Linux world has the cleverest, most intelligent and awe inspiring coders and programmers that there is. I'm humbled by some of their abilities' to put advanced mathematics and theories into code........ but they couldn't write a decent or user friendly application if their life depended on it .

Today I inherited some LabVIEW code created by an external consultancy. Whilst reviewing the quality of the code I came across a series of subVIs which are indubitably OpenG VIs with the license information stripped out. One particular instance is a VI called "Variant to Header Info.vi" and the front panel is identical in layout and size to "Variant to Head Info__ogtk.vi" except the license text is missing. The VI icon is identical, and the VI description word for word. There's no doubt in my mind that this developer took the Open Toolkit, stripped all the licensing out, and is using the code in their own distribution without honouring the license agreement. Is this something I ought to follow up, or does this happen a lot these days?

I usually gently point out these "discrepancies" if I have firm suspicions and give them the opportunity to rectify it and/or respond. They may have an agreement in place or they might have received the code in good faith but were not as diligent as you were and have been caught holding the ball. I'm fairly lenient with individuals and ignorance but can't abide business decisions that produce this situation. After that, it depends. I might ask the supplier if I can check with the original authors to see what their reaction is or I might tell the authors straight away-it really depends on their reaction and who they are. An expletive ridden email response telling me to insert parts of my anatomy in various orifices will definitely result in the latter with supporting evidence after several hours of investigation of all the software they have ever written, to boot. Does it happen alot? Not really in the LabVIEW world-much more in other domains. Most of the time it is an oversight or some engineer somewhere hiding a lack of ability from a boss. Corporate misappropriation does happen but it is an exception rather than the rule. It's happened twice to me with my software and both times a gentle nudge resolved it with no drama. Generally these things are a bit like witnesses at road accidents-noone wants to get involved even though they should.

So it looks like I won't be able to continue my LabVIEW development in the near future (or at least have a major break) *sadface* Is anyone interested in continuing development of the project? It is now at the point where all dependencies to web services have been removed and replaced with web sockets. That means the page for the front panel can be viewed via file:// protocol and doesn't require a http:// any more. Web socket connection is established to a configurable port. It can handle multiple clients (how ever stupid that may be to give control over a single system to multiple users; makes sense if they're all indicators). It supports a bunch of common controls that can be represented as HTML5 and it supports representing any control as an image. I've implemented a basic config editor that can be used to select if a control should be represented as HTML or image. Current version is attached. FPPublisher.zip