Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

This area is for discussions involving any fusion related radiation metrology issues. Neutrons are the key signature of fusion, but other radiations are of interest to the amateur fusioneer as well.
John Myers
Posts: 68
Joined: Tue Mar 07, 2017 7:13 pm
Real name:
Location: SoCal

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Post by John Myers »

The Arduino code base is meant to be user friendly not necessarily quick and efficient. So even though an Atmel AVR chip can handle 'sensing' frequency's above 3Mhz the Arduino library and the skill of the programmer will limit the actually max frequency that can be counted accurately.

Micro-controllers like AVR's are terrible at accurate in-sync measurements. At higher frequency a CPLD/FPGA is a better option (or buying a module).

Trying to use old USB drivers in a VM seems like a very hit-and-miss idea to me. When I used VirtualBox even newer common USB devices would give me trouble trying to get them to work.
Rex Allers
Posts: 570
Joined: Sun Dec 30, 2012 3:39 am
Real name:
Location: San Jose CA

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Post by Rex Allers »

John Myers said,
Micro-controllers like AVR's are terrible at accurate in-sync measurements.

I don't have much experience beyond simple stuff with AVR chips. What are you getting at? The timing of measurements is hard to keep consistent or maybe there are accuracy issues with ADC?

Can you be more specific about why FPGA is better on some issues?
(Not surprised that specific hardware configuration would be, just not sure exactly what aspects would be improved.)
Rex Allers
Harald_Consul
Posts: 94
Joined: Sat Oct 20, 2018 6:01 am
Real name: Harald Consul

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Post by Harald_Consul »

USB is a standardized interface. Thus, a generic USB driver can be used for any USB controller (instead of an individual one), right?

Aren't new USB controllers (USB 3.0, 3.1) downward compatible to USB 2.0, so that also USB 2.0 drivers might be used on them?
John Myers
Posts: 68
Joined: Tue Mar 07, 2017 7:13 pm
Real name:
Location: SoCal

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Post by John Myers »

Rex,

It's being able to consistently sync multiple discrete IO and interrupt signals that older micro-controllers like AVR can't do well. More modern MCU's like Xmega's do have special modules built in to address these issues. Most ADC's in MCU aren't designed for high speed, their just meant for basic voltage readings.

CPLD/FPGA's are just gate-logic so they don't have the multitasking issues like latency and interrupts that an MCU has.
John Futter
Posts: 1848
Joined: Wed Apr 21, 2004 10:29 pm
Real name: John Futter
Contact:

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Post by John Futter »

I personally would never use labview for any real time application
for a start it sits atop a non real time operating system.
Getting reliable data in real time keeps many experts very busy
one very good example is http://www.coultersmithing.com/forums/v ... f=13&t=640

One place real time data is important is in the automotive industry, engine control, self drive etc and these applications use
an RTOS "Real time Operating System" such as QNX a real time unix
What they do is not possible with windows or whatever Linux flavour
let alone along with a resource hungry application like labview that wants 110% of a processors resources
John Myers
Posts: 68
Joined: Tue Mar 07, 2017 7:13 pm
Real name:
Location: SoCal

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Post by John Myers »

Harald,
Although there are generic USB drivers for things like keyboards and mice even these have special buttons that require a specific driver in order to utilize all the features on the device. There are many standard compliant ways a manufacture can TX/RX the data so even something like the scroll wheel on a mouse wouldn't necessarily work if only using a generic driver.

The issue with USB drivers and VM's has more to do with the VM's ability to translate the actual USB hardware signals into an emulated USB hardware. If it can't do this properly the USB driver on the virtual OS can't communicate properly.
Harald_Consul
Posts: 94
Joined: Sat Oct 20, 2018 6:01 am
Real name: Harald Consul

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Post by Harald_Consul »

John, I thought you were talking about an old USB port driver (from an old Windows) for a newer version of a USB port controller chip (hardware on the mainboard).
Chris Mullins
Posts: 67
Joined: Sun Feb 19, 2017 11:32 am
Real name: Chris Mullins
Location: Shenandoah Valley, VA
Contact:

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Post by Chris Mullins »

The USB hardware on a PC motherboard is the host controller. Naturally the reality is a bit complicated (e.g. there multiple standards, some proprietary), but the USB host controller interface to the OS is standardized enough that a mainstream motherboard's USB hardware is usually OS-independent, even across several Windows versions.

Things are much more problematic on the peripheral side. The Windows driver model changed from XP to Vista, so there are drivers in the pre-Vista era that don't work in later Windows versions. There are also compatibility issues with 32 bit drivers and a 64 bit OS (or vice versa). In addition, some drivers target specific versions of Windows unnecessarily and would work in later versions except for the explicit OS targeting in the installer. The .inf file for a driver is a text file with some of those rules - occasionally that can be hand-edited to get a driver to work in a new OS if there are no other incompatibilities.

