LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Tektronix mso4 series reading data

Solved!
Go to solution

Hi all,

 

I am trying to read the data off a Tektronix MSO4 series oscilloscope using SCPI commands and i am always coming up with different error codes. The two I get are -1073807331, and -1073807399. I believe these codes are relating to timeout/ communication issues with the scope. 

 

Also along with the read area the write commands are only working some of the time, I am ensuring the visa session is closed after each run through.

 

I have attached the VI below, let me know if you need any more info.

 

Cheers

0 Kudos
Message 1 of 14
(1,725 Views)

Hi apowell17

Both first and second errors have proper solution articles. I have attached them below, try to go through that articles to solve this issue. 

  1. Error -1073807331 When Using a VISA Property in LabVIEW - NI
  2. VISA Error -1073807339 (0xbfff0015) Timeout Expired Before Operation Completed - NI

Regards)

0 Kudos
Message 2 of 14
(1,691 Views)
Solution
Accepted by topic author apowell17

You're using "Bytes at port" property nodes which are supposed to be only for Serial communications when you're using a USB device address.

 

Even if you were using a Serial device, 99% of the time you shouldn't use "Bytes at port".  If you don't know what to wire to the "Bytes to read" input, just try a large number (1000).  You may need to set up VISA to use a termination character, in this case an LF.

 

Also you're using a "VISA Clear" when you probably want to use "Flush buffer"

 

The MSO4 series should have an Ethernet port with LXI, can you use that instead of USB?  I find it much more reliable.

 

Have you tried or looked at the premade drivers?:

https://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=5384DD4E307874B7E05400144FFBB...

Even if they are missing a function you need, using them can prove that communication works and will give you a template of sorts you can follow to create your own, working, VIs.

Message 3 of 14
(1,680 Views)

 

The MSO4 series should have an Ethernet port with LXI, can you use that instead of USB?  I find it much more reliable.

 

I can't agree more about this point. the communication seems always stop when connected with USB while LXI is ok.

0 Kudos
Message 4 of 14
(1,661 Views)

Hi all,

 

Thank you very much for your help. Will try a few of these solutions today and let you know how i get on.

 

Cheers

 

Alex

0 Kudos
Message 5 of 14
(1,627 Views)

@yeah wrote:

 

The MSO4 series should have an Ethernet port with LXI, can you use that instead of USB?  I find it much more reliable.

 

I can't agree more about this point. the communication seems always stop when connected with USB while LXI is ok.


I have a general rule of avoiding USB whenever possible.  My order of preference for instrument communications is Ethernet (ie LXI), Serial (RS-232 or RS-422), GPIB (mostly due to cost), and finally USB.  If I do have to use USB, I'm using a commercial grade externally powered USB hub.  I do not trust USB hubs on motherboards.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 6 of 14
(1,612 Views)

So the issue is now fixed, since i removed the 'bytes at port' for a constant and removing the 'visa clear' it is seeming to solve the issue and i am not getting any more errors

At the moment i am still using USB, but am looking to use ethernet instead after the advice from everyone, as i have had a few reliability issues with usb cross multiple instruments.

0 Kudos
Message 7 of 14
(1,604 Views)

@apowell17 wrote:

At the moment i am still using USB, but am looking to use ethernet instead after the advice from everyone, as i have had a few reliability issues with usb cross multiple instruments.


Some advice for when using TCP:

1. Have a private network dedicated to instruments.

2. If you need internet access on your computer, use a second NIC.

3. Use a good Ethernet switch.  No real need for a full up router, but you still don't want a cheap switch/hub.

4. Used fixed IP addresses.  This just helps sooo much for setting up and debugging, especially if you standardize your IP addresses across programs.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 8 of 14
(1,586 Views)

@crossrulz wrote:

3. Use a good Ethernet switch.  No real need for a full up router, but you still don't want a cheap switch/hub.

 


Got any specific recommendations for what constitutes a good switch, or which ones you prefer?

0 Kudos
Message 9 of 14
(1,576 Views)

At my company we've found that the best "switch" is no switch at all, but rather we just add on extra Ethernet ports to the PC and connect all of the equipment to the PC directly.  

 

  • Prevents loops from forming if someone connects the switch to itself
  • Prevents the chance 2 PCs get connected to the same switch and try to use the same equipment
    • Also prevents the switch from being connected to your main company network and potentially allowing anyone anywhere access to them or interacting with DHCP without intending to
  • Allows use of different IP ranges (for instance, if one device insists on being on 192.168.*.* and another wants to be on 169.254.*.*) on a device by device basis
  • You can tell which device is on and plugged in by seeing which ports on your PC show as connected (as opposed to looking at lights on an Ethernet switch)
  • Prevents the switch being a point of failure (admittedly it adds failure points to your PC, but in my experience PC network cards are less likely to fail and when they do it's more obvious, i.e. Windows shows failure messages or they just disappear from Device Manager)

 

There are some drawbacks, i.e. you have to know which PC port connects to which device, you have to manage the IP settings for all the ports, but overall it works great for us.

Message 10 of 14
(1,571 Views)