Abdullah R

In my experience, they are quite reliable; most bugs have been traced to code other developers have written, rather than any issue with the shared variables themselves. Couple of points:

1 "Important" (regularly updated, critical) shared variables are read using the DataSocket API, where I connect to the SV engine on the RT target, and then monitor the status of my connection. If it goes down, I reconnect, kind of like a TCP loop. The read values are then Q'ed. Prior to implementing the reads in this way, I would get SV's go down when the RT target was being rebooted, and they wouldn't "reconnect" without restarting the HMI (PC) application.

2 Once connection is re-established, the other static Shared variables seem to connect without a problem. Runtime for built executables (between reboots) can be 8 or 9 days.

3 The Shared Variables are hosted on the RT target and number about 70 or so; some are complex clusters, others are SGL's, DBL's, and even an IMAQ image flattened as a string. Some values are buffered, others are not.

Here are some screenshots:

Neville.

Neville

Great post.

Is it possible for you to share what you are doing in "Analyze Datasocket" VI?

Paracha

No offense, great work. But sometime i wonder do we have to write in an overly complicated way to solve the problem? If someone joined your team in your company, would it be easier for him to understand your code or say mine that uses producer consumer with no dynamic events and many functional globals?

Dont get me wrong but i often see some programmers use LabVIEW OOP (classes), dynamic events, semaphores and rendezvous when

- They are not really necessary

- Their is simpler alternative available.

- There is no benefit of using classes like abstraction, plugable architecture (dynamic dispatching) etc

I hardly see anyone comment by saying "write simple code". For example i really dont feel user event/dynamic event to detect error between two loop was simple solution.

Just thought i should share my feelings. Good luck passing CLD.

BTW I took CLD exam yesterday and i am optimistic, i will clear it

Thanks!

From the LabVIEW 2009 Help Manual here it is...

The Application Builder no longer moves VIs with conflicting filenames outside of stand-alone applications, shared libraries, or Web services for build specifications you create in LabVIEW 2009. In LabVIEW 8.6 and earlier, the Application Builder saves VIs and library files in a flat list within the application and saves VIs with conflicting filenames outside the application in separate directories.

If you build a stand-alone application or shared library using LabVIEW 2009, the Application Builder stores source files within the application using a layout similar to the directory structure of the source files on disk. For example, the following table lists the relative paths for a top-level VI, foo.vi, which calls a.vi and b.vi. C:\..\Application.exe represents the path to the application.

Path to source files Path to files in application

C:\Source\foo.vi C:\..\Application.exe\foo.vi

C:\Source\xxx\a.vi C:\..\Application.exe\xxx\a.vi

C:\Source\yyy\b.vi C:\..\Application.exe\yyy\b.vi

To use the legacy file layout, place a checkmark in the Use LabVIEW 8.x file layout checkbox on the Advanced page of the Application Properties, Shared Library Properties, and Web Service Properties dialog boxes. LabVIEW enables this option by default for build specifications you load from previous LabVIEW versions.

ohh so the size of application and performance is untouched. Well actually the size may now get even bigger because everything is in it.

data reference is what i like!!

QUOTE (Antoine Châlons @ May 15 2009, 04:30 AM)

Next step is to have scripting abilities at runtime...

you are pushing it

The Scripting download for Windows is now available.

Not available for LV 8.5?

As promised, here are the slides from the presentation. I think the topic was a bit advanced for some attendees, however. I got a lot of glazed looks when I tried to explain how important it was to understand application instances when using web services.

Maybe I will get to present this or an updated version at NI Week 2010.

Unfortunately, the slides don't have a lot of details and are more of an outline of my presentation, but maybe you can get something useful from them anyways.

-John

Can you make couple slides talk about the basics like what is web service, why you would want to do that in LV and how you would use possibly use it, use cases? Not having much idea about web services, i am thinking what are these slides all about? To me web services run on websites or ISP hosting servers. Since most of the hosting companies will not have labview support installed on their traditionally linux servers, does it make sense to build web service in LV??

am i missing something??

I usually build my exe and have it call plugin VI out of "Support" folder that sits next to the exe file. The exe calls the plugin VI out of that folder using CallByRef node. The only catch is that you need to have plugin VI hierarchy in that folder or else it will give error saying subVI is not executable. My plugin VIs following certain naming like plugin_Foo1.vi, plugin_Foo2.vi etc etc. So depending on plugin VIs found in "Support" folder, the exe shows the user available plugins as "Foo1" and "Foo2".

