LogMAN

Do you mean "select the terminals" and the little pull-down menu of alignment options?

Exactly.

I agree, selecting pull-down menu takes time, but as I get used to it over time it goes faster and faster. Also you just need to do this like two or three times a hour after adding new controls / indicator (as I write programs).

I did a little CAD work back in the day and I've always found the LabVIEW alignment tools to be slow and clunky. A relatively simple "snap to guidelines" feature (aligning in both dimensions to related objects and also aligning for straight wires) would make it easy to write code clean from the start.

I frequently use CAD application too, but I always liked the way LabVIEW does not automatically snap in position. actually it does make some things easier for me (on large VIs with many wires). Best solution might lie in between (like turn on / off snap positions by hot-key).

I can't say I care that much about the standard types either way. A string is a string. But mixing icons and smaller types means I have to go through the effort of manually changing either the standard or non-standard types. And in larger diagrams, with only a few controls/indicators, I don't see much benefit to the smaller terminals, even for standard types. But I'd be happy to meet people half way if we all want to standardize on small terminals for simple types and icons for objects, type-def clusters and enums, refnums, or anything where the small terminal doesn't convey the full type.

I disagree if it comes to mixing everything up, since this would make a VI even more unreadable.

How about adding a tool where you can design your own control / indicator symbol of a cluster / class or any complex type? ...(That would possibly make things even more complex......)

Flipping back and forth between BD and FP just to figure out what the terminals are? Can't say I like that option for code clarity!

I agree, flipping between BD and FP is not a solution. In my opinion, if you even need to switch between BD and FP, your VI got to large and you should consider using SubVIs. But using large icons does not solve this problem too, since they also do not show all information about your type. So what I usually do is using the help window while programming large solutions on classes or other object related projects (It will tell you more as you could possibly show on any icon).

A bit of history here... when the icon FP Terminals were first added, I didn't like them and asked they be removed because all they did was reflect a few FP controls/indicators. Those who do the usability testing on LV said that it benefited newbies to recognize the association between the thing they dropped on the panel and the thing they dropped on the diagram. I sighed and said, well, if we're going to have icons, they might as well be *useful* icons, so I made the VI Refnum reflect conpane, made the other refnum types show something other than just the folded corner of paper, made the typedefs show their control icon, and made LV classes show their type icon (originally they were all cubes). And then, as time went by, they started growing on me.

Maybe it's just prisoner syndrome and I've started identifying with my captors.

sense of humor at the end?

Let me say just this:

Thanks for adding large icons, they helped me a lot when I started programming in LabVIEW.

Thanks for letting me choose between large and small icons, I really appreciate this.

Whether my VI benefit from small icons or not depends on my particular VI and my specific way of programming.

I suppose a bad programmers VI will be unreadable no matter which icon he or she uses, am I right?

If you want to know something about your VIs readability, just open a VI you wrote one or two years ago!

Just got thinking:

Maybe we are running in circles on LabVIEW, like when you are beginner, you use large icons, at some point you switch to small icons and when you are professional you might switch back to large icons... I'm pretty shure there has been a similar singularity here on LavaG.

Indeed... I have to debug this application wich is full of locals,globals, and explicit naming VI (like: "dialog18buttons.vi")

Haha...

I'm so sorry, couldn't hold back.

Getting more serious: I'm sorry for you, not because of icon terminals, but about globals and explicit naming...

An experiment. My previous subVI redone to be more like ShaunR's style:

+1 +1 +1...

I like that

Actually this is also my style. More readable, easier to find terminals, less space, more flexibility.

You should use your own style of programming, but please don't mix everything up, that would make things unreadable.

2) I, personally, find it less tedious to spend time making up lots of icons than carefully aligning and adjusting things into small compact diagrams. I'm perfectly happy with my previous diagram that takes up twice the space and doesn't have the terminals all lined up, yet I'll open the icon editor if I notice a few-pixel inconsistency among related icons. Your OCD may vary.

You know LabVIEW can automatically align your terminals by two clicks?

--> I always spend time to clean up code, since it will come back to me after some time (easier to maintain).

