Grampa_of_Oliva_n_Eden

I am still curious to hear more about what you feel makes a hero a hero and how or if an engineer or scientist can achieve that status. But on a somewhat related idea...

I have often mentioned to my buddies

"Anyone can casue a problem, but for a disaster, there as to be an engineer."

Ben

Thanks, everybody, for all the feedback. Everything is pretty much along the lines of what I already suspected, but it's good to see the discussion.

We've been discussing this internally at JKI, too, and I've sort of come to the following take-home points:

• Good code always beats bad code (this is obvious, and yes, I ruled this out in the original question, on purpose)
• A faster computer will definitely help in the case I specified. Also, more RAM never hurt anyone.
• Being careful about transparency and tab controls (especially nested ones) will probably help, too.
• A powerful graphics card will probably not change things much.

On that last point.

I suspect that very little of LV graphics can take advantage of the accelerator on high-end graphics cards.

The New 3D picture may be the exception. I am getting good response from it and have not totally ruled out (yet) including the 3D graphics as a realtime update.

So if the app is using the 3D picture, a good graphics card may pay off.

Ben

...UI thread is single threaded. ...

Ben

I'd like to add an outlandish statement re: the UI thread.

THe UI thread is over-used. It is now ime for NI to seriously consider getting all GUI updates out of the UI thread so that they can happen in parallel. It was a clever move when first implemented but the time has come to fix the UI Bottleneck.

Ben

I'm confused by this suggestion... hiding the front panel (which is where the graph is being drawn) would kind of defeat the purpose of trying to show the data in the first place, no? Am I misunderstanding?

In parenthesis, you ruled out code changes, So I offered a suggestion that did not require code changes. How can it help?