Good thing about this model is that, you can update and throw new plugins into "Support" folder without updating your exe. Exe or Source Distro build specs are little tricky but else it works out very well. It is much better than having all the dyn plugin VIs packed into one fatty exe that takes seconds to load. By doing this you also get benefit of on demand loading.

I have tried creating a very minimalist LV .exe with nothing in it but a small low res image of the splash image I wanted to use on the front panel and a simple call to the “System Exec” pointing to the main .exe: This did improve the load time from around 10 seconds to about 7 seconds for the first running of the programme. All subsequent calls were almost instantaneous and remained so until the machine is subsequently re-booted.

7 seconds?? I am suspecting something else like windows. Did you try running the exe on some other machine that has LVRTE installed? Sometimes windows shell get slowed down and it may not be LV exe thing.

My impact list:

1. ByRef Objects - Yes, you can implement byref behavior using single element queues, but having native support for byref objects would eliminate the (sometimes complex) workarounds needed to get that behavior. Byref objects would be huge! At the same time, I've read that NI has no desire to pursue that as it violates the principle of data-flow and encroaches on the solution Endevo provides.

2. Interfaces - So much of good oop design relies on interfaces I would think (and hope) that NI is figuring out how to do this. This is actually the #1 item on my wish list. I can live without native byref objects. Working around the lack of interfaces is harder.

3. Constructor/Destructors - Another carryover from other languages that could change the fundamental way objects are developed and used, I doubt this is on the roadmap for inclusion. The Decision Behind the Design document clearly outlines why they don't fit the Labview paradigm. (It sure would be nice if LV called destructor methods when the Abort button was clicked.)

That said, based on the timeless principle of induction accompanied by a heavy dose of wishful thinking, my prediction for LV2009 OOP new features is...

User defined namespaces -- or at least improved namespacing.

I think #1 and #2 would be nice to have. If they introduced namespacing, that would be ok but not like WOW!!

QUOTE (TobyD @ Jan 22 2009, 01:48 PM)

Totally off topic...but I think I remember Stephen saying once that if his activity on LAVA suddenly increased it was usually a good indicator that all of his work for the next release of LabVIEW was complete and he had a bit of time before work on the next release had to begin. As I read through this thread I was noticing that you've been posting a lot today Stephen. :ninja:

Great now you made him not post anything. Thank TobyD...j/k :laugh:

QUOTE (Aristos Queue @ Jan 22 2009, 12:17 PM)

Hm... I'm running 8.5.1. Are you perhaps running 8.5.0? I don't know of anything that got fixed in that bug fix release that would affect this, but maybe there was something. Other than that, I have no idea what could be wrong.

NOOOOOOOOOOOOOO :headbang:

Such nice design of my software is now in jeopardy because of this issue!!! Yes i am running 8.5.0. Is 8.5.1 free upgrade or paid?

Where is what i see in 8.5.1 bug fixes that looks close.

QUOTE

and labview exe is essentially an LLB. Any workarounds?

Ohh God!

QUOTE (Aristos Queue @ Jan 22 2009, 12:00 PM)

I just tried Eugene's 8.5 .zip file -- it works just fine in 8.5.

Eugene added a bit of extra code to it to make it more interesting... here's the 8.5 version stripped back to just my original example.

http://lavag.org/old_files/post-5877-1232650822.zip'>Download File:post-5877-1232650822.zip

@AQ, i tried your zip file just now, no changes made. When i run the VI, yes it works and i do see "Kid". Then i build executable, it says Parent when run. See attached screenshot of exe.

@Aristos Queue

Any ideas?

QUOTE (Eugen Graf @ Jan 22 2009, 03:32 AM)

Here you have

Thanks Eugen, but your code does not work, the problem is actually masked and hence you dont see any error messages. I have added little debugging indicators and i see the same error as i get with my code. See attached updated zip file.

I dont understand how it is working on your side?

QUOTE (Aristos Queue @ Jan 21 2009, 09:34 PM)

Here's a simple example that works.

http://lavag.org/old_files/post-5877-1232598869.zip'>Download File:post-5877-1232598869.zip

Thank you for your help. Would you be kind enough to send me code in LV 8.5? My company does not upgrade immediately

LabVIEW 8.5 code Please :headbang:

waiting for a breakthrough.

QUOTE (Aristos Queue @ Jan 21 2009, 03:55 PM)

