silmaril

QUOTE(Tomi Maila @ Nov 20 2007, 12:46 PM)

When wiring error into a loop, the most common use case is to have a shift register to pass the error from iteration to iteration. Hence shift registers should be the default terminal type for error clusters when wired to a loop.

EDIT: The same should apply for all reference types.

I agree absolutely.

Did you already suggest this on NI's site?

QUOTE(djp_eng @ Nov 17 2007, 02:44 AM)

Have seen several references to a "Demo Read Voltage.vi"...

IIRC this VI comes with the LabVIEW Basics I course examples and is to be used if you don't have DAQ hardware.

It doesn't do much more than generating a random value.

If you only need it as a sub-VI to open some example, it might be easy to replace it by a simple VI of your own.

Did you try Ctrl-Shift-Run on your top level VI?

Was the run arrow still unbroken after this?

QUOTE(Aristos Queue @ Nov 4 2007, 10:03 PM)

According to the IEEE standard for floating point calculations (which LV follows), if I have a value A that is NaN and I compare it to a value B that is NaN, then I should get FALSE for tests of both equality and inequality. In other words, A!=B and A==B are both false. That's how you detect NaN.

If A!=B and A==B are both false for NaN values, how do you explain this behaviour of LabVIEW 8.5?

http://lavag.org/old_files/monthly_11_2007/post-7932-1194603753.png' target="_blank">

QUOTE(beckerg @ Oct 28 2007, 10:25 AM)

As a daily reader of the various topics, I discuss many of it with a colleague.

QUOTE(crelf @ Oct 28 2007, 03:53 PM)

OK, looks like a good time for me to come out of the dark, too. :ninja:

I am the college, beckerg refers to

Don't worry - I already try to add my share to this great forum. The only problem is what you so fittingly describe as "little time"...

It's often difficult to get the return data from a DLL that allocates it's own memory. LabVIEW is much easier to use, as long as it can do the memory allocation.

There is a very usefull function inside Windows kernel32.dll:

void RtlMoveMemory(void *dest, int32_t Source, int32_t length);

You could use this to copy the data from the returned address into an array you allocated in your LV app.

It works fine for me with my own cluster connected to the *dest input using "Adapt to Type" and "Handles by Value".

It should do the same if you have an array instead.

If you have access to the DLL source code, I would recommend following Tomi's advice and change the way you return the data.

I find it easiest if the DLL gets a pointer to the memory that is already allocated by LV.

QUOTE(Hacti @ Oct 25 2007, 08:21 AM)

I'm having some problems with my .exe because some property and invoke method nodes are not supported by LV realtime and dsc run-time. Is there any way to include these nodes in my application?

It seems to me you are mixing the terms here: Run-time, Realtime, DSC.

So I am not quite shure what you are really doing.

Every property or method has it's table in the online help which states things like "Available in Run-Time Engine and Real-Time Operating System", "Settable when the VI is running" and others. If a property is not available in the Run-time environment, there is usually a good reason (which means, it doesn't make sense to use it outside the development environment).

This means there is no way to use those properties/methods in an EXE or on an RT target.

If you really think you need one of those on your target, let us know what you want to achieve. Maybe we can find a workaround together.

QUOTE(jlokanis @ Oct 24 2007, 07:57 PM)

Unfortunatly, the coloring of the cells is an integral part of my display, so eliminating that is not an option. I will try your idea about only changing the color in the for loop and moving the symbol and test changes to the Add function call. If only I could specify the color of each cell in the add function...

In a table you can use "-2" as the "line" coordinate to color a whole column in one step, which works pretty fast.

I didn't find an equivalent for this in the tree control properties.

Is this really missing, or was it just me who missed it?

The fastest way I found to make large changes to a tree control is still hiding the tree until I'm finished.

This doesn't look very nice, but it works.

QUOTE(mballa @ Oct 25 2007, 08:32 AM)

Thankyou for the feedback and trying out the tool. I hope it saves you some time.

I'm shure it will!

QUOTE(mballa @ Oct 25 2007, 08:32 AM)

:headbang: Oh yeah! I like this kind of problems

QUOTE(mballa @ Oct 25 2007, 08:32 AM)

Yes, this one works nicely, but I'm sorry to say that I found two more little things that should be fixed.

In _FIXER Subvis Main.vi there should be a "This VI" reference at the beginning. Without this, I always get error 1026.

http://lavag.org/old_files/monthly_10_2007/post-7932-1193296538.png' target="_blank">

The OpenG SubVI was designed very carefully. If you don't wire a reference to it's input, it opens it's own reference and makes shure it is closed again at the end of the VI.

Also there is still a breakpoint in the engine, that gets hit everytime I use the "Set as Required" button.

Looking at your code, one question comes to my mind: What exactly does the method "FP.Set Close If Lonely" do?

