Jeffrey Habets

QUOTE (crelf @ Sep 1 2008, 05:56 PM) Amen to everything created by mister Mark Knopfler! I must say I normally just code with the radio on.. But if it's not the radio it's MK/DS or the Eagles.

Sigh... I wish I didn't use OOP as long as I do... Now I don't have a valid excuse to go.. :thumbdown: Who's teaching?

Well, I think it should be doable.. I've done it within the same project (I think it was in LV8, where there was no duplicate option yet). You should make sure that that you copy the complete item <Item Name="YourBuildName" Type="EXE"> including the closing tag within the <Item Name="Build Specifications" Type="Build"> tag. Then inspect (and if necessary edit) all property tags of your buildspec to see if they relate to stuff that is actually in your project. I've done the same with DAQ-Tasks in recent projects and it is really important that everything that is refered to is actually present in the project. It's also important that you don't introduce duplicate names/paths etc. by copying tags.

It's actually a problem of the Export Waveforms To Spreadsheet File itself (I looked at the 1D polymorphic instance of it, haven't checked the others). With every call, it writes one row of (empty) data to many.. I think the problem is the Incr function (see attached picture), although I haven't checked if it would break other functionality of the VI if it would be removed. Question to NI would be, is this expected behaviour or is it a bug. I would think the latter.

QUOTE (Ton @ Jul 26 2008, 11:28 AM) Amen to that.. QUOTE (Ton @ Jul 26 2008, 11:28 AM) It should be easy (right-click easy) to name a pane and splitter Imho this is already possible. Right clicking the splitter gets you to the visibility property of the label for the splitter as well as the adjoining panes. From this menu you can also open a properties dialog for the panes and change the label there, which is easier if the label is obstructed by controls on your pane. The splitter itself though doesn't seem to have a properties dialog. I wonder why, since all other controls have one.

QUOTE (LV_FPGA_SE @ Jul 26 2008, 12:54 AM) In OO terminology they would classify as a singleton design pattern. Because that's basically what they are: a class of which only one object can be instantiated. An advantage of this particular singleton implementation is that we don't have to pass a class reference around. Disadvantage ofcourse is that reads are always serialized and we have to wire and set the method selector everywhere we call a 'method' of the class.

If you have "Allow drag" for the cursor set to off you can't drag the label either. So that wouldn't be an option. You can set the label offset to the cursor position in the "Cursor list" property. Mind you that if you have a scale multiplier set other than 1 to one of the scales the cursor is connected to. The cursor label will "drift away further" from the cursor position each time you change the position. This is a bug in LV.

I noticed there are some 15,4" notebooks on the market today with resolutions up to 1920x1200.. Does someone have experience with coding on these? It seems to me you would need a magnifying glass to distinguish the various functions and VI's on your BD.

I use a 14.1" laptop with 1280x800 resolution (Dell Inspiron). I choose this because it's very portable, and I can work up to 4-5 hours on one battery charge. The only down-side for me until now is the vertical resolution. Not for the BD's, cause I keep these always quite smallish, but for the FP's. Most customers use screens with resolutions of at least 1280x1024, and sometimes an application simply needs to use all available screen real estate. Well, I can tell you its pretty difficult to get to the bottom of a 1024 pixel high FP with the scrollbars turned off on a screen that has only 800 pixels vertical resolution. :thumbdown: My next laptop will probably be the smallest one available with at least 1050 pixels vertical resolution. Although the system at home/work (a desktop system with 24" 1900x1200 resolution) is a way more relaxed work environment I don't want a laptop with that same resolution, so I just try and keep all BD's within my laptop's resolution.

QUOTE (horatius @ May 15 2008, 07:51 AM) It is: QUOTE (LabVIEW help) Globally Initializing the Feedback Node If you do not move the initializer terminal to the left edge of a loop, the Feedback Node globally initializes. You can use a Feedback Node that globally initializes anywhere on the block diagram. If a Feedback Node globally initializes and you set an initial value, the Feedback Node initializes to that value on the first call of the VI in an execution. If you do not wire an input value to the initializer terminal, the initial input of the Feedback Node for the first execution is the default value for the data type. Each time the VI runs after the first execution, the initial value is the last value from the previous execution. The following block diagrams show the differences in value from execution to execution for a Feedback Node with a wired initializer terminal and a Feedback Node with an unwired initializer terminal.

QUOTE (horatius @ May 7 2008, 08:37 AM) You probably have the initialize terminal of the feedback node within the loop, this is a global init and will happen only once.. Something like this: To initialize with every call off the sub-vi, place the initializer on the border of the loop. Like this:

