Hi,
I'm connecting to a Rigol DZ1000 Oscilloscope via USB and using the :DISP:DATA? ON,0,PNG command to grab a screenshot. Reading out the data in blocks of 65535 bytes until there is no more (see attached vi).
This normally works fine but yesterday I was getting a timeout error. I fired up IO Trace and got this:
> 783. viRead (USB0::0x1AB1::0x04CE::DS1ZA201305475::INSTR (0x00000001), "#9000045852‰PNG.......", 65536 (0x10000), 45864 (0xB328)) > Process ID: 0x000039C8 Thread ID: 0x00001760 > Start Time: 13:13:54.1169 Call Duration 00:00:10.4323 > Status: 0xBFFF0015 (VI_ERROR_TMO) You can see that 45864 bytes were received, which is exactly what was specified by the binary data header (45852 data bytes + 11 header bytes + 1 termination char)
I dumped the reply string into a binary file and set the scope to run so it show something else on the screen. Sure enough the error went away. I also dumped a good result into a file. Then I tried to figure out what the problem may have been but I didn't get anywhere. Any ideas? Sure looks like a bug in VISA read or perhaps an incorrectly escaped reply from the scope?
It's very easy to "convert" the reply into the screenshot - just remove the leading 15 bytes (4 bytes from WriteBinayFile and 11 bytes from the scope header). And yes, both data files display just fine as PNG. I don't think PNG does internal checksum so byte errors would be hard to spot.
Any ideas what could have caused that timeout?

I am experiencing numerous VISA Lock Errors (-1073807345) on resources I haven't explicitly locked.  This is happening on TCPIP connections to keysight N6700 power supplies and keysight N5242 PNA fairly regularly.
I have simultaneous loops in the application communicating to the different instruments, using a sequencer of sorts to pipe commands one at a time to each of my various loops.
Has anyone seen the locking error pop before while not actually using the Lock and Unlock VIs?  This issue has gotten worse lately and it has come time to find the root cause.  My only thoughts are that it may have something to do with having NI MAX and Keysight Connection Expert both installed and possibly trying to "ping" these devices.  Every once in a while me sending commands and these "pings" may clash and cause the locking error.
Error reads as follows:
"Specified type of lock cannot be obtained, or specified operation cannot be performed, because the resource is locked. VISA error code -1073807345 (0xBFFF000F)"
We are using LabVIEW 2013
Thanks in advance!

Hey guys,
Can you take a look at this?
The only work around I found is to dynamically open the connection with an external VI to make it fail so the second time it works.
If anyone has an instrument that communicate trough TCP-IP with VI, please try on your side with LabVIEW 2018 and visa 18.
https://forums.ni.com/t5/LabVIEW/VISA-error-with-TCP-IP-BK-precision-2190E/m-p/3876316
Thanks

I wanted to cross post metux's discovery here asap, and have a separate discussion.
Metux's original post:
The recent Linux driver package introduces a CRITICAL security vulnerability:
 
http://www.ni.com/download/ni-linux-device-drivers-2018/7664/en/
 
It adds additional yum/zypper repos, but explicitly disabling package signing and using unencrypted HTTP transport. That way, it's pretty trivial to completely takeover the affected systems, by injecting malicious packages.
 
 
DO NOT INSTALL THIS BROKEN SOFTWARE - IT IS DANGEROUS !
 
CERT and BSI are already notified.
 
 
 
 
 

Hi
We have an application where we need to have a custom PCIe board transfer data to the PC using DMA.
We are able to get this to work using NI-VISA Driver Wizard for PXI/PCI board.
The recommended approach is to have VISA allocate memory on the host (PC) and have the PCIe board write to it (as seen below).

While this approach works well, the memory allocated by VISA for this task is quite limited (~ around 1-2MB) and we would like to expand this to tens of MB.
Note: The documentation (and help available on the web) regarding these advanced VISA function (for instance "VISA Move out 32" and "VISA Move In 32") is parse. If someone has some deep knowledge regarding theses, please feel free to share how we could allocate more memory.
Since we are not able to allocate more memory using the VISA function at this time, we investigate doing the same operation using the LabVIEW Memory Manager Functions which allow us to allocate much larger memory block.
Below is the resulting code.

Unfortunately while we can validate that reading and writing to memory using this work well outside the context of DMA transfer, doing a DMA transfer do NOT work (although the board think it did and the computer is not crashing).
We are wondering why this is not working and would welcome any feedback.
Note: the DMA transfer implemented on the board requires contiguous memory for it to be successful. I believe that the LabVIEW Memory Manager Functions do allocate continuous memory, but correct me if I am wrong.
To troubleshoot this, I did allocate memory using the LabVIEW memory manager function and try to read it back using VISA and I got a "wrong offset" error (Note: This test may not be significant)
Another data point; while the documentation for DSNewPtr do not talk about DMA transfer, the one for DSNewAlignedHandle does. Experiment using LV memory manager Handles has not got us anywhere either.
We would welcome any feedback regarding either approach and about the LabVIEW Memory Manager Functions capabilities in that use case.
Thanks in advance.
PJM
Note: We are using LabVIEW 2014 if that matter at all.