QUOTE(mballa @ Oct 24 2007, 05:50 AM)

Here is Version 3 using the VI Activation Event that PJM showed me.

This is a really nice tool!

Thank you very much for all the time you put into this! :worship:

The tool works very nice, as long as the name of the main VI starts with an underscore.

I copied it into my projects directory and removed that underscore to get a Tools menu item for this.

Now I get a funny problem: every time the tool changes the window focus to itself, it seems to detect the VI Activation event and sets "Target VI" to itself, which makes it impossible to use the tool anymore.

The straight-forward solution to this seems to work fine here:

I didn't upload the complete VI, since it's a really small change, and I suspect, you already have made much bigger changes in your own version.

QUOTE(crelf @ Oct 24 2007, 02:44 AM)

Absolutely! All you'd need to do is step down into the deepest structure, get references to all the objects, get their footprints, move them to the top left (+ some arbitrary border), resize the structure, and then step up a level and continue. You'd of course need to look at parallel structures too, but I don't think it'd be that difficult. The only thing that might take a bit more thinking is the positioning of tunnels once you've resized their structures.

I wouldn't want any automatic function to mess with VI or tunnel positions that I have chosen carefully before. :thumbdown:

So I'd prefer a function that only changes the size of structures, i.e. the bottom left corner, but doesn't move anything.

In my opinion, it shouldn't touch any parent or child structures as well. I expect this would only lead to diagramms on which you can invest hours to bring them back to a decent coding style.

QUOTE(alukindo @ Oct 21 2007, 08:10 PM)

As of LabVIEW 8.0, LabVIEW will print graphs with the plot area empty! All grid lines, controls, etc will show up OK, but the all important graph will be empty! In some cases LabVIEW prints empty pages altogether. NI application engineers acknowledge that this is a known bug but it is yet to be fixed as of LabVIEW 8.5.

It would be interesting to see an example of this behaviour.

Maybe it's an effect similar to what I saw in one project, where I printed a front panel as a report:

First call: panel with default values was printed,

Second call: panel with values from first call was printed,

and so on...

It seems that LabVIEW simply generated the image to print before updating the data in the controls.

Fortunately, all the elements were in one cluster, so the solution was easy: I wired the cluster control directly into a local variable of itself and used a sequence structure to make shure the image was generated after this.

Could this be the same thing you are experiencing?

QUOTE(Michael_Aivaliotis @ Oct 18 2007, 07:38 PM)

Sure, and probably some time after that you will see LV 9.0. Oh and probably sometime after that you will see 9.1 then 9.1.1 then 10.0 then... So?

:laugh:

It sounded more like "we try to do it this year".

8.5.1 is mainly supposed to bring bug fixes, not new features.

This sounds like a very good idea to me... Let's hope this dream really comes true

(I heard, they were talking about a version 8.0.1 after the 8.0 desaster, but it was never released, because NI considered it too expensive. :thumbdown: )

QUOTE(orko @ Jun 11 2007, 11:45 PM)

I'm especially interested in what people *expected* versus what they *experienced* when they took the CLA exam.

I took my CLA recertification exam in June this year.

The written part consisted of a lot of questions that had to be answered in your own words. Quite a few of them seemed to target topics from the course "LabVIEW Advanced I - Architectures", so it's definitely a good idea to review this manual before taking the test!

There were some questions for which you cannot give the one and only correct answer. It looks as if NI only wants to see that you are able to think for yourself

The programming part was a project that's quite a bit larger than the one from the CLD exam. One important thing to keep in mind during the whole exam: You are not supposed to deliver a working application! You are supposed to show your skill as a LV architect, which means you should define the complete architecture of the application, so that others can implement it by filling in the gaps you left.

This means you have to wire the complete state machine (or whatever you use) and create all the sub VIs, including their icons, connectors and descriptions. The descriptions have to be sufficient to tell another programmer what to implement at this point.

I found it quite difficult to really stick to the architecture without wasting a lot of time implementing details. Because of this, I didn't finish the practical part (4 hours can be such a short time! ). In the end, I really wasn't shure if I passed or failed, so I was very nervous for the next weeks.

I really wouldn't call the challenges in the CLA exam easy, but NI seems to make up for that by correcting in quite a friendly fashion, so it ended well for me :thumbup:

QUOTE(TG @ Oct 18 2007, 03:03 AM)

Wondering if there is going to be an 8.5.1 patch coming..