Like John said, running old USB drivers and software in a VM is hit or miss, and success depends on the tools used to build the driver, the nature of the incompatibility, and the VM software itself (e.g. VirtualBox vs. VMWare) and how it passes the USB interface to the host. I've had mixed results even using the same OS in the host and VM, and with a compatible USB driver for that OS.

Linux and Windows both include some standard USB peripheral drivers - keyboard, mouse, virtual comm port, network adapter, etc. If an instrument like a scope, meter, etc. implements a standard USB interface like one of those in its hardware/firmware, there's no need to install a USB driver on the host PC. That greatly increases the odds of longevity through multiple OS versions. On the other hand, if an instrument implements some proprietary interface over USB involving a custom driver, the risk of obsolescence is much higher. This is true even the interface presented by the driver to the OS (e.g. virtual comm port or network adapter) is a standard one (as opposed to the instrument using the OS built-in driver for that same interface).

USB is my last choice for interfacing to any sort of instrumentation.
Harald_Consul
Posts: 94
Joined: Sat Oct 20, 2018 6:01 am
Real name: Harald Consul

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Post by Harald_Consul »

To let me get this straight what you have said:

I thought, there are two levels of drivers:
  1. A lower level USB port driver between the OS and the USB port controller chip (hardware on the mainboard)
  2. A higher level driver between the OS (or the application) and the periphal hardware - e.g. a scope - (that uses the lower level USB port driver as some kind of protocol)
But you say, both of my imagined drivers are bound in one driver for the peripheral hardware?
Chris Mullins
Posts: 67
Joined: Sun Feb 19, 2017 11:32 am
Real name: Chris Mullins
Location: Shenandoah Valley, VA
Contact:

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Post by Chris Mullins »

Sorry, I may not have been clear earlier.

With USB, one side of the interface is the host, and the other is the peripheral. The host is the PC, and the peripheral is the device connected to the PC (e.g. a scope). Technically there is a provision for swapping these roles, but it's not common.

There are usually two drivers involved with USB, but they're typically not thought of together. One is the device driver that runs the USB host controller on the motherboard. This is what you're calling the USB port driver. This driver is usually part of the operating system, or installed with the operating system, and is almost never modified by the user (except as part of an OS upgrade). There may even be BIOS support for some portion of the USB host controller (in reality the situation is complicated, because the USB host itself is composed of several pieces, each with their own driver). No USB peripheral device comes with a host controller driver.

The other driver is the one for the peripheral. Without this driver, the peripheral can interact with the host USB controller itself, but there's no ready mechanism for any PC application to communicate with it. Technically you could write software that reached directly through the USB host controller down to the peripheral - that's how the peripheral's driver itself does it. The function of the driver is to provide a standardized programming interface to application software for that device. For example, a scope USB driver may provide functions for interacting with the scope to higher level software. The scope only needs to install the peripheral driver, relying on the OS to already have a driver and standard interface to the USB host controller.

There are standardized device classes and types of interfaces defined in the USB spec, including a virtual comm port. A USB device driver can implement one of those standard classes, or make up its own device. If the driver implements a standard device, then others can create software that interacts with it more easily. If the device hardware itself implements a standard device that already has a built-in OS driver, then no peripheral driver needs to be installed at all. For example, a scope may have a USB virtual comm port. The scope itself could implement that directly without requiring a driver install on the OS. That's best for long-term compatibility, but puts more burden on the device. Or, it could have some proprietary USB software interface, requiring a driver install. That driver could then present a standard virtual comm port to the OS, or some other non-standard interface, or both. But, you'd have to have the driver installed to work with the scope. Without the driver, the host controller can still talk to the scope's USB port (and there's a lot of talking going on just at that level, since USB is a shared bus), but programs running in the OS won't be able to talk to the scope.

USB in general is far more complicated than RS-232, Ethernet, or GPIB, and changes much more rapidly - it's driven by the consumer electronics technology treadmill. How many USB connectors have come and gone compared to RS-232, Ethernet, or GPIB?
User avatar
Richard Hull
Moderator
Posts: 14992
Joined: Fri Jun 15, 2001 9:44 am
Real name: Richard Hull

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Post by Richard Hull »

Chris has it right. USB is still forming and might never stop evolving the RS serials and GPIB are so dead, they are set in stone. Slow yet reliable and easily worked with to this day. You pay for the late and great super fasts which may or may not survive a new operating system or connectivity rage. Technology marches on as we need to grab data at lightning speeds.

