All Activity

There are posts on the NI forum about this, the earliest probably around 2012 or 2013 and I was involved in finding the issue. It's not so difficult when you look at a Call Library Node for a Windows API that crashes and then see that it is configured cdecl as there are virtually no Windows APIs with that calling convention except when they have a variable number of parameters as that can not be done in stdcall where the function itself adjusts the stack just before returning. Why would someone "fix" an anti foot shooting protection? Most likely because there was an important customer wanting to call a DLL that used that naming decoration for whatever strange reason, while it was explicitly compiled to use cdecl, and threatened to sue the poor support person taking their call and sending an assassin squad to the NI head quarter. 😁 And in all honestly it is an ill advised protection that should not be there. What is less nice is that this functionality was simply removed without some mutation code path when upgrading pre 2011 VIs with a Call Library Node to 2011 or later. Yes there are complications, the correction was apparently done at recompilation time by actually verifying the exported name (the Call Library Node doesn't require to enter the decorated name but does the according matching to the real exported function at that moment) so if the VI was loaded in a newer version with the DLL missing, it would be impossible to properly mutate the code, but it would have been at least possible to try to mutate the VI during loading into the new version if the original was older than 2011. As it is that ship has long sailed already and it is a moot point to argue about now.

I would probably never have been able to resolve an issue like that. What kind of monster removes anti foot-shooting boots? It's highly likely it was just me misconfiguring some CLFN's. It's obviously been fixed in later versions. I still use the API so would have known if there was an issue with 5.0.0. I think version 1.3 was about 2010 so that version is over 16 years old - an amazing testament to LabVIEW's compatibility really.

Just one wild guess that recently bit me in another library. Does the SQLLite API in the Windows DLL use stdcall calling convention? Until LabVIEW 2011, LabVIEW had a "helpful" feature to second guess your choice of that calling convention in the Call Library Node if the exported function had the appendix @xx with xx indicating the number of bytes passed on the stack for the parameters. The calling convention was silently "corrected" to stdcall even if you had cdecl in the configuration. Once you move to LabVIEW 2011 or later, this suddenly crashes as that silent correction was removed without any warning. The correct way when such a feature gets removed would have of course been to mutate the VI when converted from a pre 2011 version to 2011 or later. However the person removing that paternalizing feature did not think about adding an according mutation code path in the InstrumentLoad() function. The thing bit me because I was developing code in LabVIEW 8.6 and had been also testing it in LabVIEW 2020 64-bit to be sure, wrongly assuming I had been accounting for a fairly large range of LabVIEW versions and platforms. Since LabVIEW 64-bit does not have any calling convention to choose from it did not expose that misconfiguration and someone else loading it into a newer LabVIEW 32-bit version found out the hard way that I had messed up. Never mind, I see it is 2025 64-bit LabVIEW so there is no calling convention to get wrong.

Not necessarily but possibly. Pointer to data instead of value or vice versa, enum sizes, pointer de-references of strings etc. Library calls are trixy.

Are you suggesting that the problem was non-uniform application of the pointer-sized integer CLFN parameters?

Indeed. That is usually the result of misconfigured CLFN's.

It crashes running any of the included examples. It seems to be able to open a reference to the .db but any queries crash.

It is probably one or more misconfigured CLFN's somewhere that was fixed in later versions. It was worth a try though.

I did try the latest sqlite dll from SQLite.org and also adding the AES symbol to the project but still crashes.

If you didn't use the encryption then you could use the SQLite binaries from SQLite.org to keep you running while you transition. I can't remember off-hand if it was supported in 1.3.1 but adding AES=NONE to the project conditional symbols enables the use of vanilla SQLite binaries (i.e. comments out encryption function calls). That said, I expect the issue with LV2025 is probably to do with calling parameters rather than the binary itself because V5.0.0. seems to work fine with LV 2025 & 2026.

Thanks. I have already started porting to JDP SQLite. I should have done that a long time ago.

There are several SQLite libraries on VIPM.io. I personally use the one by JDP Science, but a few others also look promising. Changing over will obviously take some time finding and replacing one API for another, especially if there are differences in design choices in how they each implement similar functionality.

If you have a commercial waiver then there is limited residual support but apart from that, you should be looking to transition to an alternative product.

That is considerably more modern then my v1.3.1, I would give it a go if you could make it available...

The SQLite API for LabVIEW was retired 6 years ago (at version 5.0.0).

I realize this SQLite LIbrary (by ShaunR) is pretty ancient so not surprised there maybe some dll updating required but I thought I would inquire. I have used it many times in the past and have come to appreciate its performant well crafted design.

There is definitely space in the market at this level. The success for LabVIEW is almost entirely dependent on the drivers and ease of application deployment. This is where, historically, NI have the upper hand as they have an integrated solution. Other platforms can get complicated

This is a problem I've seen come up more often lately. Many applications don't necessarily need a full CompactDAQ or PXI-class system, but they still need reliable industrial I/O, current-loop measurements, modular expansion, and the ability to adapt the hardware to a specific application. What often becomes frustrating is that once you need a specialized measurement module or a custom combination of I/O, the expansion path can become disproportionately expensive compared to the actual measurement requirements. It feels like there's a growing need for more open and modular instrumentation platforms that sit somewhere between fully custom hardware and large proprietary DAQ ecosystems. That's one of the reasons we're building DAQNX — modular instrumentation hardware with interchangeable function-specific modules and open software interfaces. https://www.crowdsupply.com/daqnx/daqnx https://www.daqnx.com Full disclosure: I work on the DAQNX project. If the concept sounds interesting, feel free to subscribe to the Crowd Supply campaign.

This is an interesting discussion because it highlights a problem we keep seeing in industrial and test systems: the gap between fully custom hardware and large DAQ ecosystems. For many applications, the measurement requirements themselves are not extremely demanding, but the cost of expanding distributed I/O, adding specialized functionality, or adapting the hardware architecture to a specific project can become significant. What seems increasingly important is having modular hardware that can be distributed, customized, and extended without needing to redesign everything from scratch or commit to a much larger platform than the application actually requires. We're exploring that idea with DAQNX, a modular instrumentation and DAQ platform built around interchangeable hardware modules and open software interfaces. https://www.crowdsupply.com/daqnx/daqnx https://www.daqnx.com Full disclosure: I work on the DAQNX project. If the concept looks interesting, feel free to subscribe to the Crowd Supply campaign.

Howdy all 🤠 I'm Nate, the product manager for NI-Industrial Communications for EtherCAT at NI | Emerson. The rumors are true! We're working on releasing new versions of EtherCAT. We've had two recent releases that fix some usability bugs and improve the ESI file loading experience (better error handling - now we point to exact XML tag that causes us to trip up, etc.). Give them a download and let me know what else we need to do to close the gap! DM me for my direct email address if you want to chat more.

This is a very good demo

Job Posting

参考 https://www.vipm.io/publisher/opengds/ OpenGDS UML Editor by OpenGDS

Good afternoon! I have multiple positions open starting up ASAP for LabView System Integration & Test Engineers. Our client is located north of Boston, and these are long term contract positions that are all onsite. Our client is looking for LabView and Test Stand experience. You would need to be a US Citizen, and you would also be able to obtain an active secret clearance on this project. If you are interested in learning more, please email me over a copy of your resume to: *****@*****.tld Thank you! Lou LaMattina Senior Technical Recruiter Advanced Technology Office: 774-210-4084 *****@*****.tld www.advancedtechno.com