Rolf Kalbermatter

Sounds like a masterpiece of engineering. Use a non-standard connector, resp. if they use the DB9 on the other device, connect its pins in a different way than standard, and then use for every new device again a different pinout. Someone must think selling custom cables is the way to earn lots of money! 😀

Would it be a lot to ask, for this library to support C++ style comments? Basically any text after // would simply be ignored until the EOL. I know that JSON strictly speaking doesn't support comments but JSON5 for instance does support those C++ style comments.

According to this link mentioned in the post before yours, you got that wrong. pin 7, 8, 9 are the serial port signals on the DB9 connector. The DB15 connector has them on pin 1, 2, 4!

Note that LabVIEW does not officially support Windows Server OS. I believe it will generally work, but ActiveX is definitely one of the areas I have my suspicions. Windows Server does quite a bit with security policies to lock the computer down for more security. ActiveX may very well be one area that is very much affected by this. Have you talked with MatLab if they fully support Windows Server editions? In any case, ActiveX needs to be installed and that also means modifications to the registry and the installer can choose if he wants to make the component available system wide or just

And how would you suppose should your client, who wants to use this library on a cRIO-9064 (just to name one of the currently still possible options which are Windows 32-bit, Windows 64-bit, Pharlap ETS, VxWorks, Linux 64-bit, MacOS X 64-bit, Linux ARM) recompile it without having access to the key? Sure with asynchronous encryption you don't have to publish your private key but then you are still again in the same boat! If you want to give a client the possibility to recompile your encrypted VIs (in order to not have to create a precompiled VI for each platform and version your clients may wa

This very much depends on the used font. Not all fonts specify glyphs for all these attributes. If it doesn't, the attribute request is simply ignored and the font is drawn in the basic form. LabVIEW doesn't draw these texts, it just passes the request to Windows GDI (or Unix XWindows, or MacOS Quartz) and tells it to do its work).

Consider the diagram password equivalent to your door lock. Does it prevent a burglar to enter your home if he really absolutely has set his mind on doing so? Of course not! Is it a clear indication to the normal law abiding citizen to not enter? You bet! There is no simple way to protect a diagram that the compiler needs to be able to read in order to recompile the program (for a different version, platform or whatever) without having a fairly easy way to also peek into it for the person truly wanting to. In fact there are many ways to circumvent that. You could patch the executabl

As far as if NI could do that legally, yes they could. If they want to? Why should they? Are you releasing all your source code as Open Source? And this is really meant seriously. Propose a meaningful business case why NI should release that source code if you were a manager at NI! And don't forget all the technical support questions of noobies trying to peek in that code, thinking they can fix something and then boom, everything goes haywire. There is no business case in the current NI software model for this. Unless NI decides to go .Net Core with their software, which I don't quite see

If you really want to spend a lot of time and effort into this, the more promising way would be to simply start developing an Advanced Analysis Library replacement directly around the Intel Math Kernel Library. That DLL interface you are talking about is mostly a historical burden carried over from when NI was still developing their own Advanced Analysis Library. Around 7.x days they decided that they could never compete with the girls and guys who knew probably best on this planet how to tickle a few percentage more of performance out of Intel CPUs, because they worked at the company who

Why?

