Jump to content

My VI only works when you first run it then it stops working


Recommended Posts

I am using Labview 8.0, trying to makie a client that constantly reads in string data from a linux-pc that ends with Line Feed Characters. Also I need to be able to send command strings to linux-pc at any given time, keeping the connection active until I want to close it.

 

The Linux-server will respond "OK" if the command is valid, and "ERROR" if it is not. The messages are variable length and not fixed length. My vi sends the command to the server when I first run the VI, but if I try to send another command, it doesn't send, nor does it receive any new data from the server.

 

Any help is appreciated!

 

TCP_TESTER.vi

Edited by Mark Zacharoni Hamilton
Link to comment

Quick guess - is the buffer getting overrun/full?  Your boolean control is set to a "latching" mechanical action, so when you ask it to send a command, you are most likely send a LOT of commands (only a 5 ms wait in each loop).

 

Also, you might want to wire through the TCP reference to a shift register.

  • Like 1
Link to comment

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 David Akinpelu
      I am implementing a TCP connection between MyRio(client) and Python(server). The goal is to send data from the server to the client, perform some calculations, and send the result to the server. I need to keep changing the data being sent to the client. I noticed the first data works fine and the result returned to the server, but the client could not read subsequent data. I debugged and was able to detect that the error is coming from the first read function is the "Reading values subvi"  but I don't know how to correct it. How do I go about it?
      I have attached the files below.
      Reading Unknown Bytes from TCP.vi Second_client.vi SimpleServer.py
    • By Diegodemf
      Hello, I'm trying to send data from my RPI b+ to labview and store the information in a spreadsheet, right now the data I'm using is just a sawtooth generated in the python code but eventually it will be sensor data adquired via spi, the data comes at =~ 6-7khz but the time it takes to send the data to labview is much greater, I fear the circular buffer I intended to use to store the data before sending it via tcp will get filled pretty fast. I'm not very experienced in either python nor Labview, I was wondering if i could get some advice in the optimization of the code.

      I attached the VI of the client and a VI that graphs the data on the spreadsheet, also the python code.
      Thanks in advance, sorry for the mess.
      Waveform Grapher.vi
      Client.vi
      serverSerial.py
    • By bigjoepops
      I am working with a Universal Robot arm.  I believe it is a UR-5.  I was under the assumption that it could be controlled via Modbus, but I found that was incorrect.  I need to use URScript commands.  I am having a hard time getting started with this.  I was wondering if anyone has written a VI that would control the movement of one of these robot arms.
      Thanks.
    • By Zyl
      Hi everybody,
       
      I'm actually running on a problem with a  TCP connection between 2 cRIOS.
      One cRIO is a server which writes 76 bytes long messages every 10ms (today, but can be anything between 1ms and 1s) using STM Write VI (so at the end it pushes 82 bytes long message in the TCP write function). I want that message to be sent only if the client as time to read it, so I set the timeout to 0.
      The other cRIO is a the client with tries to read on the TCP link at a speed of 1000Hz (1ms, Wait next Multiple used to ensure that the loop is not running faster). I use the STM Read VI to get the data sent from the other cRIO. The read function has a timeout of 100ms.
      What I was expected is that the client loop would actually runs at 10ms rate (server writing rate) due to the 100ms timeout. And if the server writes faster, it would follow the server rate. If the server rate is greater that 100ms, error 56 would be fired, and I would handle it.
      What happens is that the server writes the 82 bytes every 10ms. But the client loop is always getting data and runs at 1ms ; which means that the timeout is not respected ! I disabled Nagel algorithm on the server side to be sure that the message is sent when requested, but it didn't help. The client acts like there is always data in the read buffer. Even if it can be right for the first iterations, I would expect that running at 1ms rate, the client would empty the buffer rapidly, but it seems that it never ends... Moreover, the longer the server writes, the longer it takes for the client to see empty buffer (timeout reached again and error 56) when the server is stopped (but connection not closed).
      Does somebody already ran into this issue ?
      Any idea on how I can solve this ?
       
      Server code is attached to the post. 2 TCP connections are established between the server and client (so same IP address, but different ports), but only one is used (upper loop). The other opens and close immediately because EnableStream boolean is always false.

    • By mhy
      How do you decode, unpack a flattened string in python which was sent by a LabVIEW TCP server?
      I want to exchange data via loopback. Therefore I take a sine wave and flatten it to string and sent over the network Simple TCP - ServerSINE.viSimple TCP - ServerSINE.vi. Then I have to decode the incoming data in a way that I have the correct numerical values like when I plot them in LabVIEW. I did this so far in python_client.py but the values are wrong.
      Does anyone know how to work with the transferred Data in python?
×
×
  • Create New...

Important Information

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