-
Posts
152 -
Joined
-
Last visited
-
Days Won
12
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Olivier Jourdan
-
-
I don't think they'd be in memory.
If they are include in the EXE, I think they are in memory when the EXE is loaded. Try and let me know.
-
Hello,
Have you try to use "All VIs In Memory" application property ?
-
You can also trigger one of the other events by calling a property or method for the XControl.
As far as I know, if the dynamic process is part of the XC, you cannot use property or method owned by the XControl itself.
[LV2009]
Any thoughts?
FWIW:
The Value Signalling PN works fine when it is on the X-Control.
And the above runs fine when the dynamicVI is separated out of the X-Control.
More than a long text in a "crappy" english, I've attached a quick sample code (apologize for the messy G code, but it works) demonstrating what I've understood from your need.
- open the xctl file
- drop it in the New VI Front panel
- click on "Load // process" button
- send message from window to Xcontrol
Let me know if it helps you.
Regards
- 1
-
Anyone have a workaround for this or a better way to do the above?
This is definitely not a better way to do but maybe a workaround to try (I've implemented this solution in this XControl):
- Create an hidden cluster with a string and a variant in your facade VI
- Create an event case on Cluster "Value change"
- Give cluster reference to your parallel process
- Do "Value (signaling)" using the cluster reference to "fire event"
- Process action in the event case create in 2.
String and variant allows you to implement multiple action and different data to process in your facade VI.
Hope this can work for you.
Regards
Olivier
- 2
-
As a side note, I would test your toolkit on a NI Real-time controller running PharLap (any PXI system). PharLap is a stripped out version of Windows, so the toolkit might work as is. Might be another selling point. VxWorks would require you to look at the code in the article.
Hello,
I agree the RT interest. As a first step, I've run DLL Checker (found here) on sqlite.dll and result seems to show there are some "bad" functions... However, we don't investigate more on this for now.Regards
-
-
It was longer than we thought, but our toolkit is now available. Just run your VIPM 2010 app, a dialog window might prompt you to install SQLiteVIEW in your LabVIEW.
For more information just go here.
Regards.
- 1
-
If you change the Source Code Of Sqlite to fit your product, then I don't think you can call it Sqlite , because you are changing the source. If you are using a C-Wrapper around it then you are introducing another level of redirection and extra code to maintain. A c-wrapper will force you to reduce the functionality that you can provide thru your wrapper. I have been down that road and it's not pretty.
I think there is a misunderstood (probably due to my english level, I'm sorry of that and apologize). We don't have modified SQLite source code. We are using dll and library provided here for window and Linux. Concerning Mac OS X, as far as I know, we need a framework not a command line tool to be able to reuse the same LabVIEW code over the 3 Operating Systems.
Like I said earlier just wrapping the sqlite3.dll for LabVIEW is not going to be enough, you need to separate the programmer from the database, which you said you have such tools (Great), but also provide all the advanced functions that Sqlite itself already provides , see documentation.
For the first release, we will not provide all the advanced functions but the functions essential (for us) for execute query with "high performance".
I am not against a paid Sqlite-LabVIEW toolkit but only hope that a really Solid and worthy Toolkit is released that everyone can benefit, even the one who are capable of doing the work.
Believe me when I agree the "solid and worthy toolkit" terms. We can't think our product in an other way and I'll take all these feedbacks into account for the future version of SQLiteVIEW.
Regards
- 2
-
It seems that the amount of work involved isn't proportional to the price you're suggesting. Why so much? I can't afford it
Sell a product (we experienced this with a ModBus protocol toolkit since 1996) is not only provide a set of functional VIs. We have to
- provide full integration to LabVIEW with an easy and quick install process (thank you VIPM )
- provide support to customers (how to, documentation...)
- maintain toolkit over LabVIEW version (for example upgrade from LV8.6 to LV2009 has reveal a bug (already fixed ) in SQLiteVIEW
- improve the toolkit (performances, new features...)
and many other "little" hidden things.
As I said before the "right" price is very difficult to determine but keep in touch, there will be a significant discount for the release
If it is full blown implementation then it is a lot of work. I think, however, most people only need/use the basics. I just hope its not ADO or .NET.
It's not ADO or .NET, our toolkit is fully compatible with Linux (We are currently using it for a multi platform (Windows/Linux) application. Mac OS support might be possible, but we have to compile the SQLite source in a framework...
-
Lots of interesting comments and constructive feedback
I can appreciate a Toolkit that simplifies working with LabVIEW data and Database so that the programmer does not have to use a single SQL statement.We have these kind of tools but they need to be "clean up" to be integrated in our toolkit.
But now you can use the DLL-Import feature of LabVIEW and import the Sqlite3.dll and have yourself a fully working toolkit. After import you have to replace a couple of Type-controls to Int32 and you will be done in less than an hour.
We are not used to use this LabVIEW feature and we definitely not thinking that implement the ddl call was the most difficult to do. We also think that most of LabVIEW user are not familiar with dll and haven't time to do this work.
Regards
-
Hi all,
Thank you for your interesting comments.
I'll try to be more precise about our toolkit.
I, therefore, request a "community" or "educational" version that would allow for use of the toolkit past your trial period, but not for commercial uses.
There's no plan to support a "limited version" of our toolkit but it could be a way to democratize SQLite use, so...
After the evaluation, how much will it cost? How will it be licensed?
I can be intrested if the price is rigth
We don't really know what is the "right" price, but we know how many effort we've done to release this toolkit.
We've decided to sell it at 699$ and offer a special pricing up to the end of the year (a certain % discount not yet defined...).
The licensing is intended for a single computer activation. No runtime needed to build applications.
This is awesome news. A couple of weeks? I want it now!
we are working away to release SQLiteVIEW as soon as possible
Then take a look at this
I've took a look at this and it seems, as far as I can see, the "NI implementation" is quite more complex due to the execution on RT target. SQLiteVIEW only needs sqlite3.dll (or .so for linux OS) to run. Our toolkit also provides way to improve query execution performance using statement features and we have lot of other useful features to add to improve the end-user development experience.
Stay tuned to evaluate our toolkit for free. We are looking forward to know your feelings about it.
Regards
-
Hi all,
I've been working at SAPHIR for many years (SAPHIR is a 20 years old french company - www.saphir.fr). We have implemented DataBase (ACSESS, MySQL...) in several LabVIEW applications. Since one year, we are using SQLite database without any trouble and now we are pleased to announce the release of our new toolkit: SQLiteVIEW.
It will be available with a 30 days evaluation version. You can already read more about it here. You can also learn more about SQLite here.
We plan to release this toolkit in a couple of weeks and we hope you'll like it as we do
Regards
-
Name: AutoSave Combo Box
Submitter: odjau
Submitted: 02 Jul 2009
Category: X-Controls
LabVIEW Version: 8.2
Version: 1.0.1
License Type: BSD (Most common)
Make this available on the VI Package Network?: Undecided
Copyright 2007 SAPHIR (Olivier JOURDAN) All rights reserved.
Author:
Oliver JOURDAN
--see readme file for contact information.
Description:
Use auto save combo box control to save automatically new users entry in the predefine item list.
Features:
-Automatically save new combo box entry (available in development and runtime)
-Remove selected item (available in development and runtime)
-List of forbidden items (available in development and runtime)
-sort Items (available in development and runtime)
-Properties settable via friendly interface (available in development only)
Instructions:
Just unzip the code into any folder of your choice and select the file "AutosaveCombobox.xctl" as a control.
This code has been tested to run under LabVIEW 8.2.1
Dependancies:
None
Change Log:
1.0.1 Change to BSD Licence
1.0.0 Initial submission to the LAVA CR
-
Name: Capacity indicator
Submitter: odjau
Submitted: 02 Jul 2009
Category: X-Controls
LabVIEW Version: 8.2
Version: 2.0.3
License Type: BSD (Most common)
Make this available on the VI Package Network?: Undecided
Copyright © 2007 SAPHIR (Olivier JOURDAN) All rights reserved.
Author
Olivier JOURDAN
--see readme file for contact information
Description
Use capacity indicator to provide information about the level or amount of something that has well defined minimum and maximum values. For example, you might use a capacity indicator to showthe current level of storage-space usage on a server or the charge left in a battery.
Features
* Usefull interface to set properties (colors and threshold)
* All settings are modifiable by property
* Refresh value of capacity indicator with percent of disk used by method
Instructions
Just unzip the code into any folder of your choice and select the file "CapacityIndicator.xctl" as a control.
This code has been tested to run under LabVIEW 8.2.1
Dependancies
None
Change Log
* 2.0.3 : Change to BSD Licence
* 2.0.2 : Added comments and documentation - Fixed initialisation bug
* 2.0.1 : Initial submission to LAVA CR.
-
File Name: History
File Submitter: LAVA 1.0 Content
File Submitted: 03 Jul 2009
File Category: Custom Probes
LabVIEW Version: 8.2
File Version: 1.0.0
License Type: BSD (Most common)
Potentially make this file available on the VI Package Network?: Undecided
Copyright © 2007 SAPHIR (Olivier JOURDAN) All rights reserved.
Author
Olivier JOURDAN
--see readme file for contact information
Description
Use this probe stored string in a buffer and display this buffer.
Instructions
Just unzip the code into following folder: ..\user.lib\_probes or .. \LabVIEW Data\Probes
This code has been tested to run under LabVIEW 8.2.1
Dependancies
None
Change Log
* 1.0.0 : Initial submission to LAVA CR.
-
File Name: Details
File Submitter: LAVA 1.0 Content
File Submitted: 02 Jul 2009
File Category: Custom Probes
LabVIEW Version: 8.2
File Version: 1.0.0
License Type: BSD (Most common)
Potentially make this file available on the VI Package Network?: Undecided
Copyright © 2007 SAPHIR (Olivier JOURDAN) All rights reserved.
Author
Olivier JOURDAN
--see readme file for contact information
Description
Use this probe to display string in different mode and to have the size of the string.
Instructions
Just unzip the code into following folder: ..\user.lib\_probes or .. \LabVIEW Data\Probes
This code has been tested to run under LabVIEW 8.2.1
Dependancies
None
Change Log
* 1.0.0 : Initial submission to LAVA CR.
-
CITATION(Dave Graybeal @ Jul 28 2006, 01:19 PM)
Another option is in LabVIEW 8.0, The SubPanel Control has an option that you can turn on to allow opening of the Block diagram. This allows you to open the block diagram of an embedded VI while the application is running in the subpanel by right clicking on the subpanel and choosing open block diagram. I use this feature a lot for debugging and it works great.Hi, I'm using this feature since many years... Unfortunately, it seems to be bugged in LV8.6 someone can confirm this ? (I tried on 3 different PC running windows XP, same "code" works fine with 8.2.1 and 8.5.1).
Regards
odjau
-
Hi,
I'm a bit scared about user event in XControl. In my experience user event are processed by facade VI, only when a "standard" event is handle... but I'm interseted by any new solution to improve XControl use, so I'll read this topic with many attention
Bye
-
CITATION(jaegen @ Sep 15 2007, 02:00 AM)
It appears that an XControl inside a cluster type def never fires the "Data Change" event.Is this a bug?
Hi,
Perhaps the bug is that LabVIEW allow you to place XControl in a cluster.
Like it's says in the WIKI, XControls (like subpanels) cannot be placed in an array... Subpanels cannot be placed in cluster as well...
But, I know how it's frustrating to cannot do it...
ptit bras
-
CITATION(tcplomp @ Jul 19 2007, 04:42 PM)
Invisible means transparent, so you can't see it , but it is there.Haven't checked the 'drop' event.
But then I believe a OS drag and drop isn't covered in LabVIEW (yet?)
Ton
Could you post some code, because I can't reproduce your "bug" :headbang:
The only way to reproduce the behaviour is to change path as an indicator ( but I don't think that it's your problem)
Last question, what do you mean by "external applications" (Drag from Explorer or drag from other application made with LV)
Ptit bras
-
-
-
-
CITATION(ptit bras @ Jul 10 2007, 12:22 PM)
Yes, it's work :thumbup: but what is the workaround (appart from delete drag enter event case) ???I found two other diferences :
- function "to variant" in DragStarting? event => this is not useful for the workaround
- WaveformGraph local variable in "Drop" event of Facade.vi => this is the workaround, but it's very supernatural !!! If you probe output of "Get Drag Drop Data" function, the wire is empty !!!???
It works but, it seems to be risky to use this in industial application
In any case, thanks all for helping me :worship:
How to get list of dymanic VIs included in an executable?
in Application Builder, Installers and code distribution
Posted
You are right, I've never test this because I use an another way to load dynamic VIs.
If you use Static VI Reference (see attachment) :
- You don't have to add explicitly your dynamic VI in your build specification
- You can rename your dynamic VI worriless
- Your dynamic VI is hidden from end-users
- code is the same in development or runtime
As far as I've understood the question, I think this can fit with the issue.
Regards,