I have code that renders the CAT scan we often see as a gif of a human head (looks like Hova's vatar) as 3D image. It let me turn that gif around so I could see the guy's face. On my old laptop, it would take about an hour to render the image in 3D. On my new laptop it only takes about 15 minutes to udate the screen if i watch the updates but if I minimize the screen and watch the CPU (windows task manager) I can see that the update will complete in about two minutes.

So...

It did not require code changes

It did increase the renering speed.

If you lifted the "no code change" restiction, I suggest defer FP updates, hide the widget, update the widget, show the widget undefer updates.

BTW: Using Defer FP update when trying to update a chart on a tab control results in no update as of LV 2009.

Ben

... Can anyone help me fill in the rest? Here's what I'm looking for:

• In general, what's the biggest limiting factor in LabVIEW's execution? Is it RAM? CPU speed? Bus speed?
• Specifically with regard to graphing/UI stuff, what's the biggest limiting factor? Is it the UI controls themselves? Does accelerated graphics ever matter at all to LabVIEW?
• Given a problem with CPU railing during intensive plotting (not 3D picture control), what's the best way to tackle the problem other than code changes?

I can optimize code or deploy to more than one CPU so Virtual address space is the limit I hit most often. Even the Bus speed can be worked-around by designng hte app to run on more than on machine (devide and conquer).

UI thread is single threaded. Accelerated graphics really made a big difference in my 3D graphing speed. Even the old 3D graph (that only used a single code to render the graphics) got much quicker when I used my new top of the line laptop.

You last question is rather limiting but ... Hiding the FP of a LV app realy can speed up a screen update.

Ben

In the US media we often hear the term "Hero" applied to people that find themselves in a situation where they do their job as expected, Fire fighters, police, doctors and the like. When interviewed they dismiss the heroic nature and simple claim to be doing their job.

There are others that go beyond "doing their job" and put themselves in harms way fully knowing that harm can or will come to them. The story of the Fire Fighter at Chernobel (sp?) that drove up to the fire and continued to fight it single handed while vomiting and eventually passing out from the radiation.

So the operators now working the issues at the reactors in Japan...

Are they heroes or just doing their job?

Ben

Not sure if this is the best place to post but check our white paper for accelerating the FIX protocol using FlexRIO and LabVIEW FPGA

http://www.wallstree...a.com/fixcancel

Feedback and comments are appreciated.

Very cool!

[OT]

Have you done or heard of anyone analyzing trends based on the market in terms of the current gold price?

I ask because I have often wondered what the trends would look like after being transformed to the "Gold Space". I have concidered writing the code myself but it never bubbles to the top of my ToDo list.

Just curious,

Ben

Neville covered it quite well.

Clocking options are very robust on PXI.

Disclaimer, I am a LV guy...

You may be able to run your app on one of those USB-DAQ widgets that have RT a cRIO built-in to handle odd ball low jitter requirements.

Ben

Another option for the PXI platform I failed tommentio last night is "SCRAMNet" from Curtiss-Wright implements shared memory between machines. Data transfers are blazing fast. I have adapted them for use in LV but they were originally develoed for C. If redundancy serves any purpose in your app then concider SCRAMNet. Not only are the transfers fast but with the right hardware you can configure multple redundant paths with slef healing etc.

Ben

...

Good luck and keep us appraised of your progress.

Neville.

Neville covered it quite well.

Clocking options are very robust on PXI.

Disclaimer, I am a LV guy...

You may be able to run your app on one of those USB-DAQ widgets that have RT a cRIO built-in to handle odd ball low jitter requirements.

Ben

Yeah, it took me 9 years to finally decide to dive in... Oh, you mean about the posts!

My wife has been trying to get me in a kilt for years. I believe should found the Anderson tartan available from a place in Cananda, I suspect the same as yours. Aside from the interesting situation it presents in the airport security lines, I have been shunning the idea. You are a better man that me! Congratulations on the mile-stone.

Ben

In the context of a large application that will be maintained/added on to for years, what is the best choice for data communication?

For the purposes of this discussion, we are talking about using TCP to communicate between two LV applications. Each application will be updated separately. The server side will ALWAYS be up to date with the latest transmission/receiving types, the clients may be out of date at any given time, but newer transmission types will not be used on legacy clients.

Would it be better to:

Use a messaging system relying on a typedef'ed enum with variant data. (Flattened String to Variant, Variant to flattened string used for message formation/conversion.) each message has an associated typdef for variant conversion.

OR

Use a messaging system relying on a typedef'ed enum with a human readable string following the bin data of the enum. Each message has its own typedef and a string formation VI as well as a custom string parser to data.

Additionally, LVCLASSES cannot be used, so don't go there.

Would love to hear some takes including your perceived benefits/drawbacks to each system.

Why not take a leason from the 7-Layer model and look at how packets are transfered specifically, design a generic envelope that you can pack any type of data into adn ID the type of packet. So something like

32 bits message type

32 bits length of the data

The first value will tell you what language is being used, and the length tells you how big the data is.

A quick check of th first value will tell your software if it can handle the protocol. if it can then look at the data.

Just my quick 2 cents,

Ben

At least I know one wrong way.

I'm trying to workaround.

Thanks François!

Search the Dark Side" for the phrase "Controls on the fly" for many threads on this topic.

The easiest aproach uses off-screen hidden objects that are placed there durring development and shown/positioned/sized/labeled at run time. That is the easiest approach.

The other exteme approach uses a picture indicator to render the images of the objects and explicit code is developed to handle the user interaction with those objects. My latest version of this approach took me about 3 months to design, document and then develop, so to don't run to that extreme unless you have to do so. Try to nudge the requirements such that you can put some upper limit on the number of the possible widgets and use the simplier approach.

Ben

Discalimer: The approach I described above was first inspired by a post by JPD and is just my interpretation of that idea.

Think of the UI as your boss and you as the core. Your boss tells you what to do but can't doing anything himself. You have to do all the work.

Therefore, you are decoupled from your boss. He can be fired and a new boss brought in and you will still do the same work. If you are fired, the boss can't get anything done without you! (one of the joys of being a LV dev )

In this above exchanges above a point that has not been made is

"What is the app supposed to do?"

If the app has no no UI requirements, then it seems complete decoupling is possible. He#$, I wrote one of those 12 years ago before I knew what OOP was. THe GUI only had a bitmap of the folw originally imagined by the customer and nothing else. But then again if a an app does not have a GUI is discusions of decoupling form the GUI becomes a high-tech version of "If a (an) tree (app) falls in the forest (lacks a GUI) will it make a sound (can it be decoupled)?"

So continuing on my philosophical trek...

Interacting with widgets and devices

When I write code to interact with GPIB widgets or DAQ devices, I do not start by switching to kernal mode but rather reply on the methods and properties offered by VISA and DAQmx. The Classes that use those services, are coupled to those services and depnd on them to work and will break if they go away. Provided the app has to interact wiht real devices (simiulation not concidered) the code will also depend on the functions/commands (services) offered by the widget and it will suffer if the used functions go away. Now to apply what I think Feilix was saying... VISA is an abstraction layer that reduces the coupling between code and widget.

LV offers a set of virtual objects that allow us to interact with users. If our apps have no UI requirements, then the virtual objects services are not required and decoupling (disclaimer: implementing a global abort in batch type apps, I have not pondered in this context).

Three ways to implement a GUI?

I'm just musing out-loud so maybe more.

Traditional

Prior to LV 6i we did not have property nodes and control references but rather we had attribute nodes. We had two choices, use the native LV controls "as-is' and avoid attribute nodes, or "over-ride" the native operation and use attribute nodes to do what was required byt the app. Still attempting the work on my vocabulary... the GUI and the code were tightly coupled. You had to ""ctr-A Ctl-C" to duplicate the apps GUI functionality. Complex LV apps that date back to LV 5.1 or before had very complicated diagrams. THere is an example of of a "bad diagram" over on the Dark-Side that I am convinced was developed in LV 5.1 and upgraded.

Cotrol References:

With LV 6i we picked-up the ability to move the code that did complex manipulations to over-ride the native behaviour of LV's widgets into sub-VIs. This provided a level of abstraction we did not have previously. We could now write sub-VIs that performed a common function by acted on different objects. They let us implement a layer of abstraction between a class of of widget on the GUI and code that used that widget.

Concrete primitive example - Back in 6i, it was still common to poll a cluster of booleans for a command or a mode change. I wrote a re-usable AE that would accept the control ref and return the name of the first boolean true. It could be used on any cluster of booleans blah, blah, blah, It added a layer of abstraction to a a widget of type "cluster of boolean" and de-coupled the code that used it from the actual instance on the GUI. To use this primative abstraction level, the code that used it had to have some knowlege of what object it had to work on (the cluster the user clicked on was tightly coupled to the opeation of the application) "Expert Pattern" (?). In this case the code that used the abstraction layer (AE) "pushed" the control ref to the AE.

"With great power comes great responcibility." (I don't know the author) But control references, even in these early days could be dangegerous if property >>> value is used to store data rather than a way to query or update a user. I feel this would be tight coupling and can become quite restrcting.

Time goes on... we learn more about control references navigating same and some more complex applications of control refs.

Dynamic event Structures - another double edged sword that helps to couple or decouple. I tend to think that dynamic eevnt structure as a powerful decoupling technique. Going back tot those Old apps... If an app was not in "Supervisor mode" we could not respond to a button so the "Non-Suppevisor mode" had to "Not_DO_Something". So turning on and off events feels like I don't have to worry about the stuff I'm not supposed to do since it just does not happen (the event is not registered and just does not fire) so CODE RUNNING IN event stuctures become less coupled to the GUI since events only fire when appropritate. "Code running in" events only run when they have to run adn when they run they do what they are supposed to do (e.g. The "load Design" button does the same thing when one button is pressed in design mode and another button pressed in operate mode). "The other edge" that come with Dynamic events enters when we concider when to register/unregister what, when. The app has to answer those questions and "someone" is responsible for knowing how to find those answers and is therefore tightly coupled to the GUI to implement the non native LV functionality (control don't hide show themsleves, yeeessshhh!). "Somebody" has to do it. This part of the code is coupled to the GUI is coupled to the GUI in the fact that the widgets it hides/shows registers/unregisters have to be available. They don't necessarily have to be a particular widget on a particular GUI. Provided there are are compatable widget SOMEWHERE, it could still work.

Example: My lame example above. I could have nested modes of operation tht the operator moves through using a series of clustered booleans. As the modes change the cluster get hidden shown based on the button presses. The same sub-VI could execute on all modes to figure out which button wa clicked and different event cases would caall that sub-VI depending on event registrations.

But if another customer wanted to use the same application but wanted to implement it not doing the hide/show thing but rather present pop-ups wiht the clusters, the code runs the same but operates on different yet compatable widgets (I admit I would avoid adding this level of complexity unless the app required it).

Another Tightly coupled applicaiton of events is the use of "Event Signalling". THis seems like a tightly coupled situation but I have not thought about that twist yet.

So because my wife tells me the pot roast is ready I'lll wrap it up now...

The coupling between code that has a GUI and the object offered by LV is similar to the coupling between apps and the widget they control or monitor. We can have apps that are completely decoupled from the GUI if it has no GUI requirements.

As long as there are "special requirements" there will be coupleing.

XControl are probable an example of decoupling.

Take care,

Ben

That would be a lumbar microdiscectomy, to be exact. Yup, today I am getting my back opened up and parts of my spinal column removed.

I have had a herniated disk (well, a couple actually, but only one that's currently causing a lot of trouble) for almost a year now. It was bad, got better, then at the beginning of last December got much worse. I have been thru therapy, oral steroids, epidural cortisone shots, etc. Nothing seems to be working, so it's time to get out the knife.

I am currently on more opiates than House. The big difference between me and House, tho, is that he's a fictional charcter and doesn't actually feel pain. I, on the other hand, still hurt like h3ll.

Hopefully that will be all over in a few hours. Well, mostly over anyway, as I've been told there has probably been nerve damage and there will be residual pain/tingling/numbness from that for quite some time. But it should be much better than it is now.

I'm not sure what the recovery time will be like. I can't come back to work for 2 weeks. I'm not supposed to sit for more than 30 min at a time. At the moment, sitting is very painful and I'm lucky to get 10 min in a chair before the pain becomes too severe. That would be why I haven't been on LAVA much -- it's hard to type when you're walking around.

This is a routine procedure (for my surgeon, anyway ) and if all goes well I should be back home tonite. Keep your fingers crossed for me!

Cat

AS the son of and brother to sewing nuts, I recalled one of those "accidents" with them "auto sewing" themsleves.

I hope all works out well.

Ben

Many of my apps came to me as "NI said it can't be done" (or antoher third party)due to the extreme performace demands (Real-time NDT is an example). These apps typically can not tolerate using the UI thread (which is required if using property vlaue nodes)to do the updates. Additionally duplicating data is a big no-no since there is barely enough memory for the first copy let alone the copied version.

So althought Decoupling and OOP ideas in general are useful when developing, if my apps is the "perfect LVOOP" app but runs like a dog, its harldy perfect.

Ben

Question:

This idea comes to me because I once read that LV was an early inventor of the idea of "time" in programming (I don't remember when or where).

Is the idea of "Time" reflected in OOP ?

I can't recall running across the speed ever entering into the game.

Ben

...

This comment gave me cognitive dissonance and I've been thinking about it for the past couple days. I agree that flexibility and re-use are not necessarily explicit project goals and all requirements need to be balanced, yet the idea that decoupling would not be a desirable characteristic in any app of reasonable size is... dissonating.

Decoupling (in general, not just the UI) does more than just improve flexibility and reuse. Most notably, testing a decoupled component is much, much easier than testing that same functionality in a tightly integrated system. It also (IMO) makes development easier as there is a clearly defined api that can be implemented without worrying about hidden interactions with other components. While I have never has a customer explicitly require decoupling, the requirements they do specify (as well as the implied requirements, such as fixing bugs in a timely manner) always lead to at least some degree of decoupling.

I'm not disagreeing with you... just verbalizing (or textualizing?) the way I resolved the dissonance.

Many of my apps came to me as "NI said it can't be done" (or antoher third party)due to the extreme performace demands (Real-time NDT is an example). These apps typically can not tolerate using the UI thread (which is required if using property vlaue nodes)to do the updates. Additionally duplicating data is a big no-no since there is barely enough memory for the first copy let alone the copied version.

So althought Decoupling and OOP ideas in general are useful when developing, if my apps is the "perfect LVOOP" app but runs like a dog, its harldy perfect.

Ben

I'm sure NI purposely makes the problems much bigger than what can reasonably be accomplished in the given time. Why? I dunno... maybe to put us under pressure... maybe so we don't have time to experiment/learn how to do something... maybe because they're sadistic bastards...?

I think I would prefer that over a coding test. It's much faster sketching out execution diagrams and state diagrams on paper than on a bd.

First time I took it it was a trivia test on LV. There was some coding but not much.

THen they re-did it and it was coding test along with some Qs. If you are not a CS type make sure you know the vocabularly. Since then the recert is supposed to be just questions, but I have not sat for that since they changed the re-cert.

Remember you are being judged on Architecture not coding. Leave the coding for the developer that gets your design.

Ben

Yes, but only if you app is trying to display data at high speed. If your app is some sort of automation control app, you likely are not doing anything that a 1ms delay could affect. And, in most cases it is less than that. Additionally, there are ways around this by creating a separate dedicated channel for the high speed data and having a separate UI loop handle it.

We're on the same page. The point I would like to highlight is decoupling, although desirable for flexibility and re-use is not nessarily desirable in all applications and should be carefully balanced with other requirements.

Ben

Cat - Web Service support SSH, if you need it.

And, there is no reason you need to use them for a decoupled UI. You could just as easily use a queue if you UI and core are both running on the same machine in the same app instance.

The benefit of a decoupled UI is: can replace or change without affecting the core code. Can use message channel to automate core (headless). Can use message channel to test core and UI separately. Cna log message channel for field debugging.

Downsides are: more code to write. Not as easy to implement, design wise. Might offer slower performance in high speed apps.

"There is the rub" (Hamlet, Act 1 scene 1 ?)

Ben

Who is Loopy? And doesn't she mind?

Extending the pun with a Pittsburgh twist...

Years aago I was helping Mister Roger's Neighborhood with a printer problem. It was a unique experience. I came away thinking that acting like Mr Rogers was a req to work there. I told them iswould be couple of days before the printer would work and wa about to cover my head (since that is when customers want to hit you) when my contact replied "That's OK Ben, want a cookie?". So on my return trip the admin assiatanst wanted autographs so i got them sorta what the they wanted.

Now the real nut-case in that gang ws Mr McFeely how is actually the author of all those shows. He had an office with pidgeon holes up the the ceiling with all of the old scripts. When he asked who the autograph was for and I indicated one of the secretaries he signed his photo with the message;

"Stop down some time and find out how I got my name."

Ben

I hope their requirements are fairly simple then.* Complicated requirements require complicated solutions. I haven't found a way around that yet. It's all a matter of how you manage the complexity.

(*What do you do when someone asks you to build an F-22 fighter jet, but make it as simple to understand as a bicycle?)

I have done the system that tested out the new fuel pump for the JSF and the sytems that tests the GPS for cruise missles.

I document everything with the assumption my audience knows little about software. The final code get deployed with diagrams in the BD detailing the states with each state being very boring.

Ben

So, are you feeling LOOPy?

Far from the GD and adults skipping, LOOPy reminds me of the song from "The Music Man" "Shaboopy".

Ben

It all depends on how much decoupling you're looking for. Injecting control references decouples *that specific* UI from the funcitonal code, but the functional code still requires *a* UI. Ultimate decoupling means you can, for example, attach multiple UIs at the same time, or run the code with no UI at all.

"Decoupled" isn't a binary attribute--it's a gradient. If you have implemented an insufficient decoupling strategy for a given change request, you'll end up having to rewrite a lot of code, or at least do a significant overhaul. Personally I like to build my UI's more along the lines of what John does with a UI component to send and receive messages, and interpret and display data.

And since I have to code for LV basics I & II customers, I stick with the references since adding code to get that extra degree of "uncoupling" would not sit well with most of them. Hell, an Action Engine seems "overly complicated" (actual quote from customer) to some customers.

Take care,

Ben

As far as i can recall, this is the first serious discusion of what Decoupling the UI really means in LV.

Question:

Is ther anyway to interact with a LV FP without using ActiveX via properties or methods?

None come to my mind.

So my gut feel for what the term "Decoupling the UI" means in LV has to assume the the use of control refs somewhere in the game.

I think I am coming down on the JG side of this discusion since differnt GUI's that provide the same set of controls and indicators (think of these as different classes that expose the same properties and methods) the underlying functions should still operate regardless of how I have re-arranged things.

But I am just and old wire jockey and these CS concept are not my area of expertise.

Take care,

Ben

A great thread over here on Best Practices brings up something I have occasionally wondered about -- the concept of decoupling the UI from the code.

While I grasp the concept philosophically, I'm trying to figure out what it looks like in practice. I'm not sure if this is just a fancy term for something I already do (as "plug-in architecture" turned out to be), or if it's something I should be looking at doing.

Does anyone have some code they don't mind offering up that would be a good example of decoupling the UI?

Cat

I am in a similar situation. This thread on the Dark-side

http://forums.ni.com/t5/LabVIEW/Strange-Problem-Cluster-of-References/m-p/1110076#M490461

has images showing how I seperated the GUI from the logic. Once i have refs to all of the FP object the underlying code can run under any FP that has that set of objects. Technically speaking the control refs still represnt a dgree of copling that I could work-around but then I get into text based solutions (control names to find refs) that I avoid since it would only open me up for typos and any LV implementation that leads to the potential of typos feels like an oxymoron to me.

Take care,

Ben