Jump to content


  • Posts

  • Joined

  • Last visited

About osvaldo

  • Birthday 01/16/1971

Profile Information

  • Gender
  • Location

LabVIEW Information

  • Version
    LabVIEW 2020
  • Since

Contact Methods

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

osvaldo's Achievements


Newbie (1/14)



  1. Damn! You are right! When I create the new file I run 3 insert queries to set some default values in the tables. In the last of these queries the VI Finalize was missing and remained open! (damn copy and paste!) I was concentrating on closing the file when the problem occurred an hour before it was created! Thank you so much again! Osvaldo
  2. Thanks for getting back to me so quickly! 🙂 In fact I haven't checked ... I hadn't thought about the possibility that the last insert query might not have ended when the Close was executed. I do some tests and check for any errors. Thank you so much !
  3. Good evening everyone. I have a problem with SQLite file locks ... I created a datalogger in Labview that saves the data acquired from a customer's custom equipment in an SQLite database. I used Powell's library (an egregious library!) Although the capture is continuous, the data is not stored in a single SQLite file but on different files lasting about 1 hour each. At each time change the software closes the database currently in use (with SQLite Close) and create a new one. The database reference remains open all the time until it is closed at the next hour change. These SQLite files are downloaded from another application running on a second PC using FTP. (the machine running the data logger has a FileZilla server) What happens is that it is not possible to download any SQLite file created by the data logger until the application is stopped! By stopping the application and restarting it, you can download all the files created before the restart but not those created afterwards! It is as if a lock is maintained on all files created until the program is closed! I would expect the lock to be present on the file currently in use, but not on those already closed. Has anyone experienced this behavior before? Thanks for any help you can give me. Osvaldo
  4. Thanks for the reply Hmm ... Yes ... In fact it would seem that way ... would require that only the class can instantiate DVR relative to a subclass B derivative of it. The only pattern that comes to mind is the abstract factory, but not I see a use case that requires the option in question ... On the Internet I found no example where this approach was used. Maybe I'll understand the meaning if I happen a situation that makes clear the need for this setting. At the moment I'm just studying the object model of LabVIEW trying to bring him back to what we already know. Thank you Osvaldo
  5. Goodmorning everyone! We program in LabVIEW for a long time (fifteen years), but only recently have I been able to devote to learning OOP techniques with LabVIEW. I state that I have little experience in general with the OOP having in fact only a theoretical knowledge of the concepts and patterns and few experiments made in Pascal ... (eh ... eh ... ) I come to you humbly ask for the meaning and use cases of the "Restrict references of descendant class type to member VIs of this class." In the tab on inheritance I could not connect this option with any of OOP concepts known to me. Thanks for your help. Osvaldo
  6. I do not know ... During the process of packaging, VIPM freezes and I have to stop killing the process ... Curiously, however, remains open window of the VI OpenG Builder ...
  7. Thanks jgcode... I have cross-posted even there, but I thought that perhaps some of you might have encountered the same problem ... However, I will follow your advice and try again even on the forums .. JKI Have a nice day Osvlado
  8. No one have experienced the same issue? No idea on how to fix this problem or where it can be located in the OpenG Builder code? Thanks. Osvaldo
  9. (cross-posted in http://forums.jki.net/topic/1324-recursive-vis-cannot-be-built-in-package/page__gopid__4548#entry4548) Hello to all, boys, I'm using VIPM ver 2011.0.1 (build 1692) dic 07/2011 Community Edition with OpenG Builder ver 3.0.1-2. I am trying to create a package to a library for LabVIEW 2011 that uses recursion native, but Package Builder gives me the same problem described by Kring to "Known Issue (Case 8006): VI Package build hangs in LabVIEW 2009 when recursive VIs included in package" and stated fixed from version 3.0 and later ... I think in my case the problem is that recursion is not "direct" ... Let me explain ... In my library there is the following sequence of calls: VI_A call VI_B that call VI_C that call VI_A! If I realize the simple recursion VI_A call VI_A, the Package Builder executes with success, but building my library, it fail waiting infinitely for the VI to load in memory... the same issue reported by Normandine... Even in may case, I have to kill the process. I do not know if Package Builder maintains a global list of calls, but I think the problem may reside in the test that checks for the sub-VI called the list of callers ... I'm sorry it could not provide a possible solution ... :-( Thank to all! Osvaldo
  10. Ok! Thankyou! I use it like tag variables... I'm writing a library based on the idea of the NI CVT reference Library where the inner data storage based on Arrays where replaced on a number of dinamically created notifiers, one for each tag defined... My hope is that each reading/writing operation on notifiers is decoupled by each other, so that different loop can run in parallel so much as possible (the implementation of the original CVT reference library serialize all access on the AE that encapsulate the assary it self...) Ok... Ok... I could used the Shared Variables, but when the library development was started, no Shared Variable API was avaiable... Have a nice day! Osvaldo
  11. Hi Very interesting! So... speaking to the guy who writed the primitives... what about the Notifiers Primitives? I usually use them to send signal (like booleans to quits parallel While loops, o to send chuncks of data asynchronously to many consumers), but now I'm working on an library that will use them to broadcast data to parallel tasks (using named notifiers)... Any issues? On realtime targets? Thanks Bye! Osvaldo
  12. happy to be of help! Osvaldo p.s. where you came from?
  13. Hi mandya14, Sorry for bad English ... but not my mother tongue ... Let me understand... I guess you a while loop containing a VI (from your device driver toolkit) that returns the status of DIO and you set the value of this DIO directly into a boolean indicator through its terminal. On the other hand you have another while loop that contains an event structure with which you collect the event "value change" on the indicator whose value is set from the di DIO... I understand you correctly? If it is correct, your problem is that setting the value of an indicator in this way *does not* trigger any "Value Change" event! If instead of using an indicator you use a control (of course you should set its value though its local variable), then when the program writes the new boolean value, automatically would be triggered a "value change" event that you can catch with the event structure. Osvaldo p.s. The comparision would be done between the new value en the old one memorized in an shift register or using a feedback node...
  14. Hi mandya14, i think that is impossible for an indicator to send an event at an event structure... Even in my last project a find that a numeric double indicator does not trigger any value change event... In my application the event would be sent when the I/O loop change the value via the Value (trigger) property... Even a control with the Disable property set to 1 or 2 is not able to trigger events! To solve the problem, i change the indicator with a control and than I put an rectangular trasparent decoration to mask the control itself... Or make a tiny loop that trigger the event whenever detect a change in the boolean value... Osvaldo
  15. Oh! This is an idea! I never thought of! Thanks! Osvaldo
  • Create New...

Important Information

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