LogMAN

I agree to what @ShaunR said, but let me add to it: The library is not dead, because it is still functional and very useful - especially for new developers as mentioned earlier. The project, however, is dead. As you correctly pointed out: Technically anyone could fork the project (on whatever platform - SourceForge / GitHub / BitBucket - you name it). Development could even continue under a new name (probably even the same?). Yet the number of licenses being used right now is impossible to maintain, even for experienced developers. OpenG is also tightly coupled with lots of services (i.e. NI and VIPM link to the official repository on SourceForge). To my understanding (although I don't have facts on this), the lack of response in the main repository is the reason to why libraries like MGI were found in the first place. Just look at the bug tracker https://sourceforge.net/p/opengtoolkit/bugs/ This is also not the first time we discussed the (possible) future of OpenG. Here is a thread from two years ago: The complexity of the main repository (i.e. the folder structure) also sets the bar very high for novice contributors: https://sourceforge.net/projects/opengtoolkit/files/ And let's not forget the difficulties in comparing VI revisions in general. All things considered, the project is not a simple task anyone could just pick up and get going. Lot's of things need to be considered, which requires lots of experience in LV. Of course, most experienced developers have no interest in contributing to the project if it involves lots of administrative tasks on top of their regular job. Maybe a shared library like OpenG is not the right solution for LV. A simple place to share VIs might be easier to manage and contribute to in the long run.

We used the OpenG library a long time ago, when LabVIEW was still new to us and we could leverage the power of OpenG to accelerate our development (between LV6.1 and LV2009). This is in my opinion still the strongest point of that library - it provides new developers (or teams) with lots of useful functions at the cost of dependencies. We have since walked away from it due to incomprehensible copyrights, lack of updates (although it is very stable) and generally because we used few functions to begin with (i.e. Fit FP to largest decoration, filter arrays and some string manipulation). At some point the dependencies mattered more than the benefits. What we needed was rebuild in our own library, removing all dependencies from OpenG. If the OpenG library were to be cleaned up, just removing functions is not a good solution because it breaks compatibility for anyone who depends on it. On the other hand, dependencies between the libraries can easily be removed. For example, there is no need for OpenG String to depend on OpenG Error anymore. Instead OpenG String could be updated to remove the dependency (using only native LV functions) and still keep OpenG Error in VIPM. OpenG Error on the other hand is technically unnecessary nowadays (as pointed out by @smithd above). This library can be archived (while keeping it in VIPM). Here is what we do with our libraries when they become obsolete: Remove obsolete VIs from the palette (but keep them in the vi.lib) Change icons and documentation to highlight obsolete VIs (similar to how NI does it, by adding red color to the icon - the more the better) Explain in the documentation why the VI is obsolete and how to replace it Add replacement code to the block diagram of the VI Remove password protection Enable inlining if possible That way, when you come across obsolete VIs, you can simply use the "Inline SubVI" command to replace it: https://forums.ni.com/t5/LabVIEW/Inline-subvi/m-p/1279086/highlight/true#M532443 Of course, sometimes changes may destroy the block diagram of the calling VI, which is why those VIs have password protection removed, allowing the developer to inline the VI manually.

Please share ? Amen. I was working on a nasty bug for the past few days as well. The source code looked fine, but the application didn't do what it was supposed to do (or so I thought). As it turns out the executable did exactly what it was supposed to do. And I was looking at the latest code, testing old software... Reminder: 1) Always include und update the version number in your executables (and configuration data if possible)! 2) Work with the source code you used to make the executable! 3) If you are experienced enough to skip points 1 and 2, see points 1 and 2!

Yes, at least since 7.1, maybe earlier.

Sorry, my bad. I didn't see the "Something went wrong" message, thought we were talking about the "Optional Profile Information".

This is awesome! Thanks Michael I see the same notification using regular login (email + pw). Caching doesn't seem to be the issue. There are likely some new parameters which weren't available in the previous version. Edit: Here is a capture of the requested settings (it says "optional" but if you click "Skip this step" it will continue requesting info): Update: Pressing "Dismiss" on the notification seems to work for me

Are you looking for something like this? https://docs.microsoft.com/en-us/windows/desktop/api/wincred/nf-wincred-creduipromptforwindowscredentialsa

Here is a KB from NI on this subject: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P7qjSAC

Which font do you use? On Windows we have "Small Fonts" which is the only readable one. Something similar should exist on Linux.

If anyone is interested in finding incorrectly connected Constructors automatically, here is a VI that will do that for you: It's not very fast, but it does its job. The result is a list of VIs with the total number of Constructor Nodes found and the number of Constructor Nodes where the first terminal ("new reference") isn't connected. This is an indirect solution because the offending terminal officially doesn't exist (not accessible via scripting).

Thanks for reporting @_Mike_ Turns out the terminal adjusts to the object type (object or enum). In your case the Constructor is for an enum type, so it actually returns an enum instead of a reference. Here is another example: This is the corresponding definition according to Visual Studio: Very interesting behavior indeed.

@Darren Would you be interested in adding another detail to the CAR? Just for fun I went to see if I can break other nodes and actually got strange behavior from the Call Library Function Node in a very similar way (using LV2017). You can connect the "path" terminals, even if the option "Specify path on diagram" is not checked. I understand that this is probably a design choice to prevent wires from vanishing when unchecking this option and it doesn't do any harm, but the wire should break. Unfortunately, the output wire doesn't break initially: Notice: I just placed the node and connected the wires. The options dialog is open to show the checkbox is actually not checked. Here is what I get after pressing the "OK" button on the dialog (you don't have to change any settings for this to work). You can see the wire is now broken, as it should be: This is only a cosmetic problem because the function breaks as soon as you press the "OK" button. The behavior is strange nonetheless.

Thanks everyone! It's good to know I'm not (yet) going insane Sorry for not mentioning how reproduce the issue in the first place. I suppose one reason this never occurs to anyone is because we all start wiring from the Constructor Node for obvious reasons, except sometimes we don't. Awesome, thanks for sharing! I'll inform my team to keep this in mind.

Okay, I just finished testing on various machines (virtual an non-virtual) with various LV versions and all of them support this feature! It is very unlikely that we somehow broke all machines and versions in our department for the past 15 years exactly the same way (although there is always a chance ). Find attached more snippets for all versions I checked (for 7.1 and 8.6.1 I had to take screenshots). I've also attached the VI for LV2017. So, in total I've positively tested these versions: 7.1 8.6.1 2009 2011 2013 2015 2017 Unfortunately I currently don't have a 2018 Installation to check. It works just fine. We can load, edit, build and execute the project and all executables. Darren, which version of LV have you been using at that time? Could this possibly have been changed in LV2018? Constructor Terminals LV2017.vi

Thanks for looking into this Darren! On my machine these terminals are permanently available even after a reboot and with a new VI. I just removed all VIPM packages and cleared the compiled object cache, restarted LV and still can connect those terminals. Also tested this on a different machine and got the same terminals. This is a very bad sign indeed, I don't see any warning whatsoever. This means it's either a bug in this particular version of LV [15.0.1f10 (32-bit)] or my installation is majorly broken somehow. Not sure what could have caused it though. Unfortunately I can't do that. My application builds perfectly fine (no broken arrow, no exception, no error) while connected to the wrong output terminal. This could potentially be harmful if it somehow effects memory. I'll check if this is still an issue with the latest (f12) or one of the previous patches.

So this just happened to me and I'm quite confused by it. As it turns out, the .NET Constructor Node not only provides terminals for error in, error out and the reference, but actually two more "hidden" terminals: Notice: I left the error terminals untouched and none of the wires are connected (try it yourself). This never occurred to me. Only now, while hunting a null reference exception I found the constructor node looked "off", like this: The strange part is that the terminal doesn't actually carry the reference (which is why I receive the null exception). It only specifies the type. The upper left terminal is a void type input, so the wire is always broken. Does anyone know why these extra terminals exist? They don't seem to be part of the specification as far as I can tell. Any fancy things we can do with this?

How about a fade animation for switching between FP and BD? Or slowly connecting wires with some sparkling effect at its current position? By 2020 Hollywood will use LV for the next generation of CGI, just wait for it

Absolutely. We still use LV2015 for our projects, even though newer version are "superior" in some aspects. Still wondering if there is anyone at NI actually using LV/NXG for real-world applications nowadays. From my perspective, design has become much higher priority in newer versions than responsiveness did in the past. My dev machine is equipped with decent hardware and still LV2017+ and NXG feel slow. The kind of slow where you wait for some freaking animation to finish, not the kind of slow where the code runs slower... It has gotten to a point where we are frustrated enough to consider moving away from LV, especially for more common tasks that can easily be done in text languages. In the past we implemented those tasks in LV mostly for convenience (only one language to maintain), but maintenance has become more and more tedious and very frustrating in newer versions (don't even get me started on NXG, it's a disaster). I really hope NI takes a hint and allows disabling all the "cute" features in LV and NXG. LV2020 is likely the last version we'll consider for internal testing. Hopefully with positive results or my keyboard will get much more busy than my mouse. Says a lot about it, doesn't it

You might want to reduce the number of parallel connections to two (seems to be working fine on my end). The server bans IPs with too many connections at once: The other videos are still online, but not available right now until traffic for the current videos has gone down. Once all of us finished choking the server all videos should be available again. This has happened in the past as well:

I understand you are eager to learn programming in LabVIEW, but you should really start by learning the concepts first. The learning curve you try to take is way to high in my opinion. That being said, these are your current solutions as far as I can tell: 1) z = (x << 3) + (5 << y) 2) z = (x² ^ 2) | (y & 1) Again, you should manually calculate some results and see if your code returns the correct results.

