ShaunR

So. Who is using a VPN on their Android or iOS to connect to their LabVIEW software?

Does this mean you have never used this method but if you were specifically asked to, then this would be a proposal? Yes. That is clearer. You have a (XML?) protocol that contains security tokens.

When you talk of "Package" are you talking about software updates to the cRIO?

This is demonstrated in the shipped TCPI/IP examples with LabVIEW. You are effectively creating a simple proprietary protocol with a single header field of "Data Length". Transport extends this further by adding a timestamp, encryption and compression flags to the header.

cData can be passed as an array of U8 and you avoid all that.

A VPN will help to mask your IP and traffic will be encrypted for the entire journey only if both ends are within the VPN network (note I'm not using the phrase "end-to-end" here). If you use a 3rd party, they will potentially have visibility of all traffic so it would be the same trust issue as a cloud service. This probably isn't an option for VxWorks targets as you are pretty much stuck with what NI have installed.

Because it is far more pragmatic to remote into (and send data out of) devices in offshore oil rigs than it is to send a survival trained engineer via helicopter.

what about for cRIO or PXI?

There is an API for interfacing to RDS. As it is a session based system you would need to get the session information and use that to create a unique ID to route your data. Your channel setup process is an almost exact description of the Dispatcher handshake. I notice you have only specified a single connection to a client so I think for network streams the end points are dedicated to either writing or reading so it would be uni-directional only. You are also missing the "dealer" in your description that needs to copy the data to each end-point if there are multiple clients to a single service. That may or may not be a requirement in your case but most of the time it is needed and you might need to consider control contention if multiple clients are to ultimately all have bi-directional or reverse control channels.

I've often think about security of my LabVIEW applications but I haven't seen much discussion in the LabVIEW community and almost never see consideration given to securing network communications even at a trivial level. So I am wondering...... What do you do to protect your customers'/companies' data and network applications written in LabVIEW? (if anything). How do you mitigate attacks on your TCPIP communications? What attacks have you seen on your applications/infrastructure? Do you often use encryption? (For what and when?). Do you trust cloud providers with unencrypted sensitive data?

You will have to wrap the existing functions too so that you can call them. A better strategy may be to create a separate DLL that just provides a call-back pointer that wraps and invokes the LabVIEW user event. You can then pass the opaque pointer to the existing DLL and get the data in an event structure. You wouldn't need to wrap all the existing functions for pass-through then.

You need a diffuse light source and it helps if you put some black tape on the opposite side so it doesn't get washed out by the ambient light. If you do it right, the meniscus should be a lot brighter and you will see the tape change from colour (where there is liquid) to black (where there is air)

1. Change the title of the topic to something descriptive of your question. 2. Shine a coloured light up through the base of the column.

Turtles and elephants.

Creating libraries and reuse code is the fun bit that everyone wants to be part of. Maintaining and supporting them is the soul destroying part that usually spells the demise of a project and gets no thanks. Good luck. It's a worthy cause.

We can't see the real question so it may just be a trivial task to generate the numbers - which doesn't require binning (sorting or range checking.) The OP needs his LabVIEW eureka moment so non trivial solutions not directly addressing the question will just be confusing.

That is one event structure in a block diagram, surely?

This whole thread (and there are others) is about users being unclear as to how to attribute OpenG components they use. It is never clarified by an authoritive source and there are proposals to automate salutations with scripting etc. That will not work for LGPL because of the distribution component and until this conversation I expect many didn't even know there were other licences included apart from BSD. My view isn't from protecting the IP and which licences to use. It is from using a single licence type throughout and preferably one that only requires attribution - BSD fits that requirement and is ubiquitous within the toolkit whereas LGPL doesn't and isn't. A single licence type throughout is just common sense from both an administrative and pratical point of view. Deciding on MIT, Apache or any other type is also a non-starter from this viewpoint since it is a rationasation/simplification process not a "lets let the tail wag the dog" At the end of the day, though. I don't have any skin in this game. I don't use OpenG for exactly these reasons and am old and ugly enough to have written similar functionality in the past that I have complete control over for the few that I might need. These sorts of issues are barriers to adoption for someone like me so I am no worse off if nothing changes but could be better off if they did. None of it is a show stopper for me as I just rule out OpenG as I do ActiveX and .NET. In terms of sending patches.I don't think anything is needed. Changing licences is a documentation issue, not a coding issue and only the author has the authority to change licence terms. So it is pretty much a case of your licence; your call. I've laid out my arguments and others have voiced their confusion and I expect that is now compunded by highlighting the LGPL components.

Nice work Rolf. I think the way to look at this is probably that it is bringing the last, outstanding, non BSD code into line with the rest of the toolkit - completing, or continuing a transition that was decided many versions ago. Your contributions are particularly problematic for others to assist with since they generally require a knowledge above and beyond just LabVIEW and therfore the skills are few and far between in the community. This tends to require us to rely on you mainting your code without assistance which is obviously a heavy burden. I think if you just addressed the code that is under your licence terms specifically, then you would be absolved of any further responsibitlites. It would be up to the OpenG maintainer (whoever that may be) to decide how to proceed further, if at all, in regards to an amalgamated licence and pruning of depricated or unreleased software - your transition would allow them that ability without caveats. In terms of your effort; that is probably something you would need to discuss with JGCode, J Kring et.al as to process but I don't think it is effort intensive. I transitioned from Creative Commons simply by up issuing and releasing into the source tree. I'm a little suprised and dissapointed that you say OpenG is no longer actively maintained. I think there are a lot of people that rely on OpenG. P.S OpenG Pipe library- Please release this proper. Pretty please with cherries on top? This is far too valuable to let wither and die.

The end user of OpenG are developers making executables that may be distributed or more tools for others so yes, they do have distribution obligations under LGPL.

Well. Whatever components are LGPL, the author would need to release under a different licence. Alternatively they can be replaced with other, non LGPL versions if available. Someone has resposibility for maintaining builds. It was JGCode the last time, i recall. Zlib doesn`t require a salutation. It only demands no misrepresentation or removal of existing. Unless source is distributed, i see no requirement to distribute a licence, although a mention would be nice, i agree.

With NI, they all get installed with the run-time engine. Unfortunately. With licencing, you need to split hairs. LGPL is as obnoxious as my Creative Commons Share-Alike It puts an onus on the end user which means intermedaite distribution cannot cover the licence on the end users behalf. For the risk to the end user I would seriously consider rationalising all the LGPL and/or GPL to BSD if it is an option and, if a single licence that references all the contained licences could be produced so that only a single text file needs to be distributed by users of OpenG - that'd be swell

Incorrect. The end userr of the OpenG toolkit has a duty to redistribute and make clear the licence terms with LGPL that is far beyond other licences. Can't the remaining LGPL be superceded with BSD?

There are some LGPL in ther stiill, though, right?

Well. It depends if you are a LabVIEW island in a C [sic] of programmers. Then you only have to learn that you *must* specify the DLL function prototypes and keep shouting "Threadsafe, Threadsafe, Threadsafe" until their ears bleed No need to learn C/C++ then I think every LabVIEW programmer should have a pet C programmer