hooovahh

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.

is pv.exe bundled with Windows? I cannot find it in my install (hence the reason why you embed it in the code I suppose).

 

Are you sure you are legally allowed to distribute pv.exe in any form?

 

Edit: sorry just followed the pv link you included above, so it's not a windows tool, but am still not sure about the distribution of this.

Yeah you are probably right.  I certainly wasn't trying to hide the fact that part of the code was not mine, and that it was part of a freeware application.  I actually found the download on a site somewhere as just an EXE download without any attribution or history of where it came from.  Still the whole two wrongs thing.

I tried for a long time to accomplish what this little EXE program does natively, or using VB calls but couldn't find any thing, just some possible ways to do it in C that I couldn't get to work.

For those not adventurous enough to run random EXEs off the internet, this EXE has many functions but the one I use is given a EXE name, it will provide the PID(s) for those running applications, and the full path on disk to their locations.  If you open Task Manager you can see the PID column for all applications, and you can right click and choose Open File Location.  This is the functions that I couldn't seem to do with DLL calls to Windows, or VB and .Net calls.

The installer doesn't put the ini into the [Public App Data]<Company Name><Application Name> folder, it just creates the folder and unlocks it.  If the folder already exists, then nothing happens and your custom ini file remains intact.  The default ini that is with the exe is overwritten, but since the ini already exists in the App Data folder, the ini with the exe is not used.

I wasn't talking about the App Data folder, I was talking about normal NI installers and how standard operation is for now with applications I make.  I was saying that normally someone would need to change the permissions on the INI file in the Program Files folder if the application is going to Read/Write it.  This was done using the command line program icacls but using the "unlock" on that INI file removes the extra step of having to run icacls but will still overwrite the INI (in Program Files)

I understand how you handle INI settings and I will try to use something similar in the future after some initial testing.