To answer your question: No, its not an array. I think GregSands already provided good help to this particular question: Of course this is only useful if you work with the Formula Node, just like you did with the other solution. That being said, before you continue writing anything in LabVIEW please take your time to understand what your expressions are doing. Try to make it simpler to understand. For example, instead of trying to get this entire expression to work, start with one portion of it, like the first part: z = 3 >> x You have to answer the same questions as before: What do you expect this expression to return for z? There are a lot of resources on the internet that also explain very well what these expressions do. You just need to know what to search for, so here is a translation table for you: >> Arithmetic Shift Right << Arithmetic Shift Left ^ Bit Exclusive Or & Bit And | Bit Or I suggest you try and understand what each of these expression does before combining them into longer expressions. Here is a full list of operations with their names for the Formula Node: http://zone.ni.com/reference/en-XX/help/371361P-01/lvhowto/precedence_of_operators_in/ I'm not an expert with Formula Nodes, but this should be possible to do without MathScript. From what I can tell the "x²" probably isn't allowed in the Formula Node, so maybe use "pow(x,2)" instead? If you get an error message please post the entire message here, maybe someone knows why this error happens.

You did it for the other expression, so which part do you have trouble with? Is there maybe an error message when you create the VI?

You are the one who wrote the program, you should know better than anyone if it produces the right results or not. If you don't, maybe you should start by understanding the expression before writing any code. Let's take your first example: if ((a + b) >= 4) c = (a - 2) + (b * 3) else c = (a + 5) * (b - 2) What do you expect for a = 2 and b = 3? Your program returns c = 9. Is this correct? Before writing any code I suggest calculating a few results by hand. That way you can compare your results to what the program returns. This is how you make sure your program works correctly. Edit: Can you explain more detailed where you have trouble? The third expression seems to be working, so what is the problem with the other two?