No, and there likely never will be! NI has a very strong tendency to never ever talk about what might or might not be, unless the actual release of something is pretty much announced officially. In the old days with regional field sales offices you could sometimes get some more details during a private business lunch with the field sales office manager (usually with the request to please not share it with anyone else, since it wasn't yet official and in fact might never really materialize in that exact way). The only thing we know is that the LabVIEW source code was in some escrow and sup

It very much depends how much back you dare to look in that graph! 😀 Since it is a NASDAQ share you should rather go to the source, Luke! That steep climb around 2017 is actually after they started implementing those changes. The decline you see is mostly happening during Covid but as a trend not quite very significant yet. That all said, the current trend to measure everything in share price is a hype that is going to bring us the next big crash in not to much time. My guess is that once most people have crawled out of their covid imposed isolation in their private hole, they

I don't have these numbers. What I know is that a few years ago, NI noticed that their sales figures were starting to flatten. For a company used to have high two digit growth numbers year after year this is of course a very alarming signal. 😀 They hired some consultants who came to the conclusion that the traditional T&M market NI was operating in simply didn't have left much more air in it to continue to support the growth NI had been getting used to. And strategic decisions were made behind the scene. Not to much of that has been openly communicated yet, but the effects have been quite

That's always debatable. From a technical point of view I fully agree with you. LabVIEW is a very interesting tool that could do many more things if it had been managed differently (and also a few less than it does nowadays). For instance I very much doubt it would have ever gotten to the technical level it is nowadays if a non-profit organization had been behind LabVIEW. The community for LabVIEW is simply to diverse. The few highly technical skilled people in LabVIEW world with a very strong software engineering background, who could drive development of such a project in an Open Source mode

There is a standard digital signal available in the FPGA environment that allows resetting the device. You can assert this pin from your FPGA program. So one way would be to add to your FPGA program a small loop that polls the external digital signal (preferably with some filtering to avoid spurious resets) and then feed that signal to the FPGA Reset boolean signal.

NI didn't say they would be porting NXG features to 2021, but to future versions of LabVIEW. Technically such a promise would have been unfulfillable, since at the time the NXG demise was announced, LabVIEW 2021 was basically in a state where anything that was to be included in 2021 had to be more or less fully finished and tested. A release of a product like LabVIEW is not like your typical LabVIEW project where you might make last minute changes to the program while testing your application at the customer side. For a software package like LabVIEW, there is a complete code freeze except

Well, ultimately everything LabVIEW does is written in C(++). Some (a very small part of it) is exported to be accessible from external code. Most goes a very different and more direct way to calling the actual C code functions. Functions don't need to be exported from LabVIEW in order to be available for build in nodes to be called. That can all happen much more directly than through a (platform depending) export table.

No! Your guesswork got you in many ways wrong. AZ and DS memory spaces is an old Mac OS Classic programming distinction. AZ memory could be automatically relocated by the OS/kernel unless it was explicitly locked by the user space application. DS memory stays always at a fixed memory location. It also meant that when you try to access AZ memory and didn't lock it first with AZLock() you could badly crash if the OS decided that it needed that space and moved the memory (possibly into a cache file) during the time you tried to access that memory block. With modern virtualized memory manager

I understand and admire your reverse engineering effort 😀. My answer was partly directed to the OPs claim that the Occurrence API was documented. It's not (at least officially although the accidental leak from early LabVIEW days could be counted as semi official documentation). You're right that those functions you mention as lacking from those headers didn't even exist back in those days. They were added in the meantime in later versions. The additional 50MB of code in LabVIEW.exe aren't just useless garbage. 😀 (And only a fraction of what LabVIEW gained in weight over those 30 year

It means you COULD theoretically interact with Queues from your own C code. In reality the function name alone is pretty useless. And there is NO publically available documentation for these functions. Theoretically if you are an important enough account for NI (requires definitely 7 digits or more yearly sales in US$ for NI) are willing to sign over your mother, wife and children in an NDA document in case you breach it, you may be able to get the headers for these APIs. In practice the only people with access to that information do work in the LabVIEW development team and would likely g

No, it's not odd! Occurrences exist in LabVIEW since at least version 2.5. And back then NI sort of made a slip by distributing the full internal extcode.h file that exposed pretty much every single function that LabVIEW exported and could be accessed from a CIN (the only way to call external code back then). They fixed that in subsequent releases of 2.5.x (which was a pre release version of LabVIEW for Windows 3.0). Much of what was declared in that header was fairly useless anyways, either because it only was usable with other parts of LabVIEW that were not accessible from external code

Input registers are a totally different entity than holding registers and the Modbus protocol uses different function codes to read them. And a third function code to write to the holding registers. The LabVIEW VIs hide this function code from the user but you have to use the correct read function to cause the correct registers to be read.

Most problems about Modbus communication are related to the different address notations that are commonly used and the fact that some are 0 based while others are 1 based. I also find the distinction between registers, holding registers, coils, and discrete inputs rather confusing. Basically discrete inputs are boolean inputs, coils are boolean outputs and registers are 16 bit inputs and holding registers are 16 bit outputs. Then there is the fact that two registers can often be used together as a 32-bit register or a 32-bit floating point number but as far as the Modbus protocol is conce

There is and it is called Interapplication Communication. Which one to use depends on the platform and your familiarity with a specific method. - File IO (multiplatform, trivial to setup, difficult to manage as you have to deal with concurrency of two applications trying to access the same file) - DDE (Windows only, ultra ancient and much older than legacy, don't ever use it if you can help it) - Shared memory (super high throughput, complicated to use, pretty different APIs and methods on each platform) - (D)COM (Windows only, complicated to use from anything else than C(

Does the Patch update somehow also contain VIPM? Seeing that it is a patch it probably doesn't but it's worth checking. When you install packages through NIPM you can usually select sub packages that are or are not installed. Default is to install everything but if there is a selection possibility (the Full LabVIEW installer gives you an option to deselect VIPM), then you can control what gets really installed.