Jump to content

Recommended Posts

In my project i have 2 task

 

(1).Read data of sensor (attached to arduino board) serially  and display on LabVIEW.

(2).Control output(just ON-OFF) pins of arduino using LabVIEW.

 

 

So,for that i am using TAB in labview.created 2 TAB called Oscillospe and Input.

 

If i first start Oscilloscope it work well.

But when i come to Oscilloscope tab after using Input tab.

 

It gives Time out error (VISA read)

 

If i am executing in Highlight mode it works well

 

tab--event.vi

Link to post
Share on other sites

I feel like you don't fully understand how event structures should be used.  So if your VI starts, it will init VISA with the port selected.  At no time after starting the VI will you be able to change the com port.  This maybe fine for your test but for a real built application your VI will start running before you can interact with the controls.  

 

Then your event structure will wait forever, idle doing nothing, until you change the tab control...is this what you want?  Wouldn't it be best if you read the value of the tab and then acted on it?

 

But i think the source of your problem is that you only are writing "oo" once then reading over and over, but your device probably only sends it out once for every request.  

 

Attached is an updated version that also has some basic error handling (stop on error and display the error).  It also allows for changing of the port and baud rate while running, and supports the normal windows close methods to stop.

Tab Event Hooovahh Edit.vi

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By ThomasGutzler
      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?

    • By RMowatt
      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!
    • By Ricardo de Abreu
      Hi guys. This semester I'm starting a course system development for control and automation engineering, witch will be based on LabView. Therefore, my University doesn't have a NI hardware, even a MyRIO for us to test our VI and the teacher said that we should test our projects with our own Arduino...
      So, I have a little experience in Arduino and I know the basics for LabView. Now I'm in a point that I know that with Arduino I'll not take the best from LabView. I cannot even deploy a code to it.
      So, there is where my question comes in...
      I'm looking for a new board better then Arduino to use in the classes. I would buy a MyRIO card if I had the money but in Brazil this board is too expensive for me
       Witch one should I get that is closest to myRIO and less expensive than that? I would like to try de deployment of a VI and FPGA..... Is this possible?
      Thanks a lot for the help!
      Regards
    • By Benoit
      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
    • By szewczak
      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.
       
       
       
       
       
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.