jgcode

Thanks for yours acknowledgements.

You are welcome!

After few tests, i have find a solution to break arrow issue. In fact it's arround default case. You just need to redefine it and the arrow isn't break. see my solution in the red box below.

Eric this is great (and thanks for posting too Shaun)

I have found you only need less code, but the principle is the same: toggle the default case.

Does this work for you?

Now that the broken run arrow is no longer an issue I have uploaded a fix: version 1.1.

Here is the video (it got mundged with the starting post was automatically updated) - but now the run arrow issue is fixed.

<object id="scPlayer" class="embeddedObject" width="1122" height="876" type="application/x-shockwave-flash" data="http://content.screencast.com/users/jgcode/folders/LAVA%20CR/media/c275b677-922c-42b8-a699-ce4c1b7bd0bb/jingswfplayer.swf"> <param name="movie" value="http://content.screencast.com/users/jgcode/folders/LAVA%20CR/media/c275b677-922c-42b8-a699-ce4c1b7bd0bb/jingswfplayer.swf"> <param name="quality" value="high"> <param name="bgcolor" value="#FFFFFF"> <param name="flashVars" value="thumb=http://content.screencast.com/users/jgcode/folders/LAVA%20CR/media/c275b677-922c-42b8-a699-ce4c1b7bd0bb/FirstFrame.jpg&containerwidth=1122&containerheight=876&content=http://content.screencast.com/users/jgcode/folders/LAVA%20CR/media/c275b677-922c-42b8-a699-ce4c1b7bd0bb/Insert%20State%20Into%20JKI%20State%20Machine.swf&blurover=false"> <param name="allowFullScreen" value="true"> <param name="scale" value="showall"> <param name="allowScriptAccess" value="always"> <param name="base" value="http://content.screencast.com/users/jgcode/folders/LAVA%20CR/media/c275b677-922c-42b8-a699-ce4c1b7bd0bb/"> </object>

Hi Jonathon

Few days ago,I have propose similar tools on JKI Forum Here . Have you see it ? It's really near your tool but run like JKI RCF PlugIn.

Like you, i have find same issue arround break arrow. Certainly a scripting issue. Perhapse solve in LV2010 ?

My solution is to save automaticaly the vi before quit tool.( only possible if the vi is all ready save on hard drive)

Eric

Hi Eric

I certainly have been following your work (and with Ton too).

In fact, in the readme above you will see I included you in the acknowledgements (and made a mention in video).

I did see your code where you save the VI but I did not want to do that in this case, or handle new-VI (unsaved) case.

The reason for this tool was that I wanted to speed up my workflow when I insert a state.

This was probably the thing that takes me the longest to do.

Do you have any ideas in mind for other tools with respect to JKI State Machine?

Cheers

-Jon

Norm - this is really cool.

I think this part of the last video really hits home and defines the benefits of this design pattern, highlighting why using strings would cause an epic fail.

I agree with Shaun in that strings are generally easier to read than integers in a Case Select, but in this case it doesn't really matter - the benefits are huge (you get some readability from the casted type anyways).

I can see the benefit of this straight away esp for scripting, and will be adding this to my templates folder.

Thanks for posting!

I considered this one of the more promising features of LabVIEW 2010, since we have large collections of reusable code that we realized we needed to put into project libraries. It would additionally be helpful indeed to build each piece only once (per change), which was the promise of the packed project libraries.

The first time I heard mention of PPLs (beta), I thought it would be a cool way to distribute my general reusable component code, exposing only the public VIs and having everything that is private, hidden and locked away.

However (as Jim pointed out to me then), as you are compiling the PPL for a specific target and LV version, so it is not (general) reusable friendly.

Therefore, I see the PPL being used within an single platform Application to speed up the build time and compliment the changes to the compiler that now result in a greater build time.

So reuse in an Application context, not in a general context would be a role.

I can also see benefits of it with RT, i.e. downloaded one file, instead of many.

However, I have not dived deep into this feature yet (we am still on LV2009 anyways) but am interested to hear other user experiences.

Name: Insert State Into JKI State Machine (Quick Drop Plugin)

Submitter: jgcode

Submitted: 11 Sep 2010

File Updated: 03 Jan 2011

Category: Quick Drop Plugins

LabVIEW Version: 2009

License Type: BSD (Most common)

Insert State Into JKI State Machine v1.3-1

Copyright © 2010, Jonathon Green; JGCODE

All rights reserved.

