Jump to content

Diegodemf

Members
  • Posts

    4
  • Joined

  • Last visited

Posts posted by Diegodemf

  1. 11 hours ago, smithd said:

     

    However this will increase latency. That is the tradeoff. To be reasonably efficient with the network you'd need to transfer bursts of ~20 samples over wired ethernet. 

    How real-time is real time? What does the labview code do with the information?

    Then my answer would be that you should write to a file, but as above it depends on exactly how important it is. What happens if you lose a sample? What happens if the network disconnects for 30 seconds?

    Yes, you would have to split the file up yourself. The strategy I follow is to have a directory /data with a file /data/temp.ext and a subdirectory /data/done which contains data1.ext, data2.ext, etc. I then use the built-in labview FTP (I believe the connectivity palette but I'm not sure) functions to fetch files out of the /data/done folder. That way I don't accidentally pull off a half-finished file. This appears to be automated in python: https://docs.python.org/3/library/logging.handlers.html#rotatingfilehandler and https://www.blog.pythonlibrary.org/2014/02/11/python-how-to-create-rotating-logs/

    If you don't like FTP for some reason, someone put together a winscp wrapper library: https://lavag.org/topic/20474-free-labview-winscp-library/?tab=comments#comment-124582

     

     

    After the acquisition of the data the goal is to calculate and graph Electric power with the Voltages and currents and several factors related to it as phases, harmonics, power factor,max values, sudden changes,etc.

    As of now i'm only graphing  with the VI listed above, I'm doing this right now reading the file written in the PC, but this is something I need to work at.

    The device should be acquiring data for around 2 hours, losing 1 or 2 samples in between should not be a big issue but losing 30 secs of data might be important, the information should be as reliable as possible, in that way, writting to a file seems to be the more reliable option to store the data with the least amount of loss.

    I'll take a look into the FTP matter and get back at you, thanks for the help

  2. Hello, thanks for the answers.
    Right now the connection is made via wired ethernet (LAN) but ideally it would work with wifi as well

    Yes, I want to stream data, having a bit of initial latency is okay, as long the throughput is continous afterwards, the application has to work on real time. Via SPI we will get 7 measurements, the application will be for power measurement,  via SPI I get 7 words of 16 bits each, thats the info i want to forward, using numbers of that size in the example the function socket.send returns 60 bytes send( i assume this is without the headers) . You're right I do not need to send data from Labview to the RPI, i can try to make the server in Labview and the client, but i think i will still need to gather a good amount of measurements to send it in a big packet to improve the speed.

    The most important thing is reliability, I have thought of ftp/scp but i haven't found a way to connect those services directly with labview and automate the process of reading on the PC and erasing the file on the rpi, as the space is limited on it, the data would need to be separated in several files and erase the earlier ones as it writes the new ones.

    Any suggestion? Thanks in advance.

  3. I like your idea, and will probably try to adopt it, but I didn't get much of an improvement in terms of performance, I have tried just with the tcp read part and the time is similar. I think my option is increasing the size of the packet sent each time, but with 6000 bytes the inmediate setting its not working correctly, it sends "?" several times between reads, the speed is a little better:

    image.thumb.png.bc14050e12e2ac4ed326424068753491.png

    Using standard and 30ms timeout I get less errors but the speed is much worse:

    image.thumb.png.5931d3753d4eb2982857d22724fed937.png

    Also with this solution i would need to rearrange the array efficently, and for some reason the unflatten from json throws me no data( neither in this new setup nor in the previous one, I have had to parse manually)

  4. 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.

    image.png.37a88c58f2590ccb515199adbeafbb41.png

    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

×
×
  • Create New...

Important Information

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