Olivier Jourdan

My girlfriend is studying at Sciences Po for her third year of law school. NI will allow me to work remotely for 9 months. With that perspective, it's not hard to figure out where I'd choose to be.

You should visit us at SAPHIR during this 9 months. We are in the french Alps at 3 hours from Paris in train.

Just bought my ticket

I've missed this post

Congratulations! They are beautiful. Hope your nights are not too noisy

I still find it amazing that NI never came up with something like this as part of the professional version of LabVIEW

I think that VIPM and LabVIEW Tools Network is the solution that NI provide in order to "upgrade LabVIEW experience". It gives access to tools (free or not) with a minimum of "quality" checking.

It's certainly have to be improved but I think that it's done continuously since it was released in LV2010.

As a side node about "XControls things to know", I encourage to read this post, it's good to know that before starting to use XControl in your code.

Thanks for the toolkit but I can't hear any audio on any of the demos using Safari or FIrefox, both with Flash 10 installed. Any good ideas?

There is no good idea because there is no audio My spoken english is worse than my written english

What license are these released under? The NI page doesn't mention.

Excellent question

Saphir Software License Agreement (see attachment) is displayed during installation process. Anyway, I know this is not really fun to read, so to be short:

• You can use XControls in any app you want (free or commercial app)
  
• You have to mention the use of the toolkit in someway
  
• You cannot resell the toolkit
  

SAPHIR-SLA.txt

Please have a look to this important note about our free toolkit update here --> https://decibel.ni.com/content/groups/saphir-toolkit/blog/2012/03/12/important-vibox--probes-update

We encourage every users to update as soon as possible and hope that nobody has came across this issue.

Regards,

Olivier

Cluster seems to need a "classic" object to be typed, could be understand. I also tried to load VIs in subpanel contain in an array, but I couldn't retrieve the reference to each subpanel.

Anyway, I have to say that trying this could lead to some difficulties like the management of the modification of the array content. How LV could manage references from deleted element. If this was easy to implement I'm pretty sure that NI would have enable the feature.

Regards,

Olivier

Actually in LV2011 you can put a subpanel in a cluster and then into an array. I am not sure if you can do anything useful with it but LV does let you do it.

LV let you drop the subpanel in the cluster but code is not executable. I think we need to remember that a subpanel is "special" control. It has no terminal on the diagram, so it's not really surprising that it behave differently.

Anyway, it would be really exiting to add it in an array. I'd like to do that many times

XControl could be seen as a subpanel, you visualize the FP of the facade.vi and as far as I know you cannot use a subpanel as element of an array.

Hello,

I was a big fan of "Locate File in project" tool. Does it need to be still supported since his feature seems to be supported by Ctrl+ Shift +E short-key (available since LV 2009).

Regards

