Gabi1
-
Posts
95 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Gabi1
-
-
Should i re import picture and rewrite info?
-
Thank you for bringing it back!
i missed it
-
QUOTE (Tim_S @ May 17 2009, 04:49 AM)
QUOTE (BobHamburger @ May 18 2009, 02:27 AM)
I'd go one step further: set up a machine with separate boot partitions for each version ofLVthat you want to install and support. It's a royal pain to approach it this way, as it requires you to re-install all of the toolkits as you mentioned, but from my perspective it's the only sure-fire way to keep the various versions completely clean and self-consistent. When you install newer versions, there's an annoying tendency for the newer drivers, DAQ stuff, etc., to overwrite what's already in place. Our friends at NI naturally assume that all you're ever interested in is upgrading to the latest and greatest.it doesnt solve the original issue of the drivers, but : Yes, with all the pain involved with different LV versions this might be the only solution. maybe we can ask NI that future versions keep encapsulation into a single folder. also, we need a 'check and update' button: whenever a new version is installed, check for older version for drivers, toolkits...
-
QUOTE (Mark Yedinak @ May 16 2009, 04:35 PM)
I would look at two things that will help with your multiversion environments. First, if you are not using LabVIEW projects already then I would start using them. They help significantly to reduce cross linking issues and generally keep things more organized. Along the same lines I would look into using some sort of source code control. This way you can save code their and branch you applications and keeping working version for each of the different versions you are using.Now, do you need to distribute source or can you simply distribute stand-alone applications. If the latter then you don't need to be so concerned about the different versions of LabVIEW. However if you do need to distribute different versions you will need to use the approaches I suggested above. In addition, you will need to have each version installed on your development machine. You can save code to an earlier version but that is only supported for two revisions back. So, over time this does not become a workable solution. The only true way to support multiple versions is to have each version installed. If you need to do this I suggest that you look into the SSP program.
the project explorer doesnt help for toolkit vis, drivers, or DAQmx. it is simply not part of the explorer. one workaround is to always save a copy of the vis in the project directory. didnt do that up to now.
another problem i have is : why should i reinstall all the toolkits for every future installation of LV, if:
1- i didnt buy the new version of the toolkit, or the toolkit didnt change
2- the application saved in a previous version with drivers, where the drivers are installed on the LV folder. open the application in a new LV version, you lost the reference to these drivers. Do I need to reinstall all the drivers?
3- DAQmx hasnt changed - why should i reinstall it?
it is clear that to keep compatibility we need to keep versions of these toolkits on the original LV version. But there must be a simple option to compare / export all vis to the next version.
if its not yet existing...we need to take the challenge!
-
There must be an easy solution for this, or NI is not doing it right:
at one client i have LV8, at another LV 8.2 (computer 1) and LV8.5 (computer 2), the beta version and LV8.5 on my computer. that is becoming too messy with the different applications.
example 1:
i have all the toolkits, drivers and DAQmx installed in 8.5. as i test the LV 2009, i did not install the toolkits. now i open an application that requires DAQmx, and i need to tell LV where to find it. i am afraid to do so, as it will be saved along with the application in LV9. there should be a command to import all toolkits and drivers from previous versions.
example 2:
on one computer i have some instrument drivers installed (LV8). if i save the whole hierarchy for using in another computer, short of saving the whole user.lib and vi.lib, i have no way to export the actual drivers. my workaround right now is save to previous version, but it should not be.
so in short: how to make applications and project compatible on different versions/computers, without having to fiddle with it for 2h each time?
-
QUOTE (Don Kirkby @ May 5 2009, 07:50 PM)
By the way, the certification process was really helpful, and didn't cost anything. I highly recommend getting certified for anyone publishing an instrument driver.Both as a developer and a big user of LV drivers from a lot of instruments, I cannot agree more!
those amateur engineers who thinks their instrument communication protocol is so unique it should be hidden under piles of password protected LV files that are buggy, badly written and lack features, should be shot on spot!
-
arg !
this is damned too addictive! 14th level and going...
-
QUOTE (Aristos Queue @ May 2 2009, 08:02 PM)
Step 1. Use Edit >> Select All on the front panel to select all the controls/indicators/free labels/etc.Step 2. There's a ring on the front panel just to the right of the Run Arrow that is the font ring. Click it and select a larger font size. All the selected objects will get larger.
ALTERNATIVE:
Drop all your controls/indicators from the System palette. The controls in that palette are tied to the operating system settings. I assume that the default font on a touch screen is fairly large, so when you load those VIs on a touch screen, the text will be larger. Note that system controls also change color based on your OS settings.
it wont work for menu items. the Windows control solution is your only way out.
-
QUOTE (Aristos Queue @ Apr 27 2009, 10:19 PM)
When events fire, they are placed in a queue. They record a timestamp of the time they occurred. The timestamp has millisecond resolution.There are separate event queues for dynamically registered events and statically registered events. In Yair's demo, the user event is registered dynamically and the value change is registered statically, so there are two queues. The event handler looks at each of its queues and takes the earliest timestamp. In this case, the timestamps are identical and the statically registered event wins.
So effectively this is a race condition between events.
Why are static vs dynamic handled in different queues? just curiosity.
-
the FX6300G was actually already a pretty advanced calculating machine. i can guess your young age from it!
It was also pretty sleek for its time. I got myself a Sharp, EL9300 with added memory and an equation solver. still use it sometimes, and have some cool programs still in there...
-
-
QUOTE (ShaunR @ Apr 20 2009, 11:23 PM)
And what is this obsession with queues on this site?i'm in love with queues...cant get enough of them!
i have now transformed my design template with queues all around. have only two loops on the main diagram, Event and data display. all the rest is passed trough subs using queue. very satisfied!
But still cant get around the LVOOP: to me, nothings yet beats a good old cluster with LV2 types constructors/destructors (or directly references). maybe because i'm still on 8.2 tough.
-
QUOTE (crelf @ Nov 9 2008, 05:35 PM)
True, but often P is all you need.
This is quite dependant on the system. i found that for most, actually I is all you need. P is for first estimation and D serve as first order correction.
I never used the PID toolkit, and always developed mines alone. here is an overall simple approach you could try:
X= value wanted
X1= value wanted - actual value
X2= previous X1
correction parameter = AX+BX1 +C(X1-X2)
A,B and C are the weight you are going to put on each of the element, in order to reach target value.
I propose you activate them in steps, by first approaching solution with A, then correct for constant offset with B. you might have to tune down A quite a bit doing so. finally, minimise fluctuations with C. You will want to keep C at a minimum level.
implementing in LV is elementary.
enjoy!
-
i am always prone to inventing new words (worlds..), but this one "sourcenders" really sounds like a politically correct word for a bastard dependancy VI...sorry for the language
i am for the word: 'Little Urswick' *
original description: the member of any class whomost inclinesthe teacher toward the view that capital punishment should be introduced in schools.
It fits here, no?
*original source (apart the city...): the deeper meaning of Liff
-
Yea well, all i know is that i need my dose of 50Hz radiation every evening, to go to bed...
How old was she here?
BTW i was at one of her concert in July in the Arena of Verona - she had there a software tool to make sounds that was amazing, and would look great on LV. Trying to depict it i quite complicated, but i'll give try:
This is a touchscreen thing. with the touch of a finger one create a circle, whose size will give the pitch of a specific beat or note.
Then, one can connect the circles with wires, that will then derive dependancy (sourcenders?) sounds, with frequency derived from the distance between the circles. the circles can be created, moved, and change in size. the connecting wires as well.
Made some amazing sounds. They showed the engineer designing sound on special screens.
-
QUOTE (Ton @ Oct 18 2008, 10:31 PM)
Depends on your needs.If you are interested in trigger signal in the form of a short pulse than the pulse width is important.
If you want to read during long times DIOs the onboard memory is important.
However 64 MB onboard memory is a lot.
Consider 10 kHz, 32 channel, this means 320 kB per second, resulting in 2000 seconds of memory.
the onboard memory is usefull only at high rate of transfer, well above 1Mb/s. below that, for any decent computer, the operating system can store the data directly on the main board memory for unlimited time (depending on operating mode, you can set new data to overwrite old data). that is why 6533 would be sufficient for you (no onboard memory).
But if we dont get more input on your application it is difficult to give effective advice. if you only want triggering and DIO on the KHz regime, there are much cheaper cards and more versatile either. the NI USB 6009 might even be sufficient for you, inlcuding several DIO and some analog ports. i recall this is on the range of merely 100$. a bargain for what it propose. the 6534 i think it is not sold anymore by NI, and they have newer version, but it cost ten fold more!
-
QUOTE (Louis Manfredi @ Oct 17 2008, 08:48 PM)
Just my perspective, and in any case, Neville's point is still valid-- even if the support isn't seamless, the good folks at NI support will do their best to get you across the seams. If you buy hardware from someone else, they may lack the moral obligation, motivation, and probably even the knowledge to help you out.first, the 6534 is a DIO card. no analog there. output rate is up to 2Mb/s, in burst or handshake mode.
the cards work similarly with DaQ and DAQmx, but the DAQmx definitely offers more control and readout options, for example for the buffer state.
the correlation of the card with NI would make sense, but i have to warn you the technical knowledge of the support engineers is basic at most, as they dont do high speed DIO... so advanced bugs or issues you encounter will not be solved. Specifically, some bug with Labview doesnt allow the card to operate at 2MHz even in Burst mode. depending on computer power i found 1MHz to relatively deliver stably, but not above.
one note: go to the 6533. much cheaper, also can be found on Ebay. no buffer on the card, but for today computers i have not found performance differences in both input and output.
note 2: NI have now developped new version of those cards, that are more reliable, and perform better in terms of configuration and programation with LV, allwoing to use only the high level functions delivered by LV. if not too expensive for you, i would go on those. they also feature higher data rate, in the range 5Mb/s and above (but then you will probably need onboard memory).
-
if you use instruments with low sampling rate, then this jumpy behavior will not be observed.
even if you are at worse gain condition, on the Tc you should get an accuracy above 0.5deg. if the gain is the problem, you will see a digitation of the possibles temperatures values, and not random behavior as you describe.
my explaination to your problem is grounding issues. it is known that Tc support badly grounding on one of its wire, and this will lead to strong noise at relatively high frequency. to check this, it suffice to sample at 100KHzfor example, and average out the results down to the KHz regime. if the reading becomes more stable, you have defined the problem as well as the solution. but i would go to track the grounding issue, as it will bug you forever. one thing you can try is force ground at reception (on the card), by short circuiting the negative pin. This is not the best solution, rather if your Tc is somewhere grounded, then this will stabilise output. a better solution is to purchase from omega a Tc amplifier, based on batteries (floating). then ground noise become negligible.
-
got 2.47
i guess with a normal mouse (i'm with laptop trackball) and higher screen resolution, one could do better.
very cool game
-
QUOTE (gleichman @ Sep 28 2008, 04:09 AM)
is there an inherent reason for LV not implementing child windows? i see lots of applications for my projects, and always had to do without.
Would be a tremendous feature.
-
i have same very warm recommendation for the style book from Blume.
really great! didnt regret a dime.
-
thats so sad, i cant convince my bosses for LV 8.6...
i would work for any company that would provide it for me
(in Munich)in the mean time, can you expand on the beta?
-
-
thanks guys for your input. as gar as licence goes, i have the module here with mine. dont intend to distribute.
QUOTE (Yair @ Aug 26 2008, 06:31 PM)
All in all, I would go with the others' suggestion of using a real remote or proper software.i guess so. would be stupid to reinvent the weel, even with LV. yet i will try to talk to the IR port via NI-daq, see if i can get something usefull.
personal info is lost
in Site Feedback & Support
Posted
ok.
its great LAVA is back