Richard Hull
Progress may have been a good thing once, but it just went on too long. - Yogi Berra
Fusion is the energy of the future....and it always will be
The more complex the idea put forward by the poor amateur, the more likely it will never see embodiment
Harald_Consul
Posts: 94
Joined: Sat Oct 20, 2018 6:01 am
Real name: Harald Consul

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Post by Harald_Consul »

Thanks Chris.

Ok. I have understood now, that USB is in some directions pretty suboptimal for future-proof PC based high frequency measuring.

On the other hand serial port (aka RS-232) and parallel port (aka GPIB or IEC-625-Bus) are too slow to measure high frequency (> 3 MHZ) directly. And the measuring instruments of that decade do not have a digital storage to cache the high-frequency data mass.

I even haven't heard of digital scopes with an ethernet port a lot.

Thus, there is no future-proof intgrated high-frequency measuring solution yet, right?
Chris Mullins
Posts: 67
Joined: Sun Feb 19, 2017 11:32 am
Real name: Chris Mullins
Location: Shenandoah Valley, VA
Contact:

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Post by Chris Mullins »

Well, "future-proof" and "PC-based" are two terms that don't really go together in general, unless you're willing to lock down the PC once things are working (no OS upgrades, no changing PC hardware, not networked, etc.) Speaking generally for long-lived systems, it's best to avoid consumer hardware/software - the new technology treadmill cycle is much too fast in that world. Or, freeze time by never changing anything in the system once it works.

Scopes with Ethernet ports have been around for a while, and are dramatically cheaper than in the past. The Siglent SDS1202X-E in my system has a 200MHz bandwidth and a 14Msample buffer length (per channel, with 2 channels), along with an Ethernet port. It has a waveform storage mode with timestamps, and can capture 400K waveforms/second. Likely there is a lot of fine print, and implementation bugs/shortcuts limiting actual performance compared to a real LeCroy/Tektronix/Agilent scope, but that's not bad for $379. Rigol has similar scopes too.

I'm sure there are Ethernet-based high speed data acquisition systems out there. Buying something like that from an established company is about as "future-proof" as you could get. Here's a USB-based system that gives you up to 12 MHz sampling on 2 channels: https://www.mccdaq.com/usb-data-acquisi ... -2020.aspx, assuming your PC can keep up with the storage. Naturally it requires their own USB drivers and software. Whether you can get that to work with a new Windows PC from 20 years in the future - who knows?
User avatar
Rich Feldman
Posts: 1470
Joined: Mon Dec 21, 2009 6:59 pm
Real name: Rich Feldman
Location: Santa Clara County, CA, USA

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Post by Rich Feldman »

It gets easier when you have deep pockets. At work I sometimes use a late-model 30+ GHz oscilloscope without setting foot in the lab. It cost more than I make in a year. It's got an Ethernet cable connection.

Remotely log in from this computer to the oscilloscope's Windows PC, after sometimes asking a previous user to log off.
Then the Infiniium program (why should we start calling it an app?) takes over the screen, or a sub window, with familiar digital oscilloscope display. When there's need to enter the lab of noise and cold air, I can pick up my session at the oscilloscope's console.

I can save waveforms directly to files on 'scope's drive, or on a server, or on this PC. Generally as text files -- we are no longer locked into binary wfm formats. They can get a bit unwieldy beyond a few million lines. If the network connection is down, files can be saved or copied to a USB flash drive.

It's because of embedded industrial computers that Microsoft supports some operating systems long after the "consumer" and "pro" versions have gone into the dustbin.

Reminds me of a national security concern. We know utility grids and pipelines are remotely controlled by computer. Are they allowed to use connections through "the world wide Internet" for that? Sounds like profit-driven foolishness.
All models are wrong; some models are useful. -- George Box
John Myers
Posts: 68
Joined: Tue Mar 07, 2017 7:13 pm
Real name:
Location: SoCal

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Post by John Myers »

industrial Ethernet has been gaining popularity. It offers fast real-time/deterministic communication. POWERLINK and EtherCat are two protocol examples.
Harald_Consul
Posts: 94
Joined: Sat Oct 20, 2018 6:01 am
Real name: Harald Consul

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Post by Harald_Consul »

Very interesting.

I just did a quick Ebay research. New 200 MHZ oscilloscopes with Ethernet-Port roughly start at 1500 USD. That's more or less for the deep pocket.

On the other hand 2-Channel 200MHZ oscilloscopes with SD-card slot start at 330 USD. (Do not say, that the low price segment is good quality as well.)

Is it possible to use a sophisticated analog signal generator signal (by BNC cable) to precisely time-synchronize the measuring of two or more digital scopes (or other HF-measuring devices)?