The easiest way (I don't know about TCP and databases) is to use the database connectivity toolkit. Regards, Rodéric

The sqlite binaries can be compiled for VXworks. It's something I looked at (and successfully compiled), but since I don't have a vx works device for testing; couldn't go much further.

there was a pay for proffesionally supported one from Safir over in France. (www.safir.fr)

The toolkit is from SAPHIR (www.saphir.fr)

Concerning PostgreSQL, if you have access to the TCP protocol (I never used this database), it's the better way to implement it in order to support RT target. Indeed, RT target could run on Pharlap or on VxWorks and you should write two different wrappers to support both OS.

Last personal argument for TCP protocol, writing G code is much more funny than text based language

Olivier (from SAPHIR )

Only, presumably, if the team agree that OOP is a reasonably good set of rules. I doubt ShaunR will be much impressed with this argument.

I'm not trying to convince ShaunR, I'm just sharing my experience with OOP I've been working with LV for a few years now, and moving to OOP has been for me a great thing. That's not a reason to not understand ShaunR argument. I've"liked" is post, anyway I think is way of thinking reach limits when you work in a team.

If you are not using POOP (Predominantly Object Oriented Programming) then a lot of the POOP design patterns are no longer relevant since the problem that they solve becomes trivial and most of the mechanics gets handled by the language (yes I'm looking at you "singleton"). With POOP, the problem is usually "State", transitions of state and how to manage it. That's not to say that there aren't any in non-OOP languages, They are just usually called "frameworks" and tend to be more generic. The thing to bear in mind is that design patterns solve a well known problem. But that problem is usually a restriction in the language or paradigm you are using (sometimes called "Idioms" by the Architecture Astronauts). Therefore design patterns tend to be paradigm/language specific (not all...but most). But you have probably been using non-OOP design patterns for quite some time (State Machines, Producer/consumer, Publisher/Subscriber)

Take Monads for example (a functional programming design pattern)

Sound like VI's and terminals? We (as Labview programmers) have no need for this "pattern" because it is an in-built feature of the language (we chain VIs [monads] together using wires [pipelines] via their terminals [bind/return operators]).

A good example of a design "Pattern" that IS useful in Labview is the Producer/Consumer (we all know that one - it's a template in Labview). Why? Because it addresses a restriction of the language (it breaks Dataflow). Most of the time dataflow is our friend (it automagically handles state and imposes strict sequencing in a parallel manner) but when we need asynchronous operations this is a simple generic pattern in our arsenal.

So what POOP patterns are useful to us in "classic" labview? As a general rule -.those that break dataflow! So we have a use for things like the "Observer Pattern" or, as we muggles call it, "Publisher/Subscriber". But we also have uses for the more structural patterns such as Strategy (think plugins), State (think state machine) and Facade (think API). although these could arguably be called "idioms" for classical Labview usage.

And those that aren't very useful? Well. Most of them Labview itself makes most of the issues associated with POOP patterns fairly trivial. Many are variations on a theme (Mediator and Facade for example). Many revolve around instantiating objects - Creational patterns (we generally define all objects at design time). And many are based around managing communications between objects - Behavioral patterns, (we have wires for that).

Why aren't there many references to design patterns outside of POOP? Because they generally solve problems caused by POOP.

Now where's my hard-hat.

One thing that OOP helps to solve is the team work. OOP has "rules" that you must follow, when these rules are well known, you reduce dramatically the need to write documentation on how access data, how share source code, how organize your VIs, etc... Also rules are better followed when they come from "nobody" (OOP is not a guy in your team) than if they come from one man in a team. This avoid most of quarrel in a team...

since the probes will always be used by nice friends like us and not in delivered products to customers (where you don't know who dislikes what), you can safely change the font on all text on the probes to a common fixed font like Tahoma 13pt or something. Within the development environment, we care more about getting access to the right information for debugging and wouldn't mind that you deviated from the recommended Dialog or System font.

I was thinking about doing this font change, but I'll wait to see if there is feedback on this issue to decide if it's worth the work (there is almost 100 VIs to modify !)

Anyway, thank you for sharing your idea.

Olivier

Just to give an update, the last version (1.2.0.18) of the package is now available through VIPM Community edition

Good thing to move to the Mac

I'd recommend you Pixelmator it's not free but it really worth the few dollars and the app is really well integrated with OS X environment.

That was my first thought, but I don't think that list includes dynamically-launched clones (which AQ will be using, I think). At least, it didn't seem to work under LabVIEW 8.6 when I tried it briefly.

-- James

You're right. It doesn't work

Great work Ravi!

I've got some ideas about your tool.

Use All VI in Memory property could be interesting to access all VI without editing code. To avoid selection issue when lot of VIs are in memory, adding a filter to the VI list could be sufficient.

An other way I'm thinking about to built the VI list is to use almost the same thing we use in SAPHIR "Chronograph" probes. If we can list the VI where a probe is open, you could easily build the VI list to pause. I think it can be a good solution between "All VI in Memory" and "adding code". The only matter is that as far as know we are not able to know in which VI the probe is open

Anyway, it's the first time I heard about this debug need, but it's really challenging probe designing

Here it is ! You can download the last version of SAPHIR probes (I hope that the update will be available directly through VIPM next week).

The package contain the new probes presented in this post, with a few enhancement.

We've also added probe named Chronograph. As the one presented in this post by MikaelH, Chronograph probe allows you to measure time between it and any other SAPHIR probes.

It could be very useful for a quick code execution time checking.

Finally, we've tried to standardize every probes ui in order to have resizing capabilities and add "freeze" and "clear" graph button when it was necessary.

Hope you'll enjoy this new package. If so, feel free to leave a comment here.

Note about ui rendering on Windows Seven : Probes was originally designed on Windows XP. Using them on Windows 7, we've came across some ugly ui rendering following OS display settings.

You can see the worst example below :

History probe under XP : Same probe under 7 :

We've tried to mange it as best as we've can, feel free to give us feedback on this point.

Olivier.

saphir_lib_vibox_probes-1.2.0.18.vip

Those are pretty cool - the re-sizable array one is awesome. I really wish the NI probe did that by default.

What a nice compliment

Hi Olivier, I created a custom probe for my Queues a while ago. Please feel free to include it in your tool, if you see a fit. This especially helps while monitoring the execution of a consumer loop in a queued message handler. You can slow the execution down so you can actually read the queued messages. The code is pretty simple, but has helped me a lot. Message Queue Probe.vi

Thank you for sharing that. We also have this kind of probe. To package it, I'm wondering which type of queue we need to handle ? String and Variant cluster is essential, but is there other useful type that should be addressed by this kind of probe? I'd be curious to know developers opinion.

Olivier