As I started programming in LabVIEW, I liked using icon terminals. At some point they just bother / disturb me and I switched to small terminals. I understand the 'problem' of object or reference types, but I don't understand what you could possibly miss on small terminals for standard types like string. I would say standard types are best to read on small icons. If you don't understand standard type coloring, you should properly change glasses... If you don't remember the type of your object, just switch to FP (icons on FP are much more readable than icon terminals on BD).

Cheers, LogMAN

How comes LavaG post editor does not know words like "LabVIEW" or "LavaG"???

Hello !

Thanks for the replies !

Tim_s, using scale all objects on front panel etc.. does nothing good. Especially on complex front panels!

If one wants to control behaviour of controls while changing size of FP, there is only one way : program it!

Ton, you are perfectly right. Anyway I don't want to change only the size of the FP.

So apparently there's no way to change panel size....

Is there any trick to set their sizes ??

Thanks again.

Yo

Hello !

You can change positions of variant elements by using the generic 'position' property (you should have discovered that).

Apperently the 'bounds' property is read only, exept of the FP itself (panel bounds) and some elements (e.g.: XControls).

Is it possible to change 'bouds' property using VI scripting in future versions of LabVIEW???

(I use LV8.6 with VI scripting, but there is nothing there)

I generally use a VI to automatically resize the FP size to the largest decoration (frame) or to full screen.

--> This is good to show multiple windows in same size.

But that is no solution if you also want to change particular element sizes. You will have to do that manually.

I recommand doing it manually, since you need to fit controls to it's contents and your personal visual style.

LabVIEW does help you with tools to automatically align elements and fit sizes (There are three pull- down menus available):

http://zone.ni.com/reference/en-XX/help/371361E-01/lvhowto/aligning_objects/

Of course!!

In many cases it makes sense to take the time you need to develop a

