Jump to content

Deon

Members
  • Posts

    19
  • Joined

  • Last visited

Posts posted by Deon

  1. Hi Shaun

    I would have been interested but have only just seen your post.

    Albert Lederer developed a dll wrapper suite that is available from this link:

    https://forums.ni.com/t5/Example-Code/Using-RTL-SDR-with-Labview-Chapter-1-Labview-on-Windows/ta-p/3538774?profile.language=en

    Works very well and I have developed an FM radio using his code and the Nooelec NESDR Mini device.

    Hope this is useful to you.

    Best regards Deon

    image.png.aed8a684663db80b2982f1fe3347de4e.png

    • Thanks 1
  2. How to Downgrade DataSocket Server (DSS) to 4.0

    • Download LabVIEW Run-Time (LVRT) Engine 6.1 Installer
    • Delete the Datasocket folder in Program Files/National Instruments (! this is very important !).
    • Now run the LVRT 6.1 installer and allow it to do a default install.
    • Run the DataSocket Server file cwdss.exe in Program Files/National Instruments/Datasocket and wait for it to initialise and open.
    • Click on the DSS menu Help/About Datasocket Server and verify that the version displayed on the About panel indicates 4.0

    The reason for downgrading the version of DSS is that LV code running in v6.1 had issues with communicating with a later version of DSS, specifically the one shipped with LV 8.6.1.

    Initially the comms starts off working fine but eventually the DataSocket Server hangs and crashes LabVIEW.

    Click here to view the article

  3. Threshold Hysteresis v1.0 LV8.6.1


    The Threshold Hysteresis VI allows an input (for example, a sensor) to drift out of an inner limit without generating an invalid flag, but if it drifts outside an outer limit it then becomes invalid. For the reverse, when the input crosses back into the outer limit it remains invalid until the value falls inside the inner limit.
    For simplicity, only one input parameter is provided for both the inner & outer limits, and is negated for the lower limit, as generally tolerance limits are equidistant from the nominal.


    • Submitter
    • Submitted
      11/10/2014
    • Category
    • LabVIEW Version
    • License Type

     

  4. QUOTE(jpc @ Nov 16 2007, 11:53 PM)
    We are experiencing what we believe is a memory leak in Labview 7.1 when attempting to open and reopen an ODBC connection to a SQL database.I have seen this topic mentioned in several places...http://forums.lavag.org/Memory-Leak-t9438.htmlhttp://forums.lavag.org/Memory-usage-issue...lkit-t6570.htmlhttp://forums.ni.com/ni/board/message?boar...essage.id=53391...but, the problem resolution seems to be to just open and close the connection once. OK, you lose 4K of memory and no big deal.But in our case, we have a control system reading and writing to a SQL database at regular intervals, and would like to re-establish that connection automatically if it becomes broken (server crash, maintenance, backups, etc.). So the app was designed to loop every few seconds trying to reconnect. We wrote the code, it works well unless the server is down for extended periods of time. Then we noticed the app crashes from depleted memory. We isolated the problem to an open/close connection problem just like in the links above.So my questions are:Has this been confirmed to be a Labview problem?Or is it a ODBC problem with SQL?Does anyone know if NI has ever addressed this issue?And, yes, we have a workaround in place. The error is flagged and an operator must manually reconnect when the server is determined to be back online. We cannot risk crashing the control system. We would like to go back to the automatic reconnect, but I still haven't seen this memory leak problem resolved. My colleague who wrote code claims Labview 8.5 still has not fixed this problem.-John
    QUOTE(jpc @ Nov 16 2007, 11:53 PM)

    ...but, the problem resolution seems to be to just open and close the connection once. OK, you lose 4K of memory and no big deal.But in our case, we have a control system reading and writing to a SQL database at regular intervals, and would like to re-establish that connection automatically if it becomes broken (server crash, maintenance, backups, etc.). So the app was designed to loop every few seconds trying to reconnect. We wrote the code, it works well unless the server is down for extended periods of time. Then we noticed the app crashes from depleted memory. We isolated the problem to an open/close connection problem just like in the links above.So my questions are:Has this been confirmed to be a Labview problem?Or is it a ODBC problem with SQL?Does anyone know if NI has ever addressed this issue?And, yes, we have a workaround in place. The error is flagged and an operator must manually reconnect when the server is determined to be back online. We cannot risk crashing the control system. We would like to go back to the automatic reconnect, but I still haven't seen this memory leak problem resolved. My colleague who wrote code claims Labview 8.5 still has not fixed this problem.-John

    QUOTE(jpc @ Nov 16 2007, 11:53 PM)

    ...but, the problem resolution seems to be to just open and close the connection once. OK, you lose 4K of memory and no big deal.But in our case, we have a control system reading and writing to a SQL database at regular intervals, and would like to re-establish that connection automatically if it becomes broken (server crash, maintenance, backups, etc.). So the app was designed to loop every few seconds trying to reconnect. We wrote the code, it works well unless the server is down for extended periods of time. Then we noticed the app crashes from depleted memory. We isolated the problem to an open/close connection problem just like in the links above.So my questions are:Has this been confirmed to be a Labview problem?Or is it a ODBC problem with SQL?Does anyone know if NI has ever addressed this issue?And, yes, we have a workaround in place. The error is flagged and an operator must manually reconnect when the server is determined to be back online. We cannot risk crashing the control system. We would like to go back to the automatic reconnect, but I still haven't seen this memory leak problem resolved. My colleague who wrote code claims Labview 8.5 still has not fixed this problem.-John

    Hi JohnI had a memory leak with MySQL using LabVIEW 6.1 and it turned out to be the version of OBDC driver. I had to revert to an earlier version, rather than the latest, to solve the problem; namely MyODBC-3.51.04.exe.Attached is the installation document I produced. Don't know if this will solve your problem, but maybe it will provide additional info to help you.Best Regards.

  5. QUOTE(Neville D @ Jul 21 2007, 01:45 AM)

    Hi Guys,

    I was trying to find App Note 168 the famous "LabVIEW Performance & Memory Management" bible on the NI web-site. It seems to have been pulled. It says refer to your LabVIEW help (which is a mish-mash of random thoughts in various different locations).

    Anybody have an old copy handy?

    Neville.

    Yip, find attached file.

  6. Hi Guys

    Just wanted to add my 2 cents worth! I am busy developing code for a FieldPoint Rt controller, and found DataSocket too slow, TCP too much hassle, and so settled on UDP to communicate between the Host PC and the RT module. Works very well.

    Also, as I'm programming in LV6.1, to pass data between the core & comms loops in th RT software, I used an ODM (Object Data Manager), which is simply a non-running While Loop with a shift register and a case statement to Set & Get the required data.

    Btw, I use complex clusters for all data communication and transfer.

    Thanks for a fantatsic site!

    Regards Deon.

×
×
  • Create New...

Important Information

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