I don't use private methods often, and as a result I don't know what other methods are available.  When I do turn on private methods I find that there are a ton and they some times will slow down my development, because there are so many that I will not use 99% of the time.  For this reason I find myself enabling and disabling private methods and I wanted an easier way to turn them on and off.  I made this VI (and it's supporting code) to run from the Tools menu of LabVIEW (place in the <LabVIEW>Projects folder) which will change the LabVIEW.ini key, and then restart LabVIEW.

Disclaimer 1: Private methods are not supported by NI and should not be used in build applications, and are generally only used for tools of development.  

Disclaimer 2: This set of code contains an EXE (pv.exe) and will be saved and executed from the system temporary folder %temp%.  Information about this EXE can be found here.

Disclaimer 3: As stated in the main VI, this will taskkill the version of LabVIEW running, and all unsaved work will be lost.

Any feedback is appreciated, thanks.

EDIT: This code uses OpenG File Library.

Enable Disable Private Methods.zip

Sorry I can't edit my own post (too old) but for those having cross link issues like the one I mention, looking at the Files tab in a project explorer will quickly show any VIs not linking to the right files on disk so the tool I mentioned making isn't needed.

Occasionally I will be working on multiple projects that at one time split from each other.  Because of this there will be many VI with the same name in both projects.  To keep things simple I will only open one project at a time, but sometime I will do something stupid and have one project link incorrectly to the other projects VI.  A tool I've wanted to make is to open a ref to all VIs in memory, get their paths, and build a tree with a directory view of all VIs loaded.  This way I can see quickly which VIs are being called from where on disk.  This type of tool could take advantage of this private method because I don't care to load all other dependencies when I open my references.  I just need to know the path (and assume all the VIs are already in memory) that I want to scan.

This was my first thought also. This is an extremely handy method for performing VI server tasks on a single VI that don't require its static hierarchy to be loaded (psstt... this method can be orders of magnitude faster than Open VI Ref since, not only does it not load static dependencies, it does not load the owning library definition or sibling members).

It is very fast.  I did a test on it by having it find all VI recursively in a directory, then open each of them and read the Connector Pane Image, VI description, VI Controls and their descriptions.  Finding the VI files took longer than performing all the other operations.

EDIT: Actually I had a bug in my code the timing is not quite correct. On a directory containing 440 VIs (in sub folders too) it took 71ms to find all of them using the Recursive File List.  Then it took another 4.8s to open those 440 VI references.  The time to read the data was a bit flawed too but is on the order of 8-10 seconds.

I didn't know about the 'unlock' switch in the installer, so to get around the user access issues I was using the "icacls" command to set the user permissions. When the ini file is first created under ProgramData, I feed the command "cmd /c icacls "<path to ini file>" /grant BUILTINUsers:(F) /t" to "system exec.vi". This assigns all users full access to the ini file.

This works fine as far as I can tell, but I'm a bit nervous about using commands I don't really understand, so I might switch to the 'unlock' folder method instead when the issue with LV2012 is fixed.

I've used icacls before for setting permission as well (before I knew about the unlock feature).  What I did then was install like normal, and then I needed to remember to run the batch file to change INI permissions after the install.  Unlock removes this extra step but again will simply overwrite the INI during the install (which is where this topic came from in the first place)

Win 7 has some unexpected rules when it comes to the ProgramData folder, you can create and modify files (and folders) but if you switch users, they only have read access.  So for this I have my installer create the folder where I will be storing the modified ini (by creating a new destination [Public App Data]<Company Name><Application Name>), and set the folder to unlocked.

Awesome idea.  Yeah I was thinking about how all of this would work when switching users as well.  I have not run into this myself but apparently there is a bug with 2012 with the unlock that doesn't work properly.  Sounds like it is planned to be fixed in the next release

This code is still locked.  Your code was removed here previously because of this.  Either unlock the code or stop trying to submit it to the Code Repository.

What I'm doing right now can be considered non-standard.  The INI and EXE go into the Program Files folder, and the INI has been "unlocked" by the NI installer.  This makes it so anyone on the system has permission to write to it (but no other files).  I've known for a while that files under Program Files should not be changed after the installer because of user permissions issues and that the ProgramData is the correct place for this information.  To be more standard moving forward I think it would be a good idea to try what bmoyer suggested.  I can have the installer install into Program Files the EXE and INI and keep them locked to read-only.  Then settings are read from the ProgramData first.  If the file doesn't exist (or there is an error in reading the Section/Key) use the INI file in the Program Files.  Then when making changes save to ProgramData.

An added benefit I didn't think about with this approach is I can have a "Reset to Default" button that will simply delete the ProgramData INI file, causing the software to use the Program Files INI for settings.

Hello all.  I have an application.  This application has an installer.  During the install the EXE and the INI file are installed and the EXE uses the INI and can then write to the INI any settings changed in the application.  If I have a new version of the application I make a new version of the installer.  The problem (if it is one) is that during the install the new INI will replace the old one and all of the old settings will be lost.

On the one side this is a good thing.  This means that when version 2.0 is installed it comes with an INI file that is compatible with the 2.0 of the EXE and will have known good settings.  On the other side this means that if there were any custom settings they will be lost.  It is possible to run a EXE after an install, so I was thinking one possible solution could be to backup the old INI (sometime before deleting it) then after the install compare the two and any keys and sections that exist in the old and new INI, to be copied so the new INI has the same settings as the old.

Any thoughts on this?  Is this a non-issue and installing a new EXE with the new INI is the way to go, with the understanding that old INI settings will be lost?  Thanks.

Anyways, I reread my own post and I may be coming off as something of a doomsday preacher. Sorry about that to all of you!

No worries.  There are days where I come on here and probably say things out of emotion and say things I don't mean to try to get a point across.  Password protection, IP protection, and low level LabVIEW secrets on this forum have been a hot topic, and people are very opinionated, which makes for some topics which seem to add nothing to the greater knowledge that this forum is intended for.

I understand your position and feelings about IP and DRM.  I also understand what flarn wants to do, and to an extent what drives him in his pursuit of all that is LabVIEW secrets.  I too would like to know the dark secrets of LabVIEWs inner workings.  I'm always interested in what there is to learn when it comes to LabVIEW, but at some point you cross the line and for everyone that line is different.  Laws are intended to make that line the same but in many cases is still a grey area.  In my opinion stating that "we need a new password cracker" goes too far, but at the same time I did not know that in 2012 the password scheme was changed to counteract previous flaws.  And had it not been for this post I may have never known.

Man I'm all over the place with this post.  I congratulate anyone who understood the message I was trying to say.

- There is no difference whatsoever between intellectual property and physical property. If you can't see that then you just have to live a while longer and it will dawn on you eventually.

This is just silly.  Of course theres a difference.  If there was no difference we would use the same word to describe both types of property.  In the dictionary if you look up Intellectual Property it will not say "See Physical Property".

I also don't condone releasing anything to break NI's password protection scheme, but I also think it isn't in your place to say that he "WILL get into trouble" if anything is released.  What happened to the last guy that released a password cracker that works on all VIs between 7.x and 2011?  Well I don't know for sure but his website is still up with the source code, and will even remove the password by uploading a VI.

You weren't going mad. I got it too on all the threads so I couldn't post that there was a problem

It was kinda funny because I could see new posts, and my RSS showed new topics, but you couldn't go to the thread.

Sorry you made a duplicate topic here and I replied in any case here is what I posted:

I've attached my go at it.  This uses two OpenG VIs Remove Duplicates and Search Array.  Install the OpenG Array package to get these VIs.

 Average Rows Same First Column Hooovahh.vi   9.06K  29 Number of downloads

It doesn't look like your attached any code.  Yesterday there was some LAVA issues so this maybe this is to blame.  In either case I've attached my go at it.  This uses two OpenG VIs Remove Duplicates and Search Array.  Install the OpenG Array package to get these VIs.

Average Rows Same First Column Hooovahh.vi

Not the answer I was hoping for, but I'm not surprised.  As tempting as it may be I will try to stay away from XNodes, and stick with 100 polymorphic instances, and OpenG code that can't adapt to every thing I need.

Sometimes Ctrl+. helps. And you can almost always close the parent vi using the task bar context menu and it will terminate the blocking sub vi.

This won't work if the SubVI isn't being called in the code yet and is just in memory.  I believe this is the situation Minh was describing.  I've used several AbortVI functions in the past to be able to abort any VI running (not a close at the moment).