Author: Jonathon Green

LAVA Name: jgcode

Contact Info: Contact via PM on lavag.org

LabVIEW Versions:

LabVIEW 2009

Dependencies:

No Dependencies

Description:

Contains a Quick Drop Plugin Tool Menu Item which adds a State to a JKI State Machine. This tool will allow you to create either a new state in a section or a complete new section whilst automatically handling the template's syntax. If a new state is selected then it is added after the current visible state and the current section's frame is used as the template frame. If a new section is added it is added after the current visible section and the Core frame is used as the template frame. Correct Syntax (e.g. proper name, single spaces) are forced but can be overriden (e.g. to achieve capitalisation) using a period "." at the end of the text entry.

This package will install the quick drop plugin to LabVIEW\resource\dialog\QuickDrop\plugins and the tool menu item to LabVIEW\project\JGCODE ToolsSupport files are installed at vi.lib\addons\_JGCODE Toolkits\insert_state_into_jki_state_machine. See here to learn more about creating your own keyboard shortcuts using Quick Drop Plugins.

Note: This tool assumes that the template structure of the JKI State Machine will not be altered in any way.

Installation and Instructions:

Install package using VIPM.

*Ensure that the j.vi does not already exist as a quick drop plugin, if so you will have to manual manipulate the install.

If dependencies exist, then install provided .vipc file.

If the VI contains only one JKI State Machine then just run the plugin otherwise, use the mouse to select the case structure you want to manipulate.

Quick Drop:

Press Ctrl + Space to activate Quick Drop on this VI

Enter the name of the State in the Quick Drop Combo Box

Press Ctrl + J to create a new State

Or

Press Ctrl + Shift + J to create a new Section

Tool Menu:

Select the item from the menu

Enter the name of the State and check whether to create a new State or new Section

Press Ok

Undo is supported with the plugin.

Examples:

No Examples supplied

Known Issues:

No Known Issues

Acknowledgements:

Darren Nattinger

Eric BOBILLIER and Ton Plomp

Version History (Changelist):

1.3-1 2010 09 30

Added (): Quick Drop combobox can force syntax and non-capitialisation. Names are now checked for correct syntax, including proper case and single spaces between words and no whitespace either side.

1.1-1 2010 09 13

Fixed (): Fixed broken run arrow issue. Thanks to Eric BOBILLIER for finding and posting the workaround.

1.0-1 2010 09 11

Added (): Initial release of the code (LabVIEW 2009)

License:

