hooovahh

Well a few links that I'm sure you've already seen.

Ben's Docking example 

Dynapanels

tst array of subpanels

Snap off windows

Messing Around with Splitters (can't seem to find source)

By combining all of these you can get some neat UI functions.  I've tested a few UI techniques and you can get some very nice flowing applications.  I think what you are trying to do is very possible but will take some time ironing out the kinks.  The things I've done with it were not as feature complete as what you are proposing.  One thing to keep in mind is it maybe a good place for some OO code.  You might be able to make new instances of a classes and then override the class with functions for the specific UI element.  This could be an architecture where there are instructions on how to make your own UI elements that can be plugged in and used.

I used VMWare and actually liked it more than VPC.  VMWare also supports sharing USB devices, so I could share NI USB DAQ devices to my virtual PC and it could be used.  I think VPC has some support for this now but I think it only works with USB storage devices.  There is a performance hit for sure but it wasn't too bad, especially with a fresh Windows image. VMWare also supported 64-bit Windows as the guest OS, and multicore. 

Has anyone with Developer Suite SSP received DVDs yet with Labview 2012 SP1 on it?

 

Thanks. --Joe

I have.  I'm not sure when I got it though because I just downloaded SP1 when it come out, and just recently noticed a pack of DVDs with the SP1 release.

As a matter of fact there is an API to access the Lithium data, but you would have to be some kind of geek to be using that to analyze trends on the idea exchange.

If such a geek did exist, I am pretty sure he would tell you that projections have my idea ahead of yours 180.12 to 151.66 after two years time. Of course that geek's predictions tend to be better when the tail is not disturbed too much.

That geek would probably also be very happy if the property node idea were implemented. In fact, I am pretty sure he would think it is a great idea.

...

(but seriously cool)

Couple things.  I downloaded the zip and all that was in it was a text file with some strange characters, no code.

What you maybe talking about is the VI needs to have the compiled code in the .vi file for it to be dynamically loaded.  If you go to the VI properties under the General section there is a check box for "Separate compiled code from source file" you want this off, or else it won't be able to be dynamically called.  Not sure what version this feature was added (around 2009) but if the checkbox isn't there you can't separate the compiled code so there is no issue.

resourcedialogQuickDropplugins

http://labviewartisan.blogspot.com/2010/08/improvements-to-quick-drop-keyboard.html

Thanks for reply, but i don't want to use event I want to enable and disable of column index of 2D array.

Please see below attached imageArray Collumn enable disable.jpg

Each element of an array has the same properties.  Therefore you cannot disable some elements of an array using properties, you must disable all of them or enable all of them.  Is there something wrong with using an event to programatically disable them?

The main reasons are probably cleanliness, code safety and efficiency. A variant will cause a data copy, which is not a big deal if you're comparing a boolean, but could be an issue if it's an array with 10M elements. If you also make all your VIs work only with variants, then you will either start getting variants in the BD or the user will be forced to repeatedly convert back (and possibly make mistakes).

My intend was on the read to have a polymorphic VI for each type (variant being one of them) which performs the Variant to Data back to what is needed.  I only was curious about replacing all of the writes with one Variant VI.  I can't do the reverse because there's no way of changing a control at run time to the type needed.

In the end, if you create a tool which will be reused many times, it takes considerably less effort to make it easy to use upfront than it does to make it simple to build. If you create an automated tool to help with the polyVI creation, then the effort becomes even more minimal.

I did do this to make life a little easier.  I create the polymorphic instances programatically, but not the polymorphic VI itself.  I come to hate the polymorphic VI editor more and more with usability issues that make it slow to work with.

The real thing we need here is for LV to be able to automatically adapt VIs to work based on input type. NI has known this for years, but so far hasn't managed to come up with a stable and reliable mechanism. Hopefully at some point they will and then we won't have to deal with this any more.

Yeah I know, I can't wait to see the solution to this (sounds like not until 2015 or later).  

I couldn't find a "Reuse Discussion" section so sorry if this could be in a better category.  

Lets say I have a reuse VI.  It does some stuff with data that is passed in but the type of the data doesn't matter so I make it a Variant.  Now this is sorta generic where I can use this with any data type, but there will be a "dirty dot" showing that a data type conversion took place whenever I use it with a data type other than a variant.  The more correct way to do this is to create a polymorphic VI, with a VI type for as many data types as I think will be used (string, boolean, VI Ref, path, numerics etc).  Then when this is used it will call the same Variant VI but with a "To Variant" primitive before calling the variant version.

My question is this.  Is all of this necessary?  If I create a VI that works with a Variant, do I really need to make types for all of them that simply have the explicit "To Data" conversion instead of just using the variant version that does the conversion it self.

One example I see of this is the "Data Changed?" VI from OpenG under the comparison pallet. This VI will work with any data type, and its default is a variant.  So why did OpenG go through the trouble of making a version that works with 40+ other data types?  In this example OpenG did not call the variant version but instead made one version for each data type, but I see the benefit of all other types just calling the Variant version.  This way if I make an update I just have to update the variant version and all others call that.  Otherwise any code update to one polymorphic types, means updating all other types.

Create an event for the "Mouse Down?" on the array control.  Then use the VI here to get the index that the mouse is on based the coordinates of the mouse.  Then if the column equals the value you want to not allow the user to edit, then send a TRUE to the "Discard?" terminal (all of this within the same "Mouse Down?" event).

I tried making a VI to show you but for some reason I can't download the VI from Lava.  There's been some minor database issues around here lately so I hope when you read this you are able to get the VI.

EDIT: I believe this is the same VI on NI's forums.

Probably you could also try HELPer from http://vigods.com/toolkits/HELPer/helper.html. It's NI certified toolkit for doing exactly what you want. And arguably, with much less fuss over it than in mentioned above solution. Just try it.

This doesn't appear to be "exactly" what was asked for.  The tool you linked to does not generate CHM files at all (correct me if I'm wrong) it only makes HTML help files.

