-
Posts
168 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Downloads
Gallery
Everything posted by Dirk J.
-
Added that this is an NI card to original post.
-
Dear all, I've inherited a machine with an NI PCIe-5410s card which functions on LV12. I'm looking for documentation for this card, in part to see decide if an upgrade in LV version is wise. Strangely, I can't find any documentation, so I guess the card is deprecated.... If anyone could help out, I'd be grateful. /dirk
-
has the 'edit post' feature a minimal time on the new forums or has it always been like this? Karl, others will probably respond to your points in detail. Thank you for illustrating that standpoints in this debate are highly political and not scientific. Again, that is not a problem, just be open about it.
-
I did, and that's why I asked the question. Unfortunately, you don't seem to want to answer it here. You started the topic, granted, question remains: what is your problem? See below before you hit reply. Does asking questions make things political? If it is Science that concerns you, how about the organic transistor of Schon from Bell Labs; or the South Korean cloning thing: did that excite you that much? Sidenote: how exactly does science go beyond politics? Who's funding science? May not like it, but it's the way it is. OK, bite to this then. I hypothesize that, based on you "0bama and the watermelons" statement, this issue is in fact political for you. This is not an issue because you have every right to feel that way. For discussion sake, though, of this is the case, please stop playing the science card. If not, please stop posting politically motivated links and statements. 40k years back without an uncertainty estimate? Sure, graphs are easy to understand, remember the hockey stick? Maybe laughable is not the right word. How about unscientific. Just like all the other data that was presented as conclusive. Why do you feel your arguments are better? The issue is complicated, the data often ambiguous. There is a world wide community of climate/environmental scientists working on this. Why do you distrust all of these people? is that another seniority issue?
-
ok, so what is your point exactly? is it that you don't believe in climate change? the PICTURES OK? that you posted seem to show that there is continuous change. stop yelling please, btw. is it that you don't like the consequences that this climate change may have to your lifestyle? that's political, so don't complain about a couple of scientists gone bad. they're bad people, we all agree; doesn't necessarily mean the science is bad. is it that you don't share the political views of the people stressing this climate change, global warming? nobody likes being lied to (whether or not this is happening here). wake up, happens all the time. if you want to keep this discussion 'clean', you should also make clear why this is such a big issue for you. if it is a political thing it would be best if we stopped this discussion pretending we're scientists, because the "data" I've seen sofar in this discussion (pro or con) is laughable at best. what's even worse: it doesn't take a scientist to draw these graphs. it doesn't mean anything, pro or con without proper source and justification.
-
Well, all you US folk seem to forget that it is also St Maarten. I'm going to wire up a latern and get myself some candy.
-
since replying to this topic seems to be the only way of addressing these issues at times.... YES, I really, really, really, appreciate the time and effort the moderators put into this forum. I learned a lot, and I hope I helped some people too, in the course of time. No, I don't understand why something that was not broken (LAVA 1.0, or was it broken?) was "fixed" in LAVA 2.0. I remember a lot of topics, code snips, etc that used to be there (LAVA 1.0), which have been very useful to me, but which are just not so easy to find anymore because of alfa-bloody-fifth-dimension-rss, broken links, not showing up in general search, etc.... flame me, if you like for being disrespectful, but i.m.o. without that part of it's discoverable history, this forum is a little less valuable than it used to be. /dirk
-
headache coming up... so if I understand right, if I would load an image-saved-as-pixels from file, put it in an intensity graph control and have some property nodes on the diagram to set the labels of the axes..... I get /4/ data copies?? If so, is switching to a picture control beneficial? /d
-
Ano, I don't have 8.2 installed anymore (and if you have any chance to upgrade to 9.0 you should so I haven't been able to test it. But here you go. No wrapper DLL's involved. BrowseForFolderG.vi
-
try this /dirk BrowseForFolderG.vi
-
Not in LabVIEW. I think LV's shallow learning curve prevents 'beginners' to think about design patterns. An extreme LV duct tape programmer is someone using a lot of local and global variables, 10+ frame stacked sequences, discards a main-program-while-loop as too complicated because there is a 'run continuously' button; uses only Express VI's (the baby-blue color spells: beginner ) and thinks the combination of a state machine with an event structure is overdoing it, because why would you respond to a Stop-ValueChange with Stop-case in the next iteration of the allready redundant MainProgramWhileLoop ........? The result is the code that we all see from time to time, loaded with globals and locals, cases polling a single boolean, etc etc. It doesn't help that LV still ships with examples that use a polling architecture. It's sure important that Average Joe can wire something up in 10 minutes, but if he has been wiring for two weeks that way, he starts to complain that LV is much slower and sluggish then say C++ or whatever language he's heard of from his non-duct-tape colleages. I know it doesn't compare exactly to Joel's COM-multiple-inheritence-multi-threading rant, but still. Duct tape programming in LV is disadvantagous in the long run. /dirk
-
constant value changes on changing representation
Dirk J. replied to Dirk J.'s topic in Database and File IO
Rolf: fair enough. LV handles so many things for you..... I actually only noticed this when I changed a Complex Double (which wasn't supposed to be complex) to a Single in an example VI which I wanted to send to the students in our group. My major concern was with their potential surprise of seeing number different of the number they entered. Anyhow, it all makes sense after all. Maybe I'm just not having a good day today. /d -
constant value changes on changing representation
Dirk J. replied to Dirk J.'s topic in Database and File IO
[Edit: just a couple of minutes too late....] I understand that not all numbers can be represented exactly, but the key to my puzzle is in the default display precision of SGL and DBL. If you configure a constant as a SGL with value 1.3 it defaults to 6 digits of precision. You can change the representation of the SGL back and forth to DBL, but it maintains it's 6 digits (always displaying 1.3) If you configure the constant as a DBL with value 1.3 it defaults to 13 digits of precision (initially showing 1.3) Changing the representation to SGL maintains 13 digits of display precision (not internal precision), thus showing 1.2999..... I somehow expected it to change to 6 digits display precision (it shows 1.3 then). /d -
constant value changes on changing representation
Dirk J. replied to Dirk J.'s topic in Database and File IO
ok, I understand that it has to do with the # digits. but still this puzzles me: If I place a constant, change it's representation to SGL and enter 1.3, the constant on the BD reads 1.3 If I then enter any other value, it simply displays what I entered (as I would expect). If I place a constant, change it's representation to DBL and enter 1.3, the constant reads 1.3. If I change the representation to SGL, it shows 1.29..... If I enter any other value, it sometimes displays what I entered, sometimes not. Yet both constants have SGL representation. /d -
can anyone confirm (and explain) this behaviour: 1) place a numeric constant on an empty block diagram (defaults to 0, I32) 2) enter fractional number 1.3. representation changes to DBL 3) change representation to SGL In my case, the constant changes to 1.299999952316 (I noticed that this doesn't happen for all entered values.... 1.5 works fine) /dirk
-
Mikeal, I installed v3.2 today for lv 8.6.1 today under LV2009. It gave no errors during re-compiling, but keeps prompting me for saves of goop3 vi's when I try to close project using GOOP classes. Could you please post versions of _goop3.llb compiled in LV2009? Thanks, Dirk.
-
Yup. I've been reading this thread with interest from my RSS reader. Up until just now. I, well, used to get threads from: http://lavag.org/ind...ype=forums&id=1 All ****ing Alfa String now.
-
Here are the files. NI_Report.zip
-
There is another workaround hack, without modifying VI lib to get the reference. 1) create a child class of NI_Standard Report.lvclass (or whichever one you're interested in). Create a NIReports.Report ActiveX reference in the private data 2) override the 'new report subVI.vi' 3) in this overide VI, first call the parent method. Flatten the class to an XML string. Using pattern matching, find the (hex) string value of the reference). Typecast into the activeX reference. Both parent and child class now operate on the same reference. See the attached image of 'new report subVI.vi. /dirk
-
Using GPUs with LabVIEW for application development
Dirk J. replied to sumitg's topic in LabVIEW General
That's the way it is for now, I guess. There are a couple of interesting CUDA libraries around (such as CUFTT, which implements Fourier transforms on the GPU) that could be ported to LabVIEW just the way as CUBLAS. That would have immediate benefit. I've been toying around with it for the last couple of days, but with my somewhat limited knowledge of DLL incorporation, it has given me a lot of crashes so far .... /dirk -
front panel customation of a xcontrol
Dirk J. replied to Dirk J.'s topic in Object-Oriented Programming
Mark: I hoped that using Xcontrols would mean less coding. I agree that the 'simple dropping' of an Xcontrol is certainly an asset. My intention was to create a control (or subpanel-based, lvoop handler) that accepts an (Xarray,Yarray, Error_array) cluster as data. I'm very willing to write code for the functionality - I'm doing that in my subpanel implementation. I kind of expected that the user interface part would be handled similarly to conventional LV controls (in the IDE, not programatically). Note that the subpanel approach also allows event-structure based implementations, so I don't see any differences there. I know that the customizations I listed can be implemented relatively easy in code; but for 'normal controls' they don't require code at all. QUOTE (neBulus) That's another issue, indeed. Maybe I was wrong to assume that an Xcontrol was a "user interface" benefit. Maybe an Xcontrol is just a 1/3 lvclass; it has encapsulation, but no inheritance and polymorphism. -
Reasonably late, I have the ability to play with Xcontrols per our latest LV8.6 upgrade. I figured I'd start with an XYgraph that displays error bars. First step was dropping an XYgraph control on the Facade VI, and nothing else. If I place this Xcontrol on a front panel, it appears that I can change some stuff (such as the bizarre grid colors if the native XYcontrol), and the axis labels; and can't change other stuff such as the XY graph label. I can change the line style/color/etc of a graph if the plot legend is visible, but I can neither resize the plot legend, nor show or hide it altogether from the front panel in the 'usual way'. Not that it actually matters, because when I save everything, close, and open it all again, all xcontrols are defaulted to the Facade VI. So am I right to conclude that Xcontrols are a kind of "type def control"? Only the definition can be changed, not the individal controls? I realize that they can be changed programatically, but that requires a lot of coding. Or to put in in another way: I used to implement my "xcontrols" by means of subpanels. What is the actual benifit of having XY controls as user interface elements, over that approach if you can't customize the individial controls just as you would customize a native control? /dirk
-
Topic about LabVIEW just started on slashdot.org
Dirk J. replied to Aristos Queue's topic in LAVA Lounge
QUOTE what's certainly not helping in my opinion is the enormous complexity of turning a moderately complicated LV project into executable code. (thinking of the LVOOP <--> app builder issues) -
I wish LV can display translucent PNG or GIF image
Dirk J. replied to Cool-LV's topic in User Interface
I think you can also use the PictureBox .Net control. It blends automatically with the background.