ShaunR

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.

The link is broken for lazy people like me

Never used them or had a need for them.

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

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.

Great song.

Triggers fall into two categories: software and hardware. Whether you use software or hardware depends on the trigger accuracy required-hardware being the most accurate. For your use-case I would highly recommend hardware triggering and I think those devices support two types: Digital IO and TSP-Link. Both are well documented in the manuals and I would further recommend digital IO as it is the simplest to configure. The way to do this is first to get it all working through the devices' front panels. Connect them up (including the digital IO, configure using the menu's then run a test. That will tell you what commands (and in what order) you need to configure for a successful test as SCPI commands map directly to menu's for most manufacturers. The advantage here is that if your software fails for whatever reason, you can still run tests with a precision digit (a.k.a finger). Once you are getting good results then it will be just the case of sending a single command to trigger the tests and the devices will do the rest. After they have finished you can then read all the data out.

The intent was to tell you the software was free (as in BSD licence) and, if had downloaded it, it contains a zlib binary that isn't wrapped.

I've never understood the "free (as in beer) or free (as in speech) internet vocabulary. Beer costs and speech has a cost. It's BSD3 and cost my time and effort so it definitely wasn't "free" Rolf's works on other platforms so you should definitely use that, but if you wanted to play around with functions that aren't exported in Rolf's, there is a zlib distribution with a vanilla zlib binary to play with while you wait for a new openg release.

Yes. Rolf like to wrap DLL's in his own DLL (a philosophy we disagree on). I use the vanilla zlib and minizip in Zlib Library for LabVIEW which has all the functions exposed.