ShaunR
-
Posts
5,023 -
Joined
-
Days Won
312
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by ShaunR
-
-
-
I'll caveat this with this is only my opinion as a European. Market forces may be completely different to my perception in the US.
When I first started, LabVIEW was basically a loss-leader to sell hardware. The sales people would give it away free (or heavily discounted) if you bought the hardware. It proliferated and people like myself learnt and expanded our capabilities. Over time it launched a small consultancy industry specialising in LabVIEW. There were a few major successes such as JKI and some partnerships along with single developer consultants. The test and measurement industry had few rivals to LabVIEW's capabilities.
Fast forward to today and I think the emphasis is now firmly on large organisations with enormous hardware requirements-in particular governmental organisations. CERN is an obvious one in Europe (CERN being intergovernmental) but I believe there are many in the US. The Test and Measurement was, for the most part, lost to Python and although there are one or two consultants still operating in my neck of the woods, that part of the industry is basically gone here.
So. In my view there is still an appreciable number of opportunities working for large companies' in the US and Europe but if you are looking to be a self employed contractor (in Europe) then you would be better off with something else.
-
1
-
-
18 hours ago, Rolf Kalbermatter said:
Not sure what you mean exactly.
On 6/6/2026 at 9:08 AM, Rolf Kalbermatter said:Depends what compiler you use.
On 6/6/2026 at 9:25 AM, ShaunR said:For C/C++ I always use MingW (sometimes in MSYS2, sometimes in Codeblocks) but I prefer Pascal (Free Pascal compiler).
-
19 minutes ago, Rolf Kalbermatter said:
Depends what compiler you use. Some are more difficult to force into compliance with your preferences than others.😁
All my DLLs are always cdecl or whatever the preferred calling convention is (Windows 64-bit abandoned with cdecl in favor of fastcall, and trying to force a compiler to do cdecl there, while possible in some compilers, is pretty much doomed for anyone else who is going to have to use that DLL).
For Windows APIs however you can't choose, that decision has been made by Microsoft when defining the API. For user DLLs I don't see why anyone ever would have decided to go by stdcall, unless they use a programming environment that could not deal with cdecl.
For C/C++ I always use MingW (sometimes in MSYS2, sometimes in Codeblocks) but I prefer Pascal (Free Pascal compiler). Is this something you encounter mainly in MSVC?
-
20 hours ago, Rolf Kalbermatter said:
I consider it ill advised since that name decoration is simply a Microsoft convention. Other compilers did in the past not create such names when linking a DLL. So as summary:
1) It's not mandated by Microsoft that a stdcall function should be decorated like that, but simply a convention by their linker. It's also not mandated that a non-stdcall function can't be named that way.
2) So it is not a mechanism to reliably avoid Call Library Node misconfiguration.
3) More importantly, it makes it impossible to call a function that was intentionally named that way but compiled as cdecl.
Why would someone create such a function? Well, I have no idea even if you beat me, but obviously someone did, otherwise NI would not have removed that anti-foot-shooter hack.
The main difference is who cleans up the stack after a function. But again, I have avoided name mangling/decoration because it makes it difficult to figure out what to call. I guess being a mid-wit has saved me again
-
15 hours ago, Rolf Kalbermatter said:
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.
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.
-
2 hours ago, Rolf Kalbermatter said:
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.
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.
-
4 minutes ago, viSci said:
Are you suggesting that the problem was non-uniform application of the pointer-sized integer CLFN parameters?
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.
-
34 minutes ago, viSci said:
It crashes running any of the included examples. It seems to be able to open a reference to the .db but any queries crash.
Indeed. That is usually the result of misconfigured CLFN's.
-
1 hour ago, viSci said:
I did try the latest sqlite dll from SQLite.org and also adding the AES symbol to the project but still crashes.
It is probably one or more misconfigured CLFN's somewhere that was fixed in later versions. It was worth a try though.
-
22 hours ago, viSci said:
Thanks. I have already started porting to JDP SQLite. I should have done that a long time ago.
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).
-
4 hours ago, daqnx said:
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
Full disclosure: I work on the DAQNX project.
If the concept sounds interesting, feel free to subscribe to the Crowd Supply campaign.
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
-
On 6/12/2024 at 9:53 AM, ShaunR said:
I'm also thinking of opening up the Socket VI's as a public API so people can create their own custom protocols.
Available in the new ECL version 4.6.0
-
1
-
-
23 hours ago, Rolf Kalbermatter said:
I tried hard to ignore your poisonous whisperings but eventually succumbed to it. 🤫
-
41 minutes ago, Rolf Kalbermatter said:
Hey, I didn't talk about code! This was about advertisement and commerce.
(And my lost privilege, which indeed hurts my sensitive soul a little 😁. It's soul crushing to read an old post of myself and discover typos in it.)
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
-
33 minutes ago, Rolf Kalbermatter said:
Not sure I care at this point very much.
Your fastidiousness with code tells me this is an outright lie.
-
On 3/5/2026 at 4:54 PM, Rolf Kalbermatter said:
The link is broken for lazy people like me
-
1 hour ago, ManuBzh said:
And what your point of vue about Q Controls ?
Never used them or had a need for them.
-
2 hours ago, ManuBzh said:
For sure, this must have been debated here over and over... but : what are the reasons why X-Controls are banned ?
It is because :
- it's bugged,
- people do not understand their purpose, or philosophy, and how to code them incorrectly, leading to problems.They aren't banned. They are just very hard to debug when they don't work and have some unintuitive behaviours.
I have Toolbar and Tab pages XControls that I use all the time and there is a markup string xcontrol here. If you are a real glutton for punishment you can play with xnodes too
-
1
-
-
What's with the text centering?
I have 2012 (and 2009) running on a Windows 11 machine. I think I had to turn off the App and Browser Control in the Windows Security.
Convertir. vi
in LabVIEW General
Posted
You should contact the developer. It may use features not available in earlier versions and it is a source control nightmare maintaining subtly difference versions.