ShaunR

Ah right. It would be another one of those things I never came across. My API's rarely use functions outside of the binary it is wrapping (exception being ECL which uses some windows functions for things like the certificate store). I tend to use cross platform binaries so windows specific library calls are rare and unlikely to be cdecl. I disagree it is ill advised protection. One of the reasons I chose LabVIEW to start programming in was because it was bullet proof. I think we have had a conversation before that I never encountered crashes in the early days and it would have been because of ant foot-shooting boots like this.

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.

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.

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

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

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.

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.

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

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

It's been a long, long time but I did spend a week trying to get one to work so I'm emotionally scarred. Part 1 — P2P viability: With no stubs and both devices transformer-coupled internally, is the coupler genuinely redundant? Or are there signal integrity concerns I should be thinking about? The internal transformers are for isolation rather than impedance matching. They are required so you can have floating differential signals. If you are only transmitting over a couple of metres then you can get away with no external isolation. But you should really be using a dual-stub transformer bus coupler inline (or at one end) with terminators. Everyone starts point to point then adds devices! Part 2 — Cable spec: We're specifying a custom cable for this (DB9 female one side, HD-DSUB15 male the other — matching the AIM card's connector). What are the things that matter most in the spec — impedance tolerance, shielding, untwisted length inside the backshell, connector grounding? What's easy to get wrong? Suggestions (in order of importance) #1 You must terminate both ends. Each end should have a 78 ohm resistor across it. Impedance mismatch is the No.1 Killer. You don't seem to have mentioned termination resistors. #2 Check differential pair polarity (A and B lines) and that the correct terminals on the connector are soldered. It's been a while but I vaguely recall that the cable is a crossover cable if you are not using couplers so D1A connects to D2B etc. (I may be wrong on that) #3 Check your cable impedance. It should be 70–85 ohm at 1 MHz. #4 Make sure grounding is good (360 deg). You will get away with crappy grounding in the lab if the distance is very short, though. Aim for a max of 1-1.5 cm unshielded inside the connector shell. Use metal shells grounded to the chassis, if you can. #5 Put a scope on the lines looking at the waveform if you don't have an analyser. You are looking for rise/fall times of 100–300 ns, overshoot/ringing limits, etc (I don't remember them all-look at the spec).

I used to sell a product called the SQLite API For LabVIEW. It supported encryption. It's no longer available as SQLite removed the hooks and forced most people to use the SEE. SEE is a different source tree that they give you access to after you have paid for it. SQLCipher uses a modified source code tree and rewrites the SQLite source - they basically put the hooks back in again. Whichever way you choose, you will have to compile the binaries yourself and support them. You won't be able to just download the binaries from the SQLite website. It's been a while, and I haven't looked at the source recently, but I vaguely remember there were only a small number of API calls (maybe 2 or 3) that you needed to use

Available in the new ECL version 4.6.0

It will eat away at you slowly...at first. Then every time you see the link you will know [it doesn't work]. Drip, drip, drip. It's like those crossed wires on your diagram - you tell yourself it doesn't matter, that it's just cosmetic, that there is no change in function. But eventually you have to do something about it. Send that request to the admin, you know you want to

Your fastidiousness with code tells me this is an outright lie.