In the LV User Group Meeting during VIP 2007 (last week's NI congress in Germany), the NI people told us that LV 8.5.1 will be released "in a couple of months".

QUOTE(Justin Goeres @ Oct 10 2007, 03:58 PM)

But then when you open the VI later, won't the VI still think it's part of the library? My understanding is that it will, at which point LabVIEW will present you with the password dialog, because updating the VI to no longer belong to the library counts as a "modification."

Of course it will. That's exactly the point of password protection

From my point of view, this is the one and only correct behaviour.

This way you can for example put password protected VIs into a password protected library and sell it to customers to use it without giving them the chance to pick out single VIs for standalone use (which could be hidden deeply inside the project more easily).

QUOTE(nicolasB @ Oct 9 2007, 01:48 PM)

this looks very interesting but I tried to make this run under LV 8.5 and LV8.2.1 and it doesn't work. Even the "OS Open Document"-Event isn't available in these versions.

It's only available, if you have Scripting enabled.

You need to have this in your labview.ini:

SuperSecretPrivateSpecialStuff=True

Please read this first, if you are new to this topic: http://forums.lavag.org/VI-Scripting-Readme-First-t1207.html' target="_blank">VI Scripting - Readme First

QUOTE(yen @ Sep 8 2007, 09:36 PM)

You can do that by using the First Call? primitive. If it outputs T, you use your initial value.

No! That's way to simple! That doesn't count!!!!!!!

ok, maybe you've got a point here...

QUOTE(rolfk @ Sep 7 2007, 09:53 PM)

And just to show what the pre LabVIEW 8.5 version of this code would look like:

Those two images are a really nice example that teach me to use the traditional approach with shift registers rather than the unowned feedback node.

With the traditional version, I recognize the pipelining at once. Even if the new version does in fact the same, it still looks like sequential code if you don't look twice.

I don't think it's very intuitive.

The unowned feedback node still has one advantage: If you use it to build a functional global, you can now have a defined initial value without the need to write to the FGV at least once! :thumbup:

As far as I can see, this can't be done using the "old" shift registers.

It is possible to read the command line options in a LabVIEW application, but only if the programmer made the effort to implement it.

If he didn't document any special command line options, the best guess is, that there are none. :headbang:

So command line won't help you much here.

Maybe you could achieve your goal using AutoHotkey?

QUOTE(yen @ Sep 6 2007, 07:16 PM)

As I said, use the product suggestion center:

http://digital.ni.com/applications/psc.nsf/default?openform''>http://digital.ni.com/applications/psc.nsf/default?openform' target="_blank">http://digital.ni.com/applications/psc.nsf/default?openform

Yes, you are absolutely right!

Did it

QUOTE(Eugen Graf @ Sep 4 2007, 05:42 PM)

Yes, manually. I know I can use Control->Replace and then replace my modern object to a classic. But it doesn't work for clusters and arrays. Furthermore if I replace a object to any other, then the new loses properties, like formatting.

Even if this is solved for the simple task of making a transparent cluster, I'd still like to have a "change control style" option to change the style of controls on a front panel.

This would be very usefull for the cases when I want to use a VI from a 3D-style-project inside a system-style-project.

I'm not only thinking about complex clusters, even a simple numeric control contains lots of configuration data. If you are tweaking all the tabs in the properties dialog (which I usually do for real world user interface panels), you have to set all those properties again for the replacement control. This is a very time-consuming task compared to the simple wish "I want to change what the control looks like".

QUOTE(dsaunders @ Sep 6 2007, 02:15 AM)

I am not sure what was meant by flexibility. I interpreted that to mean that the control labels may change, which would break the configuration file.

There is an easy way to solve this particular issue: When designing your panel, use labels that tell the programmer what the control does. Then hide all your labels and display captions instead. You may change the captions as often as you like without touching the labels.

If you take a look at any localized version of LabVIEW, you have loads of example VIs that show what I mean in your function palette

QUOTE(lraynal @ Jul 20 2007, 09:23 AM)

Don't forget, as well, that you can put *.dir as a pattern to see only the Directories when you browse!

QUOTE(crelf @ Jul 20 2007, 01:56 PM)

I'd rather think this is the misunderstanding of the day.

If you put *.dir in the pattern field, the file select box will show you all the directories and all the files that match this pattern.

I named some files test1.dir and test2.dir and - of course - they were visible with this parameter.

Of course, you could try using something like *.salflsdhflkasflsdjlfdjfl to achieve the effect of a "directory only file select box". But be aware, that this mask will always be shown in the file type field of the dialog and the user can always change it back to "*.*".

QUOTE(Aristos Queue @ Aug 18 2007, 08:52 AM)

Your misinterpretation of my comments is a good idea however. I'll pass it along.

Thank you very much, AQ! :worship:

I would really appreciate a feature to have project-specific function palettes.

The "official NI way" of doing this has several disadvantages (no different library versions for different projects, bad Perforce integration, "illegal" to copy user data to programm files directory...), so I am looking forward to a good way of getting rid of the "user.lib" without loosing it's comfort. :thumbup:

At the moment I am using my project window as a palette, but I am shure, usability can be improved here.