'better' solution (even If your collegues don't agree).

For example if you develop an test application which will be used on multiple

targets and get changed or more advanced over time.

The problem is, generally (In my job) you don't know if it will be used more often

in the future.

However in many cases if you use the 'easy' solution, someday it will kick you

back in the ass (or one of your collegues if you are lucky) and you will ask yourselve

why you didn't use the 'better' solution in the past.

<<-- you know that solution? | You may use this solution! -->>

But which solution is the best?

--> depends on your problem

My experience on this matter is that in many cases you will programm the

'better' solution someday, even if you program the 'easy' solution today.

So just programm the 'better' solution if you get the time.

Please notice:

There is often more than one 'better' solution.

Your solution is the best of course!!!

Greetings, LogMAN

Hello, KeA

If I understand you the right way, you've got a framework implementing an class (interface) for loading inherited classes (components) dynamically.

Your components implementing sub- classes, which are instantiated somehow.

How do you instantiate your sub- classes (modules) within the components (statically / dynamically)?

If you statically instantiate your classes, the application builder will respond errors as you receive, because your modules (sub- classes) have

the same VI names / hierarchy. In that case I recommend you changing the VI names to match a specific pattern which does not cause VI name collision

(e.g.: <Class name>.<VI name>.vi --> CModule.Class Initialize.vi)

You could alternatively change your code to dynamically load the modules at run time (since they share the same VI names). In that case you need an Interface class, loading the inherited modules.

If you dynamically instantiate you classes you'll receive errors if you run your application in development environment (LabVIEW) once and then create the source distribution of your modules, because LabVIEW already loaded the class in memory while executing and will only unload if you close your project (or LabVIEW). In that case you should reopen your project in LabVIEW and create the target solution without execution the application in development environment.

The application should be able to dynamically load classes even with same named VIs, since class member VIs inherit a class specific prefix in call chain.

(<Class name>::<VI name>)

Greetings, LogMAN

Hello!

I can't belive it, what causes the LV crash. I've tired with LV8.6 without any result.... Same faulire, and no error log...

I did what u suggested, but I dont know how to go on...

Any ideas?

Wow, that's a hard nut...

Just as precaution: Create a second "initilize array" for the CHAR of "Model", I don't know if LabVIEW handles the array correctly.

dwCameraID should be U32

Also switch back "number of cameras" to U32.

Everything else seems good to me...

You should play around a bit, especially with the configuration dialog of the dll. There are some options about

the threading (UI thread / ... thread) - The data format (Handle by value / Pointer to handles) is also interesting.

Has anybody more experience in calling dll files with structures???

Hi LogMAN!

Thanks for your reply!

I've made the modifications but my LV crashes!

When I Set the Number of Cameras parameter to 1 (only I is connected currently) my LV crashes. BTW, If I set it to zero, I've return value, in Param cluster - NumberOfCameras = 1, but the remaining fields are empty...

But, as I read in the document, I have to Set the input parameter value - number of cameras

OK, according to the dll manual (as I read it) you have to change your cluster to an array of cluster which has the same

number of elements, as the number of cameras at your system (1 element in your case).

you can receive the number of cameras using the function "is_GetNumberOfCameras ()" of the dll

(but for now the constant is much easier).

If that does not solve the problem, try the following:

Change the "number of cameras" value from U32 to I32 --> depends on how LONG values are represented in the dll.

You might also try changing the data handle from "handle by value" to "pointer of handle"

In the dll configuration dialog there is a tab named "Error checking", just set it's property to maximum to receive error messages from LabVIEW.

LabVIEW might show an interesting message pointing to the particular problem.

Note: It's recommend to change the error checking back to normal before finishing the project, maximum error checking might cause problems later.

Hi!

Could you help me to solve my DLL call problem? Please take a look at the attached images.

How do I configure the parameter?

Hello, durnek60

First of all, change the string constants (SerNo / Model) of your cluster to arrays of bytes (numeric U8 in LabVIEW), since

chars are arrays of bytes. The arrays must be initialized (at least 16 elements for each) or the dll will write data in places which are

already in use by LabVIEW -> might cause LabVIEW to crash!!!

The DWORD values should be at least U32 values.

The last DWORD value (dwResrved) should be at least U32 and must be initialized like the char values.

I recommend initializing the arrays using the "initialize array" VI of the array palette in LabVIEW (just to be absolutely sure).

Hope that will help you.

Sorry, can't help you with the configuration dialog, since I don't have an LabVIEW installation on my current system.

If the problem does occur anymore you should also share the error messages and the configuration dialog of the your dll call.

Greetings, LogMAN

Hello guys,

I run into an error similar to this post (actually the same, but I don't like the answer and it's old).

I'm trying to change an build specification for an installer, which contains multiple exe- files with the same target directory. (LabVIEW 8.6.1f1)

Some of the exe files use the same *.dll file (lvanlys.dll) which is automatically included by the application builder.

I've already used the same project a couple of times and LabVIEW has never complained about anything. Just now I've added

another application and nothing works.

What am I doing wrong?

Is there a way to tell LabVIEW everything is OK? (Since it's the same file, so what)

I don't want to seperate the exe- files in own directories.

Greetings, LogMAN

Besides questions 2 and 4 I still have some questions regarding question 3:

Under the user.lib library in labview I simply added vis with the code I wanted to use from the palette or simply a vi I wanted to use.

I then went to Tools->Advanced->Edit Palette Settings and saved the changes.

All went great till now and I didn't have to use Vimp build palette.

However, I wonder, how can I add a vi from a class or a ctrl into the palette?

Should I add the entire project into the user.lib?

Moreover, I added the entire library of an xnode into the user.lib yet once I try to use it from the palette I the control file and the xnode file are missing.

Hi, Jubilee

You are free to add any VI or control of your choice to the palette, but project files will not work (even so I've never tried).

Using Tools -> Advanced -> Edit Palette Settings you'll get two palettes (function palette / control palette)

just right click on the particular palette and select AddVI(s) on the functional palette and AddControl(s) on the controls palette.

You can select class member VIs just like 'normal' VIs.

(Exception: public/protected VIs might not work from the palette)

I don't know how xnodes are working on the palette, but it should work either.

To your question 2:

Note: I'm not trained in license stuff, but have some basic knowledge.

Using open source software funtionalities to create new software (even commercial) is no problem,

but the source code is protected by the license and copyright. Therefore, using the JKI

RCF is OK, but don't copy or use it's source code unless you have the right. You should read the license

of JKI RCF.

Software is protected by the programmers license. His or her license must be part of the source code or the entire project.

(Text on the FP or BD / file in the directory)

Is software protected which does not provide any license information? -> I don't know, seems to be free for use, if you

ask me...

Of course there are different types of licenses:

BSD: This license allows you to freely use the code for even not open source software.

GPL: This license forces you to put your software on the same license as the source code and you have to provide your own code for free.

LGPL: This license allows you to use the open source software even for not open source software, unless you don't use the code

directly (as sub-VI), but as own library (DLL).

And much more...

Note: all samples above are much more complex than I could write.

You better read some articles from wikipedia or the particular license provider. You might also directly ask the programmer.

I recommand to only use free software for commercial use, if it is protected by BSD, which allows you to freely use it.

I also recommand to provide code which has been programmed using open source software.

OK, much writing, less information...

To your question 4:

JKI RCF bundle wire plugin

Greetings, LogMAN

I have to wonder if things would have turn out differently if the software developer had not insisted on multiple inheritance.

Ben

Just guessing about multithreading....

That king wasted a great chance, but hey, the developer somehow is alive, check out this page: toaster pc

There is just no space for a toast....

Sounds like you might be better of to have Scan Validation step which determines whether or not the scanner data is worth putting on the stack in the first place.

Double that answer!

Validate you data before putting it into the buffer!!! -> Less headache in the future, believe me.

Why not only putting the last scan data into the buffer, since this seems to be the one to be used?

If you can't validate which scan data is worth to be used, even an LIFO buffer will not help you, since the last element

in the buffer could also be invalid.

Note: Even if you enqueue the last element of the queue, you have to handle the remaining ones or your buffer will grow...

Greetings, LogMAN

That's fantastic

Just goes to show.

"There are no bad programs, only bad programmers".

I think I'll set that up as my wallpaper....move over Grace Park

Great idea. I know some people who think if they don't see the canvas, the program is using the memory more efficient.

(I havn't yet proved that)

I should upload a wallpaper collection for you (slide show).

It's obviously better to read. Gosh, how do you sustain this during debugging/trying out when your not sure what will work best?

It's not like my programs are perfectly designed at the beginning, but sometimes there are some functions I know I will use more often,

so I take the time to make it more readable!

The only thing I do always is correct wiring, because it makes it easier reading code after a day or so.

You know:

You can do 80% of work in 20% time, but you'll need 80% time getting the last 20% work done!

(I forgot who said this sentence first )

So, after finishing a program in LabVIEW, I go through the code writing it more readable and placing documentation all over my

VIs. It's hard work, but it worth the time.

However - Your code is much more readable as most of the code I have to read all the day.

Code like this: Caution: Bad code! is very common!

One thing that's really great with your project: The way you organize your VIs in your *lvproj.

So, don't worry and keep on programing, writing code more readable one step after another.

(Do one thing better each project - )

I hope anyone who has experience with a text-based language can understand how MView works after reading through the example scripts.

Your MView programming language is well designed, as far as I concern.

Even if I don't use your project as is, It's a great base concept for me to write a similar distribution!

I was going write a similar project like yours, but I'm to lazy for taking the time of a concept like your's.

So, thanks!

And a LabView question:

The memory management of this code is...well...lets say not great. I wanted something quick and easy to implement, so I ended up with arrays in clusters in arrays, and I see problems with speed and expect problems with memory allocation because of the requirement to have arrays in continuous memory. For now I won't change it, but just a thought: Labview has an interface to it's memory manager for external code, with ways to dynamically allocate memory when needed. Is there a way to use this from within LabView without writing an extensive wrapper?

I don't know much about memory management in LabVIEW, so it might worth the work of writing a new post (Interesting question).

You could write an external DLL in a conventional language, using it in LabVIEW as "Memory" (Not Recommanded)

You might try some of the 'In place element structure' functions (LabVIEW 2009 and 2010 are getting better with that step by step.)

One thing about your memory management just now:

It's an interesting way of thinking and writing something like heap and stack (pseudo, but however) in your project!

Nice to read and something to use somewhere else...

Thanks for that kind of idea too.

Greetings, LogMAN

You are right. And a test-vi is broken. Here they are:

Put them in the MView directory and it should work.

Thanks, it worked just fine.

Thanks to you and asbo for the tips. I knew already how to force empty space into a diagram. I have two problems with it: What you said - the movement off all other code. It makes it sometimes look worse. And in a vi like this interpreter, with its endless sequence of case-structures, should I force space into one of them, I have a larger number of mainly empty cases. Most of the time no issue, but if the vi grows over my screen-size, I stop. The cleaner way would be to make a sub-vi. But one little change still fits in, right? To avoid the work of making a new icon, wiring up the front panel, giving good names to the FPOs, etc. And then another fix is need...lets squeeze everything a little closer together, right?

I know exactly what you mean.

Using LabVIEW as IDE makes programming easy like playing a game.

But design in LabVIEW is as important as description in conventional programming languages.

A good way to clean programming is a design concept.

You have to define your programming design and use it in all your programms.

(Believe me, after some time it goes easier and easier)

Here are some concept ideas I use normaly. They are easy and fast to implement

after some training:

1. Do never create wires behind structures, you might search errors for hours!!! (Move wires above or below the structure.)

2. Use one connector pattern in all of your VIs (except of special VIs), with error in and error out connected to opposite connectors at the same place every time. (This will help you creating a "VI line" and using the "flow" concept of LabVIEW. (Even change the pattern of automatically created Sub-VIs.)

3. Do not move wires around like snakes. (I know it's hard at the beginning, so right clicking the wire and selecting "cleanup wire" helps )

4. Programming VIs, larger than your desktop should only expand in one direction (horizontal, vertical).

5. Use labels on your block diagram for documentation. (I normaly use a special color for documentation labels)

6. If any function might be usefull somwhere else, create a sub-VI. (VI icons should at least have text within)

7. Are you using parallel loops, larger than your desktop? Create seperate VIs for each of them.

8. Move inputs on the left side, outputs on the right side of your block diagram.

9. move labels of inputs on the left border, labels of outputs on the right border. (Implemented as option in LabVIEW 2010)

10. Do never lecture your concept ideas... aaah...

I know these concepts does not work always, but it's much easier to maintain your VIs, if you have a clean concept.

The "Right Click Framework" is also a good way to clean VIs (Thanks to all).

There are two snippets attached as sample for the concept. (First is original, second is changed)

Wow, my hands are burning... I'll need something to cool my head.

Cheers, LogMAN

Anyway, code is attached, if I find the time I'll clean it and hopefully bring it to certified standard. Might be a while, though...

Hi, j_meier

I think the MView.lvproj file is missing in your new build.

However, your code is just amazing!!!

first post here... ...never released any code to the public

Very efficient...

...straight wires...

My big weakness: good planing. First there is so much space, and then it gets crammed, and then...curves, bends, this vi could still fit in that white space, now where to put this wires? etc. How do you fight this?

It's true, caring large VIs is important and necessary.

If you need space on your block diagram, hold the 'Ctrl' key and use the left mouse button to make space. Release the mouse button to commit.

Carefull:

marking an rectangle will cause all code to move in 2D.

To make space in one direction, move your mouse until there is a straight line (almost not visible).

Tip: Use a dummy- VI for testing.

...icons...

Learned this now. I'm not good with graphics, so I'm just typing the vi-name in the icon. Helps a lot about readability.

Yes, it's hard to read and the VIs need some Artwork, but

the functionalities are amazing!!!

I suppose your code will be used in many projects from now on (Of course after some enhancements).

Cheers, LogMAN

Actually jgcode pointed me to already filled CAR #185059 on similar issue. It concerns VIs which are member of a class whiech belongs to lvlib. LogMAN, you did your test for lvproj, probably if you would try it for lvlib, you'll get similar issue...

No wonder I never encounter an error like that.

I've never used classes in project libraries.

So, problem solved ... somehow ...

They are public and their class is public as well. I'm able to drag them from palette and use normally.

In the subpalette of this palette there are some VIs from the same class and they appear without such glyphs.

This palette looks the same after restarting LabVIEW and when installed on second computer.

As an experiment I tried to change scope of some other VIs from another class and another palette to private, then I refreshed palettes and there was no change in VI appearance on the palette (no glyphs).

That's interesting...

I've attached two files to prove. (TrayIcon.RegisterEvents and TrayIcon.EventHandler are of private scope)

Changing the classes content to private will cause the files within the palette to show a red cross.

I also need to update my last post:

Protected items are shown with a red cross too.

Sorry, but if your class is public and you have full access to all contents,

it might be a bug.

Can anyone tell me why do I see such crosses in my palette?

They are in only one subpalette, palette work normally (well, almost normally - once VI's from this palette changed to ? on the DB).

There are no such crosses during palette editing (BTW palette editor start takes about 2 minutes). I already tried rewritting mnu file with palette API.

LV 2009

Hi, vugie

The VIs are marked as "private".

So, if you use libraries or classes and a VI is marked private, it'll be shown this way.

The problem is: You can't use these VIs until your VI is part of the class or library.

To solve the problem, open the library or class and mark them as "public".

Note:

VIs with red crosses are private.

VIs with yellow crosses are protected.

VIs without crosses are public.

Greetings, LogMAN

Hi Ton,

Thank you so much for the reply. But I am using LV 8.6 I couldn't open your vi's. Any possibility to get vi s in LV 8.6?

Thanks in advance,

Suvin

Hi Suvin, I've saved the snipped for LV86. Distribute.vi

There is also the Object_distribution package for OpenG attached (also for 8.6) Object_distribution_86-1.2-0.ogp

I suppose you are already using JKI VIPM.

Greetings, LogMAN

Edit: sorry, VI was broken - now it's fine.

am trying to create installer i am not able to i am getting an error telling "unable to locate the installer source for "NI labview 8.0" distribution locate ditrbution and try again" i am bigner can any help... 

hi..i ma using 8.0 version

Hi, venky 2810

This should not be a big problem.

While building the installer LabVIEW ask you to insert the LabVIEW DVDs.

If you insert the DVDs in your machine and selecting the correct drive name it should work.

Greetings, LogMAN

two minutes to late... Jim's first.

Hi, Ton

I support the answere of mje with one additional thought:

I suppose your application is running in two asynchonous loops, which results in multiple threads on your machine.

Multiple threads (multithreading) forces programms, which are not using the CPU at this moment to switch to background,

so another application could run for a couple of miliseconds.

If you execute your sender loop to send the "stop" command, it it's using the CPU completely by sending the command and

directly destroying the event, so there is no point for the computer to force the process to the background.

By adding a wait functionality, the thread will be halted for just a millisecond or less, even with a zero connected to the terminal.

Within this milisecond your listener loop is able to receive the event request to execute.

After that, the sender thread comes back and destroys the event.

So the behavior you've described is not a bug, but a multithreading dependend problem.

To solve this problem, you could force the sender thread to wait for just a milisecond as you did.

But this way of programming is not very good, because as mje already said, it results in undefined states.

You should consider to add some synchronisation functionality in your code as I would do, or just don't destroy the event,

because LabVIEW will take care of that on it's own (also not good style).

Greetings, LogMAN

QUOTE (tcplomp @ Apr 15 2008, 10:47 PM)

Maybe I'm doing this wrong, but when I switch between conditionals, I right-click the project in the "Project Explorer" window and select "Properties..."

In the "Conditional Disable Symbols" section, the only options I see are "Add" and "Remove Selected Items". So far, my only solution is to first remove my symbol, then re-Add it with a new value.

Is there a cleaner way to change Symbols in a project? That would surely make my day.

Cheers,

-H

Just click at the particular entry and change it (as shown in the picture)

We have used LV2009 for one large project and never since.

That was because of many failures.

For instance: Error in Line XYZ in MemoryManager.cpp.

LabVIEW crashed with this error every 2-3 runs. Also after we updated to LV2009 SP1...

We switched back to LV8.6.1f1 and everything works fine.

Also the VI and EXE files were larger (LV2009: 15Mib / LV8.6.1f1: 12Mib)

We use almost everything of LabVIEW, except of Mathscript and Remotepanels.

Our applications have about 200 - 300 self made VIs.

We are in need of better multicore processing, but LV2009 is to unstable.

But I think, wether to use LV2009 or not depends on your needs.

If you do parallel computing and need more performance using multicore processor,

LV2009 might be a good choice.

If you only do "normal" stuff, LV8.2 or LV8.6 / LV8.6.1f1 is the better choice for now.

Install LV2009 on one computer, load some of your projects and do some

tests. (Also perform some errors!!!)

Greetings, LogMAN