jgcode

Bad bad bad jgcode. Bad!

San... Please disregard the any mention of the (signaling) property. This is something that is VASTLY abused and should be avoided at all costs. let me repeat, DON"T USE THE SIGNALING PROPERTY unless no other way of doing it.

Newbies use this methodology in excess and end up really regretting it down the line.

This tactic is not easily traceable, debuggable or extendable (going N+1)

Just look at some of the stock examples that come with LabVIEW for user events and dynamic events. Your effort will pay off 20 times easily in better code.

Long story short,

if you want reactive code to a user input, utilize an event structure to respond to that action.

If you want reactive code to a group or types of controls/indicators look into dynamic event registration

If you want code to react to programatically to different parts of programs (without user input) then look into user events.

and once again BAD JGCODE!

lol

First I totally agree with you that this can be bad as in using globals is bad. But everything has a place, and everyone is at different programming levels and knowledge levels, so I think depending on a per use case it needs this needs to be judged. So taking the topic into perspective:

Since I'm quite new in Labview

You think someone who has openly stated they are new to LabVIEW is going write beautiful code, first time, off the bat? Understanding dynamic events is hardly a basic level subject. Especially given they are unfamiliar with design patterns (also stated). I am by no means having a go here, just establishing an estimated LabVIEW experience level based on the facts posted.

So if someone starting out has a basic application, and the use of Val(Sign) property works and gets the job done, but they learn stuff along the way - is that such a bad thing?

I never stated to abuse it like a red headed step child, I stated a method that could achieve the result outlined in the original post.

Additionally I am of the opinion that it is not detrimental that somebody has knowledge of how the Value Signaling works. If they do not know it exists, or do not understand how it works, then how are they to know why its bad?

Programming is a journey (well at least for me), it is about finding stuff out, trying different things (can always skin a cat different ways). So telling someone to disregard the Val(Sign) property means discouragement from learning something and from trying it out for themselves. This in my opinion, is counter-productive to that journey.

Bad, bad, bad Norm.

Name: Rename LVOOP Labels

Submitter: jgcode

Submitted: 28 Nov 2009

File Updated: 30 Jan 2012

Category: LabVIEW Tools Network Certified

LabVIEW Version: 2009

License Type: BSD (Most common)

This package is Open Source

This package is a LAVA distribution - visit 'http://bit.ly/team_lava' to learn more about Team LAVA

Visit 'http://bit.ly/rename_lvoop_labels' for this package's support forum

This package contains a Plugin which renames a Class Member VI's Top Left and Top Right Connector Pane inputs to 'Class Name In' for control and 'Class Name Out' for indicator. Qualified Namespacing is ignored (i.e. parent Libraries). All VI control terminal labels are aligned left and indicator terminal labels right. Addtionally the Class icon will be refreshed. Use this Plugin e.g. after you have renamed a Class and you want to update it's labels or when you have cloned (Save As) a Class

This plugin was designed to be use with 'LVOOP templates' therefore, the following Connector Panes are supported:

4815 - 4x2x2x4

4833 - 5x3x3x5

4834 - 6x4x4x6

4835 - 8x6x6x8

Restart LabVIEW to refresh Menus after installation

Use the Tool Menu or NI Example Finder to view examples of how this tool works.

Tools Menu:

Plugins can be found under Tools>>LAVA>>Rename LVOOP Labels

'Rename Selected VI Only' - operates only on the selected VI

'Rename All VIs In Class' - operates on all VIs in the selected VI's Class

'Open Example' - demonstrates features of this tool

Quick Drop (QD):

Press Ctrl + Space to launch QD

The default hotkey for this plugin is 'Z'

'Ctrl + Z' - operates only on the selected VI

'Ctrl + Shift + Z' - operates on all VIs in the selected VI's Class

Help Menu:

Help can be found under Help>>LAVA>>Rename LVOOP Labels

Installation Locations (relative to LabVIEW directory):

'\vi.lib\addons\_LAVA\rename_lvoop_labels' - main code

'\project\LAVA\rename_lvoop_labels' - tools menu plugin code

'\resource\dialog\QuickDrop\plugins' - quick drop plugin code (z.vi)

'\help\LAVA\rename_lvoop_labels' - help menu plugin code

'\examples\LAVA\rename_lvoop_labels' - example code

'\examples\exbins' - .bin3 file

Click here to download this file

To be honest I'm not sure I understood what you are suggesting but I think it's similar to what jcarmody says. Anyway thanks for the links. I will look into them.

The example attached can fire an event for Control 1 using the control or another event, which makes use of the Value Signaling property node.

The counter will increment in the Control 1 Value Change Event case. Pressing either Control 1 or Progammactically Fire Control 1 Event will increment it. So anywhere in your code you can write to this property node to create a Control 1 Value Change Event.