Nope. Don't know you or what your real name is (a hoover is a vacuum cleaner over here and in everyday usage). It was, and always will be a typo (apologies).

 

My handle, however, IS my real name. (I don't care how you spell it and even I get it wrong sometimes whilst typing. Luckily I rarely refer to myself in the third person )

Oh my apologies.  A Hoover is a vacuum in the states as well.  However when I say my name is Hoover people some times ask "How do you spell that, like the vacuum?" I say "No like the president".

Yup.

What hoover said.

 

read.vi

Sorry if this is off topic but this is the second time you have called me by my name (sorta) do I know you?  How do you know me by my name?  And not that it bothers me but could you please refer to me as "hooovahh" (or hoovah if you don't count the correct number of letters) other members may only know me by my alias and I think it was be easier if we referred to each other by our internet names.

The "Data Type" terminal in the read defines what the data type out will be.  You wired a constant of a string with the value of 0.  This tells the read VI that the data in the file is a string.  You should wire your cluster to the data type terminal, then the output will be that cluster.

EDIT: Also if you wire a -1 to the count terminal it read the whole file.  When I ran you VI it gave an end of file error so they way you were calculating the remaining bytes was incorrect.

You can just go to the source:

 

..LabVIEW xxxxvi.libAdvancedStringCommand Line String To Path.vi

I (incorrectly) assumed it was a primitive because of the icon, thanks. 

The way I resolved a similar issue was to use the "Path to Command Line String.vi" (which isn't on the palettes) rather than path to string then hacking the string. It seems to work on all platforms.

 

path2string.png

 

You can then just use all the path primitives (e.g. strip and build) to traverse the path without worrying about the underlying format.

I've never heard of this primitive before, but I couldn't get your snippet to work.  I tried in 2012 SP1 but it just added it as an image (I first saved it to my PC locally then dragged it to the BD).  I opened the file in a PNG editor and I couldn't find the VI data inside.  Would you mind posting a VI file with that primitive in it? 

Just for completeness I'll add another way to achieve this using dynapanels originally posted here.  With this method you can have independent properties on each graph/chart, and you aren't limited to an arbitrary number of VIs (64 in Yair's example).  

This can't be done the way you described it.  Every item in an array has the same data for all properties, only the value can change based on each item.  That being said you can achieve the same look by creating an array of clusters, where the two items in the cluster is a string (with transparent borders) and a slider.  Then you can bundle the name and the value.

Attached is an example of what I'm saying save in 2011.

Array Signal Example.vi

I always heard that using Variants Attributes as lookup tables was the fastest way to achieve this.  AQ has mentioned how dramatic performance increases have taken place in 2009 and earlier to make searching and retrieving data using Variants.  Here are a few links.

https://decibel.ni.com/content/groups/large-labview-application-development/blog/2012/09/04/using-variant-attributes-for-high-performance-lookup-tables

http://forums.ni.com/t5/LabVIEW/Darren-s-Weekly-Nugget-10-09-2006/td-p/425269

http://zone.ni.com/devzone/cda/pub/p/id/1495

I guess my question is why do you ask the Power Supply for its state?  Why don't you just have the power supply announce any state changes?  

Because Power Supply (and all other Actors) are Idle. (with a few exceptions)  They can be doing work every timeout but I'd rather they only perform task when needed, this cuts down on processing.  I can have hundreds of Actors all of which are idle, not polling anything.  Also I don't see the benefit from broadcasting my power supply status constantly when I may only want it at the end of a test (to see that it is still stable).  If I want PSU voltage for a UI element I can tell it to do it's thing periodically and push it to a VIG but rarely do I do this because I don't know how hold this data is.  If I request the data and wait for the reply I know that the data I got was from the operation just performed.  

What you are describing sounds like a Publisher/Subscriber paradigm, Is this how the Actor Framework works?  I assumed (from what little I've seen) that it was command/response using user events and queues.

I feel like these conversations are beneficial, but difficult to digest some times.  We all talk about what we do and how we do it, but it takes alot more time to put into text what we are trying to say and, concepts we are trying to share.  This tends to makes posts long and it doesn't take long to fall behind in the conversation.  Oh and I do like the idea of a Shutdown Actor but I haven't needed on yet.

Messaging systems don't need those features any more than a person without a car needs car insurance.  

No you are right, I didn't mean you need it as in it is a requirement, I meant it as you will would need it to prevent a dead lock, if nothing else was done.  The other suggestion I had (about knowing when a shutdown has occurred) was my preferred method.

Synchronous messaging (blocking one thread while waiting for another thread to respond) is rarely a good idea.

If this is true then I don't belong in this conversation.  I'd say the majority of my messages have a reply that a Actor will wait for.  When I ask my Power Supply Actor for the current state I wait for it to tell me the current state before moving on.  When I ask the DAQ to take a measurement I wait to get the value back before asking for the next value.  When I tell the Sequencer to "Start Test" I don't wait for a reply.

Okay yeah, I can see why you wouldn't want to take the time to implement it.

That being said I still think it would be a fun experiment.  Implement this with some OO or a DVR and have a central place with all states.  I already have something similar for the Actor messages.  I have an Actor that will intercept all messages between actors (along with the data send/received) and then I can display it using the handy Variant Probe.  Then during debug I can turn this on and can see at a higher level what is happening.  This is only turned on during debugging because it is not a circular buffer and could grown forever.  I've been meaning to fix that at some point.

I understand what you're saying, but I would rephrase it and say your messaging protocol needs to be designed appropriately.  Messaging system implies (to me) a framework for sending messages, like LapDog.Messaging, JAMA, or the messaging aspect of the AF.  The messaging protocol is the series of messages your actors exchange to communicate important information.

I explicitly avoided saying Actor throughout my post because not all of us use the Actor Frame work, and one could design the messaging framework in the way I described...and some of us have.

Some applications benefit from being able to dynamically invoke and destroy actors. 

In my experiences I've never needed to completely destroy a loop, just call the cleanup and init.  So I may have my logger close what it is doing and re-read settings but it is always running and listening for other "Actors" to respond to.

Error handling (and your entire messaging protocol, really) is simplified if you use an event-based messaging protocol.  In other words, instead of the DAQ asking the logger for information the logger automatically sends information to the DAQ when an event of interest occurs.

My example was a little simplistic.  Lets try this instead, a Sequencing Actor calls a DAQ Actor to read some values, the DAQ Actor reads the values then sends them back to the Sequencing Actor with any error that may have happened in the read.  I was trying to say that if shutdown happens the DAQ may shutdown, but my call from Sequencing to DAQ will wait forever waiting for the DAQ to reply with the data it requested.  Previously I used DAQ and Logging in my example but this makes less sense because I couldn't imagine a time when the DAQ would call Logging and want a reply.

I handle these kinds of conveniences using a generic DebugMessage with a string payload.  Status messages that are not critical to system operation but would be helpful during development are wrapped in a DebugMessage and sent up the chain.  All DebugMessages get routed to an actor where the payload is extracted and added to a string indicator.  Sometime the actor is application's UI, sometimes it is a separate debug window.  In my systems the overhead to implement it is minimal.

I like this idea but I would want all states transitioned.  So I can see what cases in my state machine, in each Actor went where, then where then where etc.  This then can give a very detailed view of what states my Actor went to and usually tell me why based on decisions that could have made it do those cases.  This central location of states and Actors would need to be a circular buffer of some kind, or possibly logged to TDMS and overwritten, or even just turned on manually.  This could open up all kinds of debugging tools.  Imagine if the User of my software has a bug that is reproducible   I could say turn on this checkbox then make the bug happen.  Then this one file could show all the states all actors went to, and with that I can very quickly narrow down what is happening.

I have done this in the past when I expect an error by using the History Probe.  Here I will probe the states wire (assuming I use strings as my state) and this probe will show all states that were executed by the Actor.  Of course this only works when running in source, but with a State Transition Actor I could use this in an EXE.

I'm not sure if this helps or muddies the waters.  One thing to think about is lets say you have your shutdown message is sent, and your logging part shuts down, but it shuts down, before the DAQ part finishes.  The DAQ part could send a message to the logging part waiting for a reply (not sure what kind of message DAQ would wait for a reply for but this is an example)  Your DAQ code could wait forever for your logging part to reply and it never will because it has already shutdown.  For this reason your messaging system either needs a long timeout in case something goes wrong so you don't wait forever, or have your messaging system be aware of the shutdown messages, and reply to messages that need replies saying to perform the shutdown, without needing the logging part of the code to be running.

This brings up another opinion of mine, and that is that separate running parts of code should never shutdown, unless they all shutdown.  So say there was an error in logging and you ran clean up, and this caused the logging code to close and stop.  Now we have the same problem as before where DAQ may ask for something from the logging code and it will never see a reply.  I've seen in the past were an error would kill some code, but you need to remember other parts of the code may need it to reply or receive messages.

EDIT: Also in my setup each parallel process handles its own errors if the error was not generated by another caller.  So DAQ asks logger for something that generates an error, this causes logger to send the error back to DAQ where the error is handled.  If logger generated an error on its own it will handle its own error (it has no place to send it).  Having a central error system is a novel idea but I too would be worried about system slow down.  In my setup any part of the code that will run often should be as streamline as possible.  So the messaging system is very minimal because I expect messages to happen all the time.  I've also thought about having a central location to keep track of states transitioned in each parallel process.  This has alot of benefit when it comes to debugging errors but again I haven't done it yet due to the overhead involved. 

hooovah, you can get the PID by running "tasklist" from the command line, then just processing the stdout...

 

no idea how you get the full path though, other than using the Win32 API

 

ok try this from a command line: wmic process where name="labview.exe"

 

it returns a whole bunch of guff, but the full path to the executable is in there

Awesome.  I modified the command a little to just get the ExecutablePath and ProcessID

wmic process where name="labview.exe" get ExecutablePath,ProcessId

Processing this will be no problem thanks again.

I do however have a new issue.  So I modified my VI be like Phillip showed, and it works when I run the VI, but if I run from the Tools Menu I get "LabVIEW:  Configuration token not found." I believe this is because from the Tools Menu I have a new Application which for some reason doesn't like that function (possibly a limitation of the private method).  I can get the "App.MenuLaunchApp" which will return the application reference that called it and then use that for modifying the key and restarting.  This works as long as I run it from the Tools Menu in an existing VI.  If I try from the Getting Started, this reference is also blank.  I tried opening a new application instance, with the port settings but this also returns the same error.  If I try debugging it then it works.  I must be going crazy over such a simple function.

Enable-Disable Private Methods Phillip Suggestion.vi

All unsaved will be what?!?! Don't leave me hangin'!

I noticed that string got cut off after I posted it but meh this isn't the CR.

You can set the INI variable and restart LabVIEW using two Invoke Nodes. You will have to confirm "Quit will abort all running VIs" and it should start back up with the correct setting.

 

(LV 2012)

 

Change SuperSecret Setting.png

Again goes to show the Private methods I'm unfamiliar with.

Even so I tested your code and it does have that dialog about quitting VIs which is nice.  It does give the user a chance to save any VIs they have instead of killing it.  I would like to point out that my method does takes half the time to perform the goal then yours...of course half in my test meant I saved an extra 5 seconds.  In the future I will be using your version because it is less likely to cause lost development work.

no idea how you get the full path though, other than using the Win32 API

That's the part I couldn't figure out.  How to go from PID --> Full Path.