QUOTE (psiam @ Apr 28 2008, 10:03 AM) I think there is a commandline executable that's part of MPLAB (PM3.exe) that you could call via system exec with the right parameters to program your device. You should find more information in your MPLAB documentation or on the Microchip site.

Although this project only uses the standard NXT SW, I thought it might be a nice pointer for al you guys into Mindstorms NXT. http://staff.science.uva.nl/~hcramer/phobot/index.html

QUOTE(aart-jan @ Dec 29 2007, 01:15 AM) Strange, I don't have this issue in my code.. Do you have some example code which replicates this?

QUOTE(aart-jan @ Dec 28 2007, 06:11 PM) Assuming you are using the EndevoGOOP3 class provider... The class name output shouldn't be empty, it should contain the classname (without the .lvclass).. Now, if you by any chance meant the "object name" output, this will be empty by default. The object name for a particular instance of your class can be set as a parameter to the new method in the create method of your class.. http://lavag.org/old_files/monthly_12_2007/post-906-1198880165.png' target="_blank">

Nobody noticed this yet? : When you need relative time as display format for a dbl, in 8.5 you need to select Absolute time. It seems the Absolute and Relative time options are swapped.

QUOTE(tcplomp @ Nov 19 2007, 03:50 PM) This is actually quite standard for NI.. Where the whole world converts $1.50 to approx. €1.00, NI converts $1,05 to approx. €1.00.. It is really ridiculous when you think of it..

QUOTE(Yen @ Nov 8 2007, 05:41 PM) Yes of course.. But for simple (lv2-style) sub-vi's where you know not much will change later on, it's still convenient to just use a shift reg or two-three.. I'll enter it in the product suggestion center...

Hi guys, I have the habit of always labeling my shiftregs on the left hand side of the loop they're on. I use free labels for that, but it would be nice if the labels where (optionaly) automatically created (like with objects on the FP). They would be attached to the shiftreg, moving with it when the shiftreg is moved up or down. besides being a handy feature for myself, it would probably also encourage others who don't label their shiftregs now to do it anyway, because it would be the next logical (more or less forced) step after creating the register. What do you guys think?

Yess!! I passed my CLA re-certification this time.. :thumbup: So I'm Ok for two years again.. :-) I did the recert also at NIWeek this year, but I guess it went wrong because of the :beer: :beer: at the Oasis the night before taking the test.

QUOTE(tcplomp @ Oct 18 2007, 12:53 PM) Congratulations Ton! :beer: And to your colleagues too of course if they passed as well...

QUOTE(tcplomp @ Sep 19 2007, 02:19 PM) I don't understand why you would need two event cases.. In this particular case we are only interested in checkboxes, and I expect these to be in switch mode, not latch.. For latch mode your event code would be of no use anyway since reading/writing of the boolean value property is not possible. So, just wire the array of strict bool-refs to the RegEvents node and you can handle all switch booleans in one event case.

QUOTE(tcplomp @ Sep 19 2007, 10:16 AM) I guess making the Value a variant is NI's way of saying: watch it, there's something special going on here.. You're actually not allowed to use the Value* properties for reading or writing a boolean that is in latch mode. If you try it, you'll get an error.. QUOTE(tcplomp @ Sep 19 2007, 10:16 AM) I propose two have two boolean reference types: Switch Latch Ton Yes, that would be nice.. But as it is now, there's only one boolean object with an attribute that lets it behave in different modes (instead of using inheritance hierarchy of various boolean controls), thus only one reference.. As a workaround to get strict types you could cast to a reference linked to one of the checkboxes like this: You could also filter the array of controls by looking at the Mechanical Action (private) property to makes sure you only get refs to the right controls.

Why go through all the hassle.. Just use the spacebar when your checkbox has focus.. Besides the fact that you don't have to program it, it is more common user interface behaviour to use the spacebar for that. QUOTE(tcplomp @ Sep 19 2007, 08:01 AM) I guess it's because your boolean references are not strictly typed.. LabVIEW has no way of knowing whether the booleans you register dynamically have a mechanical action of switch or latch.

QUOTE(dsaunders @ Sep 12 2007, 11:52 PM) This is a classical problem.. It happens when you try to cast a number to an enum where their representations are not the same. E.g. trying to cast the output of 'Search 1D array' function (i32) to an enum (default u16) will always give you some unpredictable results (well, they are predictable I guess, but you'll have to do some bit-twiddling then..) unless you first convert the i32 to a u16.