It is just another way to programmatically fire an event. It is the same as doing it registering an User Event (as jcarmody has posted) albeit most likely a little easier to start with, but not as flexible.

Value Signaling.vi

[LabVIEW 8.2]

When I feel better, I'll try it.

I got swine flu apparently.

Dude, thats nasty!

I had the flu (swine?) bad this winter too, it sucks.

Wishing you a speedy recovery from the swine flu - hope you feel better soon!

Thanks for the reply. Since I'm quite new in Labview, could you explain a little bit more what to do with the property node? And also can you give me some more info about the other methods you propose?

Programmatically writing to a control, local variable, global variable, datasocket or a value property will not cause the Event Structure to fire a Value Change event.

One way to do this programmatically is to use the Value Change (Signalling) property node of a control. This will cause a Value Change event to fire in the Event Structure that has registered for this event.

If you search for design patterns you will get a lot of hits e.g.

• LAVA WIKI
  
• NI
  
• NI
  
• Darren's Nuggets
  
• JKI

Design patterns help you solve problems and stops you from having to reinvent the wheel.

I have now added support for when "Include Error Handling Terminals" is unselected and included my preferred default save names e.g. set<DataMemberName> (in camel notation). The VIPC file is now a list so the download is back to being small as well.

**********

This was a bit of a code and fix job, as I was exploring scripting and try things out. Everything works nonetheless so I figured it was worth posting. However, I plan on refactoring the code in order to neaten it up for the next release and have a few other ideas too.

Anyone got any feedback or suggestions?

They would be much appreciated.

Cheers

JG

I'll be damned.

If you can find that document, I'll be sure to read it. I remember seing something about that a while back but can't find it either. I'll start by browsing AQ's posts...

Thanks Jon,

Haha got it!

Thralled - thats the word I was having trouble remembering

I feel naughty every time I see a coercion dot on my block diagrams and try to get rid of them as often as possible. But there's one case for which I don't understand why there's a coercion dot in the first place: wiring an object to its ultimate ancestor, the LabVIEW object.

A child wired to its parent class method will not show the dot, but wiring any object to the LV object terminal will.

Would there be an instance when this is necessary to notify us we're about to use the inheritance in a potentially unintended way?

Hi François

Nothing sinister here, if the LabVIEW data member VI (dynamic or static) has its class input wired to it's class output then you will not see a coercion.

Otherwise you will see a coercion.

AQ made a post about this relationship recently in explaining some checking that occurs - I can't find the link yet - sorry! .

But you may find it an interesting read!

Here you go.

Ton

Ah, a picture speaks a thousand words - I understand now thanks.

Do you do this?

Darren has created a new group on ni.com for Quick Drop Euthusiasts.

Check it out, as he is discussing possible 2010 release ideas.

Cheers

I like the work you did, however I almost got my feelings hurt in another thread that suggested *gasp* that a State Machine should never have as many states as I use.

I'm thinking that I need to use sub-VIs rather than more sections in my State Machine. (Encapsulation?)

Thanks Jim

I used to be an enum/variant guy myself (I was exposed to my first LV State Machine in an NI course). And I was reluctant to use strings. I started using the JKI State Machine when it came out and after a while, I couldn't stop using it. When I combined this with encapsulation (in particular LVOOP), I started to make some really neat code (IMO ) that did, as you say, cut down the number of unnecessary states (and logic) due to encapsulation.

Is there an agreed maximum number of states before readability becomes a factor? I find I can still easily fill the State drop down menu list out of the screen for medium-large UI's - there is already quite a few states in the template to start with. For dialog boxes, and small UI's this is not such a problem, but for my main UI it does become harder to read, I find, by scrolling. I usually find states map to user functions (play, stop, pause) so that is ok, but I can have a lot of "UI" states. This are normally quite basic e.g. Set A, Get A, Set B, Get B etc.. Maybe I need to encapuslate the UI more with X-controls, but I don't know if that's the best work-time tradeoff if the UI is not going to be reusable? Do other people find encapsulating the UI using X-controls is worth the effort?

Another way is to push out UI commands via a queue to another loop. Benefits of this is that updates to the UI can be asynchronous and the UI can be abstracted from the main engine VI (if user inputs are also accounted for) but this limits sharing the statefullness of the original state machine which, IMO is one of the key benefits I get e.g. I can use more LVOOP and not worry about sharing data byRef with another loop (this makes me very happy).

[Thinking out loud] Maybe I have too many UI states because updates are not asynchronous... removing the UI states would serve to reduce the length of the State drop down menu which in turn may help with my readability hmmm.....

I'm not a big fan of the queued message handler to begin with. Throwing in nested states and substates gives me a headache just thinking about it.

Thanks Paul,

I thought it would be quite common for developers to use some type of queued messaging for a UI architecture?

If not, what design pattern do you prefer?

Please post (I love discussions on design patterns).

