-
Posts
955 -
Joined
-
Last visited
-
Days Won
34
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Antoine Chalons
-
-
QUOTE (Ton @ Feb 3 2009, 11:46 AM)
Ok, thanks for the help, it *slowly* starts to make sense in my brain..
by the way, be careful with upper/lower case, Category:Application_Control does not exist yet, Category:Application_control does
-
QUOTE (crelf @ Jan 23 2009, 03:26 PM)
I've tried but without success I then saw that Michael managed to publish what I failed to publish.
If someone can tell me why the page : http://wiki.lavag.org/Category:Application_Instances does not exists (this is the one i tried to create) and why it is instead this :
[url="http://wiki.lavag.org/index.php?title=Http://wiki.lavag.org/Category:Application_Instances"]http://wiki.lavag.org/index.php?title=Http...ation_Instances[/url]
From reading to Wiki help it looks quite doable to publish a nice article but I just can get it correctly
-
-
QUOTE (stever @ Feb 2 2009, 06:02 PM)
Antoine,Thank you very much for your speedy reply. I will have a look at the code in the link you provided to the other thread.
Here is some info on my application:
- Need to acquire at full frame rate of the camera, which is currently 60 Hz, but might be faster in the future (up to a few hundred Hz)
- We cannot lose frames, and each frame needs a millisecond-based timestamp (this is a scientific application, not for human viewing of frames)
- Modern PC (will eventually be on quad-core Core 2 with 4GB RAM, XP 32-bit, SATA HD non-RAID)
- NI 1427 frame grabber
- Sensors Unlimited SU320KTSX camera
- We have to display frames, but not necessarily every single one (enough so the operator can see what's going on)
- It'd be nice to do some processing on these frames before display, but if that's too slow, not a problem to skip this
- Capture triggered by user pressing a button
- Capture needs to be able to run essentially indefinitely, but probably wouldn't be for more than a couple hours.
Using:
- LabView 8.6
- IMAQ 4.1
Thanks again,
Steve
I guess frame site is 320*240, right ?
At 60Hz, if you choose 12 bit resolution that's 60 [Hz] * (320*240) [pix] * 12 [bit/pix] / 8 [bit/byte] = 6.59 Mo/s
That's a fairly low rate in terms of data to write to disk, but you'll have to manage the disk space if it runs for many hours (each hour will be 23 Go )
I think the "concept" of code I posted in the other thread applies well to your application, feel free to post any question you might have.
Hope this helps.
-
QUOTE (stever @ Feb 2 2009, 04:01 PM)
I'm just realizing that this thread is related to http://forums.lavag.org/not-saving-at-required-frame-rate-t11317.html' target="_blank">another one here. Same person starting the thread and same application apparently.
I think the code I posted on this thread can be used to do image streaming, depending on your specs (frame rate, number of images to save) it might not be an appropriate solution.
Tell us a bit more on your application.
PS : the code I posted on linked thread is a light version of a working application that worked very well for me with an A302 basler camera, the specs were 30 images per second during 10 minutes, every images had to be processed and the display and also saved to disk.
-
QUOTE (harika @ Jan 30 2009, 12:43 PM)
hi,how can we convert an vi to exe file.please help me out.
Thanking you,
Harika.
Hi,
I assume - from seeing your profile settings - that you have LabVIEW 8.6.
First, to be able to build exe you need to have the FDS (Full Development System) or PDS (Professional Development System) version of LabVIEW, the base LabVIEW can't build exes.
Then if you have FDS or PDS, you must create a LabVIEW project and put your VIs in it to be able to build an exe (that was one of the big changes from LabVIEW 7 to LabVIEW 8).
In the project windows, right clic on "Build Specifications" and select "New.. > Application (EXE)"
Hope this helps
-
I wish I could password protect a control VI (typedef or strict typedef).
If I have a password protected VI that uses a typedef, I want to be able to protect the typedef from modifications, otherwise that can break my password protected VIs
-
-
-
QUOTE (neBulus @ Jan 29 2009, 03:24 PM)
Based on the fact that we have an option under tools (?) "Clear Password cache" NI did put some thought into keeping the password in a cache. Ibeilive this is what makes it impossible search an entire hierarchy and only have to enter the password once for all VI protected by that password.QUOTE
Once a password is entered, it stays cached until you restart LabVIEW or clear the cache.Well true... That's what I put in my EDIT, but.. I don't know..
I didn't know about that "clear password cache" option and so I made an utility VI that will recursively get all the VIs in a folder and lock/unlock them with a password ; when I noticed the behaviour I was really surprised and even if now I do understand it makes sense I'm still a bit doubtful...
But ok, feature then. Not bug.
-
Say I have 2 VIs a.vi and b.vi and both are password protected with the exact same password.
Then try that :
- open a.vi
- hit "ctrl + e"
- enter the password
>> you see a.vi's block diagram.
- open b.vi... surprise, it's unlocked and you don't need to enter the password to see the block diagram.
For me it's a bug because if a.vi and b.vi have different passwords it does not happen.
I thinks I should move this to the bug list section, any objection ?
[EDIT]
The only reason why I didn't go straight to bug list section is that I was trying to imagine the nightmare for those NI lads working on some NI password protected code... if they have to enter the password for every single password protected VI
-
QUOTE (PaulG. @ Jan 28 2009, 03:42 PM)
Have they ? I didn't know about that.. does it mean they have reasons not to support comments ?
QUOTE (PaulG. @ Jan 28 2009, 03:42 PM)
I usually ad comments to my config files after I've created them but it would be convenient to be able to read/write comments in my code.I hadn't even thought of being able to read/write comment , but it's true it would be nice.
I was merely hopping that if I put comments like this :
[SECTION_1] key_1=10 ; this is a comment for key_1
LabVIEW wouldn't turn it into that :
[SECTION_1] key_1=10 ; this is a comment for key_1=""
-
LabVIEW Config Files functions don't support comments such as described here, I wish they do in the futur.
-
I have noticed that some analysis functions - from the spectral analysis palette not to mention it - are pretty inefficient both in terms of speed and memory usage. Sometimes, a 2h refactoring on these can dramatically reduce memory usage and increase calculation speed by up to 30x .
which leads me to ask the same question as AQ : what kind of analysis are you doing ?
-
QUOTE (BOBILLIER @ Jan 27 2009, 06:14 PM)
HiFew time ago i have make this small tool to move scale. Perhapse that can help you.
2) Select your vi in "Vi ouvert" list
3) select the graph in "Nom des graphes"
5) select scale with "nom des échelles"
6) move the scale with arrow and see it in real time on your Vi.
http://lavag.org/old_files/post-5178-1233076390.llb'>Download File:post-5178-1233076390.llb
Nice tool !
The "move up" and "move down" functions don't work in LV 8.6
-
hi,
you must have done something to move it because by default it comes centered on the graph area
I couldn't find the right setting so a made a small method to center it using the property pointed by dblk22vball.
hope this helps you
-
QUOTE (Phillip Brooks @ Jan 27 2009, 01:10 PM)
LabVIEW 8.x does not support the Front Panel Window:Origin property in the VI class. If you use thisproperty in LabVIEW 8.x, the property applies only to the upper-leftmost pane. Use the Origin propertyin the Pane class instead.
Thanks for bringing that to my attention
-
Hi again,
I use this VI in my <labview>\wizard folder to reset FP Origin.
Hope this helps.
-
QUOTE (Matthew Zaleski @ Jan 26 2009, 10:40 PM)
I've done several searches and didn't find an answer (probably because I don't know the right words in LabVIEW parlance). And this problem seems so basic, someone has to have answered it before.I have a main GUI front panel that has a section that is relevant for the user at run time plus a number of off-screen indicators used while debugging the code. The problem I'm having is that during development, the front panel gets scrolled at time to the debugging indicators. What I want is that during my initialization code (if I detect App.Kind to be Run Time System) to "rescroll" the front panel to what the user expects, not my debugging indicators.
In my searches, I've seen stuff about FP.Origin (deprecated in 8.x). I think that is what I was looking for. Any pointers to relevant examples or docs to solve my problem?
Hi,
I'm not really sure in which version FP.Origin "disappeared", I think LV 8.. but if you open in LV 8+ a VI who had this property it will work. So you need to find an "old VI" that was using it ; I use it so I know it still works in LV 8.6 but you can't even fin it if you activate scripting.
Tomorrow I can post a VI with it from work if nobody does it before
-
QUOTE (jfazekas @ Jan 26 2009, 07:43 PM)
I'm in a bit of a pickle and would like to ask for suggestions. My application requires working on a large set of data that is represented in a single array of u8 integers. The array is about 12 megabytes and is fixed in length.Once the data set is aquired I have a library of 8 functions that do all sorts of analysis and anomoly checking on the data.
I've studied the GigaLabVIEW examples and see a huge benefit to passing a reference between my subVI's instead of passing the 12-meg wire around my application. This eliminates the inevitable data copies (of a large wire) and I do see a benefit to the application's memory footprint.
My problem is that this is slow. Some of my data analysis functions are iterative and I want them to run 500,000 times. There is a big hit to speed when you have to access the data many times via reference.
To demonstrate the obvious (to myself) I made the quick example below and see a 200x difference in execution speeds. It looks to me like I have a choice to either suffer multiple data copies using the byval approach or suffer speed using byref approach.
Maybe LV9 will have native byref functionality (wish wish).
Hi,
Your signature says you have LV 8.5 but your VI is saved in LV 8.6.. can you save back and repost in LV 8.5 please ?
-
QUOTE (JoergLee @ Jan 26 2009, 09:18 AM)
Hello,does somebody know how I can change the VI History programmatically?
I like to write a message in all my VIs in a project programmatically with a seperate VI.
Sometimes I like to change older History too.
Is there a oportunity with some hidden settings or how does LabVIEW manage this?
Ciao Joerg
Hi,
You probably saw that there is a property called "History Text" but it is read-only..
You also have a method to "Clear History".
I don't think you can programmatically edit the revision history.. Sorry
-
I saw that too but only on LV 8.20 and a restart of LV fixed it. Never seen it in 8.5 neither 8.6..
-
QUOTE (Eugen Graf @ Jan 22 2009, 11:24 PM)
Sorry, if I'm wrong, but I think that scripting is not necessary for LabVIEW (I, personnaly don't use it). You can generate and control code automatically, but can't use that in executables. Which advantages does it have?Do you have some VIs for automaticaly generating? Really? Or You want only to improve LV IDE?
If - like Ton said - you make the difference between scripting and private methods then yes.
But private methods come with scripting and can be helpful in your applications
-
Thanks alot Stephen for all this informations ! :worship:
Maybe this should be wikied, no ?
adjust time and date
in LabVIEW General
Posted
Hello,
In WinXP, that should do the job :
The "System Exec" primitive is in "Connectivity >> Libraries and executables" Palette.
Hope this helps