VISA / SCPI : garbage in returned data

[Sebastian.Weber]

I'm currently trying to track down a strange issue, and have no clue what's the problem.

The setup is an industrial production line with a PC running LV2017 and a Keysight 34465A multimeter.

The multimeter is attached via Ethernet, communication is done via VISA as TCP0::<ipadress>::INSTR.

Now, upon "READ?", the multimeter takes 10'000 samples, and returns a 160'000 byte long text string of comma separated float values.

And now the problem:

More or less often (up to 80%), the string contains 16 extra bytes of data, which consist mostly control characters.

This data is always inserted after the 148'873th byte, where it splits a number.

Here is an example. The first line is a good reading, the second contains that garbage:

I've done a test on the production line as it was idle, that is, everything was switched on and all software components were running, just there was no production. Withing 1000 measurements performed with just 1s delay between them, there was not a single occurence of the problem. But once producions starts, it happens again and again.

The system uses further VISA connections like a COM port and some DAQmx modules in a cDAQ crate. In addition, there are lots of raw TCP/IP connections.

So, I think the device is fine, and TCP does not cause this kind of problem. It may be related to system load or some other weird interference, though I would expect the data to be inserted at a random position.

Does anyone have an idea what could be the problem?

[GerdW]

Hi Sebastian,

you forgot to attach/include your example…

What happens when you request/read less than 148kB of data?

Like reading just 9000 samples instead of 10kS?

---

@Sebastian.Weber wrote:

there was no production. Withing 1000 measurements performed with just 1s delay between them, there was not a single occurence of the problem.

But once producions starts, it happens again and again.

---

Some kind of interference from your "production"? No production, no problem - but problem with production…

[rolfk]

The conclusion that the device can't be the culprit is a pretty quick and unfounded one. It would strike me much more strange that the TCP/IP socket driver in Windows (or VISA or LabVIEW) would cause such a strange and specific error in always the same offset for this specific device than that the device itself is actually the culprit. LabVIEW, Windows, VISA and just about everyone else know nothing about this device nor when you do exactly such a query so it would be weird that they always manage to corrupt the binary stream exactly at the same offset.

Check if Keysight has a firmware update for their device!

What happens if you instruct the device to transfer the data in binary form instead? That will both make the binary string shorter and may not trigger a specific bug in the firmware.