I'm not a fan of substates or nested states. I've gone down that road many years ago and came to the conclusion that it's simply too hard to work with. It makes the code harder to trace and debug. I had a colleague that swore by that technique. I hated working on his code.

If the code on the diagram is so complex that you need to break it down into nested states then I would consider using more subVIs instead. Makes the code easier to work with and debug.

Thanks Michael

I too, have met some people that swear by string based state machines as that can parse *anything* from a string (sub states, arguments, data etc..).

Cheers for the heads up on your experiences.

I have found, as mentioned above, that encapsulation has led to neater state machines.

When you talk about using more subVIs do you mean you would use encapsulated State Machines (in subVIs) over Sub States?

Positives I can think of is that they could be unit tested (so they are easier to debug) and make the main UI more readable.

I do try to use a Integration subVIs so I never use multiple states just because I have exceeded the BD size available within a state.

Or do you mean something else?

I could only think of a couple drawbacks:

• You can't see all the states in one glance (but, I guess if you have a great many states, you can't effectively do that, either)
• You can't easily move a substate from one category to another (for example, rename "UI: Open Control Panel" to "Control Panel: Open UI").

Thanks Jim

Your first point is the the first thing that came to mind that I was worried about - readability.

Although the design has parts that are already nested: (I though I few more would be ok )

- Idle (event) case is nested, but it does not lend it self to readability issue (at the end of the day it has to be there, but its readable).

- And I usually have to nest my menu handling (from the RTM) in the event structure as well. If it's complex though, that normally goes in a subVI though to help with readability.

And with your second, yes you would have to cut and paste instead of a nice "Rearrange Cases..."

While this may be avoided by good initial design, this would crop up again in maintenance - so you would loose some a lot of flexibility there as well.

You may also pass substates as parameters:

"State Name >> SubState Name"

Thanks Vugie

That is a great idea also.

Do you do this?

I was trying to keep all the original functionality of the JKI State Machine so if need I could still pass arguments as well as Sub States so the syntax is the same.

I was trying cause less confusion by not deviating too much from the original design.

Wouldn't it work to set the main state case to:

'---------------UI------------, UI: .. UI:z' ?

No need for an extra VI.

Thanks Ton

Are you able to elaborate? I do not think I am following (sorry!).

The owner is the "---------- UI ----------" case

Any Group of states registered as a Sub State will get sent here.

---------- Summary ----------

Summary: A poll would be nice to see who likes using Sub States and who doesn't.

Summary: Thanks to everyone who's posted so far for the great feedback!!

Summary: Please continue to post your feedback it has been very, very much appreciated.

Summary: I like to keep trying new things, so I will keep busy experimenting with this.

Cheers

JG

Hi

please anybody tell me some e-book for learning LabView as I'm new to Labview and I also dont have idea of Object oriented.

I've to make some application using labview

thanks

LabVIEW has great HELP documentation on LVOOP that ships with it.

That would be my first stop for electronic info.

Along with the white papers in NI's KB. Just do a search on their website.

Howdy, I wanted to post what I have been working on lately in order to get some feedback.

There has been some discussion about managing a large number of states in a state machine neatly.

Jim Carmody came up with this brilliant solution.

This particular implementation is also based on the JKI State Machine mainly due to the fact I now seem to be using it all the time (I have become addicted).

I have been working on modifying the architecture of the state machine to accommodate a large number of states by introducing sub states.

I also want to do it in such a way I can upgrade existing code quickly and easily.

If a group of states (e.g. UI) gets too large, I will move all UI states to their own case (owned by the separator case).

This seems to be neater and easy to read then having to scroll the state drop down menu when the number of states starts getting large.

Plus the states are all grouped, so it is quite natural for them to sit together (IMO) in an owner case.

The JKI Syntax lends itself really nicely to this. So I wrote a parser that is a wrapper for the JKI Parse State Queue.vi.

If no sub states are configured with the parser, then the VI behaves exactly the same as the JKI parser.

With respect to the state machine, everything else stays the same, so no code gets changed as such, just its location really.

I guess a disadvantage to this is readability from the point of view that I have now have increased the nesting of case structures.

But so far adding depth the the state drop down menu on the block diagram works fine.

I am sure other people have done this before, anyone care to discuss the advantages and disadvantages to such a design?

Cheers

JG

JKI State Machine with Sub States (LV8.2).zip

[LabVIEW 8.2]

Hi Athalia

As long as all functions and structures etc... used are available in 7.x then you should be able to.

I know you can't save for 7.x using 8.2.1, I don't know which is the first lower version that will work but 8.0 should be fine (maybe someone can confirm which it is?).

You will have to open the VI in LabVIEW 2009 first.

Then select File>>Save for Previous Version...

Then save it down to e.g. LabVIEW 8.0.

Then you will have to open the new VI in e.g. LabVIEW 8.0