I mean, the new signal generators (often attached within a scope) allow to program flexible wave patterns. Is it possible to program a sophisticated analog HF wave pattern, that is unique enough per time frame, that it would allow use it as index and to SQL-join the measuring of two (or more) different scopes?
User avatar
Rich Feldman
Posts: 1470
Joined: Mon Dec 21, 2009 6:59 pm
Real name: Rich Feldman
Location: Santa Clara County, CA, USA

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Post by Rich Feldman »

Harald, it sounds like your time sync question is about matching the starting times.

Do you, or other readers, also care about finely matching the time scale factors? What sort of time accuracy do the low cost instruments come with?

Each instrument in a setup has a different reference for what appears as 1 microsecond or 1 MHz. Timebase accuracy tolerance ranges from dozens of ppm (e.g. from a computer clock or embedded XO) to very small numbers. It's common, in time and frequency instruments claiming 1 ppm or better, to support frequency locking to other instruments via BNC connector on back panel. Generally 10.0 MHz with some master/slave connection topology.

Here's an example where a timebase speed difference is right in your face. Single-channel scope acquisition of a serial data waveform to study jitter. In a chart of edge position errors vs. bit number we see them gradually ramping down, so bits around 100,000 are 1/4 bit early with respect to bit 1. No big deal, it just means the data source is running 2.5 parts per million faster than the oscilloscope.

Tangential story-telling time: -------------------------------------------

Among the standards discussed in this thread, old RS-232 can tolerate mismatches measured in whole percents, because it re-synchronizes at the beginning of each character. Who else remembers electromechanical teletype machines and 110 baud? Or even knows what a UART is?

Many modern multi-gigabit standards tolerate 100 ppm differences, to minimize cost of the local frequency reference. Data scrambling or encoding ensures that receiver always gets plenty of transitions, from which Rx clock can be recovered.

The Cassini-Huygens deep space mission to Saturn and Titan barely escaped a major comm link failure in 2005.
https://www.evaluationengineering.com/h ... ns-mission
After the spacecraft (C and H) separated, H probed the atmosphere of Titan while C entered orbit around Saturn. Data from H had to be received and recorded by C, for later transmission to Earth.
Long story short: the radio receiver designers accounted for predicted Doppler shifting of the carrier frequency, but overlooked the fact that serial baud rate would be shifted by the same Doppler ratio. :-)
All models are wrong; some models are useful. -- George Box
Harald_Consul
Posts: 94
Joined: Sat Oct 20, 2018 6:01 am
Real name: Harald Consul

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Post by Harald_Consul »

Richard, if these guys eventually provided a 1 Ghz, 16 bit, 5 GSample/s and 1 TSample buffer oscilloscope for 500 USD, it would truly be about time synchronisation, only.

But for now, as the effective measured time period of recent oscilloscopes is unbelievable small (due to small buffer size), it is about about (start) time synchronisation AND remotely triggering the start of the record from my point of view (as you also mentioned).
Harald_Consul
Posts: 94
Joined: Sat Oct 20, 2018 6:01 am
Real name: Harald Consul

Re: Integrated Lab Measuring and Controlling (Labview, Labjack, ...)

Post by Harald_Consul »

Ok, I still owe you a summarizing synopsis, which comes now. I guess, it will contain some errors (as I am terribly stupid ;-)).

Integrated lab measuring consists out of
  1. Measuring
    • Generally future-proof realtime measuring requires:
      • A standardized communication interface to the peripheral meter (e.g. USB, Ethernet, Wlan, Bluetooth, Serial Port, Parallel Port).
      • A standardized protocol to access the data (over the com interface). This can either be a file transfer protocol or a streaming protocol.
      • (Maybe in the old serial and parallel ports the communication protocol and data protocol are integrated in one? I am not familiar with these ones.)
    • Afaik only Raspberry and Arduino/Atmel measurement data logging can provide standardized communication interface and standardized data protocol.
    • Arduino/Atmel maximum measurement frequency typically is up to 10 kHz, extension kits up to 1MHZ are available.
    • Future-proof integrated high frequency measuring is very problematic.
    • Running a virtualized old Windows to make use of an old USB-driver is a random game.
    • High-end oscilloscopes indeed offer Ethernet/Lan interface. But the data access is still proprietary, which means the driver will be antiquated in 10 years, as well.
    • Offline-measuring by a low cost oscilloscope with an USB-stick or SD-card interface may be an attractive workaround to achieve a future-proof measuring equipment. However, a turn key time synchronisation for this approach is not known.
  2. Control
    • Remote switching on and off is a peace of cake. Most measuring I/O adapters also offer output, which using a relais panel can be adopted to any voltage and current.
    • For remote controlling a variable voltage a variable voltage supply can used best to muliply the voltage of the I/O adapter. E.g. from Spellman.
Post Reply

Return to “Neutrons, Radiation, and Detection (& FAQs)”