BSD (http://opensource.or...bsd-license.php)

Copyright © 2010, JGCODE

All rights reserved.

Redistribution and use in source and binary forms, with or without

modification, are permitted provided that the following conditions are met:

* Redistributions of source code must retain the above copyright

notice, this list of conditions and the following disclaimer.

* Redistributions in binary form must reproduce the above copyright

notice, this list of conditions and the following disclaimer in the

documentation and/or other materials provided with the distribution.

* Neither the name of JGCODE nor the

names of its contributors may be used to endorse or promote products

derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY JGCODE ''AS IS'' AND ANY

EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED

WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE

DISCLAIMED. IN NO EVENT SHALL JONATHON GREEN BE LIABLE FOR ANY

DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES

(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;

LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND

ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT

(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS

SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Support:

If you have any problems with this code or want to suggest features:

please go to lavag.org and Navigate to LAVA > Resources > Code Repository (Certified) and search for the Insert State Into JKI State Machine support page.

Distribution:

This code was downloaded from the LAVA Code Repository found at lavag.org

Click here to download this file

I'm in the same boat as jgcode so I'll have to create 3 more accounts and hire a medium

Do you want to be friends?

Basically all the ideas implemented are 'low hanging fruit', I would be ashamed to name those new 'changes' as the major upgrade feature (as NI is currently doing).

I agree, that they should not sold as major upgrades. (unless warranted).

But I don't think NI was promoting the 2010 release as: individual ideas = individual major features.

IMHO the major feature was the Idea Exchange itself and how NI has a strong (web based) mechanism in place for collecting customer feedback that is cycled into the product releases.

The new changes were just evidence of this.

At the end of the day, we (the customers) voted for (most of) those features - democratically speaking.

I read your presentation. Unfortunately you may have forgoten to put the power supply presentation's example available for download.

[cross-posted to jki-forums]

... Make peace with your enemies. Call your mother....

lol

(I called my mom and she said "Hi!")

Thanks guys.

We did an install of 6.1 into a VM and it did install the goop library.

So we will give a copy of this to the client to try.

Don't know what version they have yet (basic and .x), but hopefully this works.

Does anyone know off the top of their heads if: _goopsup.llb is standard in LabVIEW 6.x?

It say in the wiki it is, but I have a customer who have said they have installed LabVIEW 6.x and these VIs are missing.

Could it be in some toolkit that has not been installed?

If anyone knows that would be handy... ...digging around thru old disks now

Cheers

JG

platform to utility in vi.lib (8.0 or later) but was it an extra install back in 6.x?]

This is old....

....school

Every time I read the title of this thread, all I can think is, "We can't even standardize on how to spell standardise."

Hey! Don't nock the English language!

I'm curious, what do you think of my particular approach for solving the problem?

I like the idea - well any/all new ideas! (and I have not seen that posted before).

I have not tried it - but my only concern off the top of my head would be: what happens if you wanted to call two namespaced VIs that have the same disk name - and you forced them to compile into the root?

I am guessing that would cause a clash and one would automatically get bumped somewhere else - then how do you find it?

The 9.x can change a lot so I try to avoid messing with it i.e. if you call VIs outside your project, but not a symbolic path i.e. on C and D drive (not that anyone with any experience would do) I am pretty sure another layer gets added.

IMHO I have found use the static ref as a method to point to VIs is much easier, plus I don't have to handle src vs dist path differences in my code.

Not that fond of the brand, but I thought this was a great Australian ad.

Hope people get it?!?

<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=whjNr-hjr7E?fs=1&hl=en_US"><param'>http://www.youtube.com/watch?v=whjNr-hjr7E?fs=1&hl=en_US"><param name="allowFullScreen" value="true"><param name="allowscriptaccess" value="always"><embed src="http://www.youtube.com/watch?v=whjNr-hjr7E?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></object>

I talked to Jervin: NI had let their package repository license expire so the LabVIEW Tools Network was down for a short while - should be all good now.

Ok, cheers, musta got unlucky (bad timing).

But my problem involved accessing a VI within an executable that is running as an ActiveX server by a separately running VI (not a different VI within the application). I don't see how either of those methods will work.

As you can see from that post I was replying to the first part of your post regarding changes in the 9.x build model.

For your specific use case - you could still use this method by implementing a launcher VI as Shaun mentioned - you only need to know the location of one VI relative to the main VI - but it then it knows all the paths that you need in your build using Static VI refs.

Everyone of course is free to use their own company name (or given name) as a category which goes without saying. But I'm saying it anyway.

However a nice guideline would be to use the LAVA category as the main category and then you can put your branded category as a sub-palette of that if you like.

The LAVA brand means something. We have an approval process and as time goes on we will be tightening this slightly. Possibly incorporating some of the LabVIEW Tools Network requirements as they apply to us. Being able to package your stuff and get approval to put your code underneath a LAVA palette category is special and is something everyone should be trying to do. Let's all keep working on moving forward.

I really like the sounds of that! (as per my post above):

IMO, I don't think all submissions need this, but my idea is that LAVA should have another level of certification.

A higher level whereby releases would implement the above naming schema, and the code would be more tight and (kinda like NI's Add-on Developer levels) etc...

I would love to see that.

I finally took the CLD exam at NI Week 2010... and passed. Yeepee!

A big thanks to all LAVAs for keeping me up to date in my programming style and best practices.

Well done mate

I have no problem opening VIPM at the moment.

When do you get the popup, at startup or...?

/J

Was at startup.

All good now? (which is good)

Thanks for checking

Anyone else getting this popup in VIPM at the mo?

JKI Support forums are down for upgrades - don't know if it is related or not?

Cheers

-JG

What does the online help say?

No love from LabVIEW Help on that question.

The LabVIEW shipping example does not close any references, so that didn't give me a hint either way too.

That's realy cool!

It is a good idea to upload the sharing controls to code repositry.

It certainly is!

You mean here as in LAVA?

Make sure you look here too: UI Tools (and associated expansion packs) from François Normandin.

Can anyone care to provide a fast method to scan the Date & Time string in column # 3 in the attached VI into a 1-D array of LabVIEW Date & Time data type?

I have several methods to do this but I think that there must be a much faster one out there.

Maybe it would be helpful for you to post up your methods (that you mention above) too?

Quick question: How important is performance to your use case? (given, that you have already have an implementation(s) to parse the data and solve the problem?)