Then select File>>Save for Previous Version... again to 7.x

I am pretty sure there is a network queue in the LAVA CR, or that someone posted that might be work a look too..

Hmmm...The menu suggestion makes me wonder. Does the menu have to be shown on the front panel to generate events using hot keys? My gut feel is yes but I really don't know.

Jason

Well...

...try it!!

Dear Ladies and Gentlemen,

I would like to use Short Cuts in my LV application, I found the Key Navigation with the Toggle function but there I can just use some Keys like F1... I would like to define actions for Short Cuts like Ctrl S Ctrl N ... .

If anyone as an idea, that would be great.

Mike.

Depending on what you are doing... one way would be to create a run time menu and assign shortcuts through there. See here for a start on creating a run time menu.

Congratulations mate, great job

Hello,

thanks a lot for the replies, it was really helpful. Now it seems I have many options (cFP, cRIO, FPGA PCI and std. PC), all I have to do is check what suits mostly.

Regards

No probs!

Hello All,

I am starting a project where deterministic real-time performance is obligatory. Unsurprisingly, we're on a tight budget too

What I wanna know is, should I stick to FPGA's for real-time applications, or is just using the real-time module to design an application that would run on any platform (M series PCI for instance) enough.

In the latter case, will running the code directly from PC hinder the real-time performance, or is it accessing a real-time processor on the PCI card.

P.S. Generally speaking, what makes a piece of HW real-time compatible or not !!

Thank you for your valuable response,

Omar

Like Ton said, M series is straight up a basic DAQ card

You can get PCI with FPGA but it is R series.

The code you write for the FPGA will run on the FPGA, meaning it will be deterministic.

There is no OS on the FGPA, the code is burned onto the chip.

I am pretty sure you will only need LabVIEW + the FGPA module to program the R Series card.

Depending on you specifications requirements you may find using a target with a RTOS is more flexible. E.g cFP or cRIO (which has FPGA as well).

I.e you cannot do floating point maths on FGPA. You can now do fixed point which is cool tho.

You would use the LabVIEW + the Real Time module to program the RTOS.

Well written code will be deterministic.

E.g. A standard PC running Windows OS is not a real time target. If you wanted to turn a PC into a RT target see here and here to check if your PC meets the requirements.

Hmmm.

Well the presentation I am referring to was given by Tom Bress at NI week 2009. It is titled

"From spaghetti code to State Machines: One Man's Journey through the NI Certification Process"

http://www.ni.com/niweek/summit_presentations.htm

Dan

Cheers I tried again and it worked so maybe it was busy last night?

This shows all the presentations - thanks for the link!

https://lumen.ni.com/nicif/us/niwkswdevtech/content.xhtml

Great work, jgcode! Thanks for sharing this.

My only complaint (I'm only joking, really) is that you're not using VI Tester

Cheers,

Thanks Jim much appreciate - and you guys as JKI inspired this one - so thank you too!

You will be happy to know I had to take out the UTF because I could create a dist with it in (I have to follow this up to check whether the error is a bug or not).

Anyways, I think VI Tester API will fit in there quite nicely.

I posted a response in the thread on the NI Forums...I think we should probably continue the conversation there since it has the entirety of the conversation.

-D

Thats Darren that makes sense. I am heading over there now...

jgcode: Does your customized version handle the new options in LV 2009 to not include the error terminals and case structure?

Hello AQ (thanks for putting the hooks in 2009 by the way )

Yes it does! and no it doesn't.

I didn't add support, but running the scripts tidies up the BD Labels but its not switching the connector pane for the arrays (obviously where its erroring out in the code).

Due to the style I use, I always have error in/out. But thats a great point and something I will add for the next release. I guess I should just check for error in / out terminals to determine type of template?? Is there a better way? Is that aa flag that is available somewhere? Are you able to comment on how you would support this?

Cheers for the feedback!

JG

I had to elaborate on this one in cross-post...

Hi tst

I will try to explain further and I will use JKI's VI Tester package as an example...

One of the component of VI Tester gets install in the Project Folder (aka Tools Pluign Menu) of LabVIEW.

I.e. <LabVIEW>\project\VI Tester folder contains VI Tester.txt, VI Tester.llb and New folder (containing NewTestCase.llb & NewTestSuite.llb)

VI Tester.txt contains the following text:

VI Tester Menu Launch__VI Tester Menu Launch.vi

New

Causing the Tools RTM looks as follows:

Therefore, LabVIEW, working with a plugin, is able to be pointed to a specific VI in an LLB through the text file.

Distributing code for a tool in an LLB is a nice way to include all dependencies for the developer.

Now with respect to Quick Drop - it would be great if I could distribute a LLB file and a txt file and Quick Drop can read the text file and know what top level VI to point to in the LLB should that shortcut get called.

So my question is - Is this possible at the moment?