Did you tell the project to put the class files inside the EXE? The only ones that are inside the EXE are those that are used by the Source files. If you want other files to be included in the EXE, add them to the bottom section where it says "Always Included".

Yes if you look into the attached project, you will see that it does say that destination of lvclass is in "Application.exe"

Ok i tried that, but it seems like the .lvclass files are not in the EXE. I have tried the same thing on Factory Pattern example to make sure there is nothing wrong in my code and it is same behavior.

See attachment.

FYI. i am using LV8.5

I have base class with two child classes following the factory pattern and use of "Get LV Class Default Value.vi" for dynamic loading. For my built app, i include two base classes into EXE (under "Source Files:Always Included" section). What i am seeing is that after the app is built, i see two folders next to exe with only dynamic VIs in them but no .lvclass which is what i need to load the class by its path name.

Where is child1.lvclass and child2.lvclass are? in exe? I need path so i load it in exe.

QUOTE(Aristos Queue @ Oct 30 2007, 09:23 PM)

Look up the Factory Pattern in the http://forums.lavag.org/LabVOOP-Design-Patterns-v10-t3845.html' target="_blank">design patterns document.

Now that is elegant. However looks like "LVClassLibrary::DefaultInstance" is a private method and i can not find it under LVClassLibrary's properties. Hum... i guess i have to copy it from LVOOP Navigation example where it is left purposefully!

Now my class behaves exactly the way i want it (as long as i do not built executable of it). Thanks!

Ok i looked very carefully what was happening and i found the explanation. The problem is that my abstract class (parent) has a Class Factory VI whose BD is shown in the attached figure#1. It has static instances of child classes and thats why parent is loading all the 5 children into memory. I have confirmed that if i remove static instance, then only the parent is in memory and not the children.

Now the question is how to elegantly solve his issue? The only way i can think of (which i dont think is the best) is have a public VI in each of the children that just returns its reference. Then use "Call By reference node" in the class factory to call that VI which just returns you its reference. See figure#2. And yes that solves the issue and that only parent is in memory.

Other ideas are welcomed Thanks all!

Figure#1 (causes the children to get loaded into memory with parent instance)

Figure#2 (Good! Only parent is in memory at edit time)

I am not sure if this has already been discussed. I hope this is not a duplicate post.

I have an asbtract class that just exposes an interface (i.e. bunch of public VIs with pass through wires on BD) for children to implement using dynamic dispatching. This class has 5 children classes with lots of private subVIs besides the dyn dispatched interface implementations (public ones).

The problem is that outside project environment (i mean when I close all projects even restart LabVIEW) and just open a blank VI and drop abstract class object (Parent) on the block diagram. What i see in "VI Hierarchy" windows is that ALL 5 children classes with ALL of their SubVIs have been loaded into memory. Is there anyway that children classes & their VI be dynamically loaded into memory at runtime? The reason is that based on inputs to abstract class, i know it will only need to load one child class for particular end user of mine. To the end user it is not only waste of memory but also slow loading time because LabVIEW is loading into memory 4 classes that i know the user will not need at runtime.

Is there anyway that i only load thin abstract class at edit time? I hope i made myself clear!

Any ideas around this problem? suggestions? patterns?

Thanks all!

The only reason i wanted to write a plugin is because LabVIEW project shows you nice status of each file in project view. Also (not sure about this one) doesn't labview also automatically checkout all the called subVIs when you check you the top level caller? And also i think as soon as you start editing a checkin VI, that it prompts you like "This VI is checked in do you want to check it out? YES NO?".

I agree those are nice to have features. I am comfortable with DesignSync command line interface but the engineers who will be working with this will definitely find it hard because they have no previous exp with SCC what so ever. I just wanted to make it easy for them to do SCC operations from within LabVIEW env.

I guess i will have to write some utility VIs that would nicely wrap the commands for check in and check out etc.

Thanks for all who responded.

We are using Design Sync as our company wide SCC which LabVIEW 8.x does not support in project environment. Does anybody know

1- If there is a way to write your own SCC plugin for LabVIEW project that would perform checkin/checkout etc operations on the files in project without users going through the command like interface of the SCC we use?

2- If there is a way, can somebody point me to right direction? How to get started on writing your own plugin?

Thanks

Abdullah R

Where can we find VIs that you showed in your superb NIWEEK presentation? I tried looking at the website but didn't notice any obvious link for that.

Thanks

paracha3

LabVIEW 7.1 announced :thumbup:

LabVIEW 7.1 Link