You mean they didn't happen in the executable right? The executable has no automatic error handling (unless compiled with debugging enabled, maybe), so the errors still happen but silently. Error 1097 indicates that the library corrupted memory. Memory that doesn't belong to the library, which is a serious issue. I'm not an expert with Call Library nodes, but this should be taken care of. Here is an article that might be of help: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P6tcSAC @jacobson mentioned before: A DWarn doesn't mean LV restored the corrupted memory, just that it was able to continue operation despite the memory being corrupted. You should still make sure it doesn't happen again! Sounds to me like the Call Library nodes are not configured properly. The library is unloaded by LV when closing a VI which causes the library to free all of its memory. Since the library accessed memory in the address space of LV, it tries to free it, causing LV to crash in the process. I meant that this is to be expected while working on the Call Library node. At least it takes me a while to figure out the correct settings before it works without errors.

Some of your crash logs point towards the TSVN Toolkit. Possibly related: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019RInSAM Edit: OpenCV also causes some issues: <DEBUG_OUTPUT> 21/02/2018 17:31:12.240 DWarn 0x50CBD7C1: Got corruption with error 1097 calling library OpenCVWrapperToCpp.dll function ?lv_Canny@@YAXHHNNH_NPAH@Z I suppose you were working with the Call Library function at that moment, so these problems are to be expected. Just make sure to restart LV every now and then to reset the memory or LV will crash eventually.