Grampa_of_Oliva_n_Eden
-
Posts
2,767 -
Joined
-
Last visited
-
Days Won
17
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Grampa_of_Oliva_n_Eden
-
-
-
-
QUOTE (menghuihantang @ Mar 24 2009, 12:13 PM)
http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=102576#M102576' target="_blank">See here !
Ben
-
QUOTE (Cat @ Mar 24 2009, 06:09 AM)
...But, I guess I'll probably have to give NI support another try.Great story! Now I understand the bump on my head!
1) If you don't make any good progress (if you do not have premier support that could be an issue) use the phrase "I understand that it should be possible to ESCALATE this call, could you do that please?" Mnay AE's (particularly the rookies) will fight that thinking that they have failed if they do so.
2) I believe it is Elijah Kerry form NI who is pushing those new tools. Since he is in the marketing side you can just ask for him when you call NI. Tell him that "Ben NI" said that "he (Elijah) can make recomendations on who to talk to to get the tool working the way it has to." Have your service request handy when you call for him since he can use that to escalate the call.
3) Talk to your local NI person. They picked-up a little extra in their pay-check when you bought that software, let them help out.
I aggre with Neville that traditional approach may hel pnarrow down the issue to a point where can invoke the toolkit to get that extra info you require.
Still trying to help,
Ben
-
QUOTE (menghuihantang @ Mar 24 2009, 09:00 AM)
As http://forums.ni.com/ni/board/message?board.id=BreakPoint&thread.id=7246&jump=true' target="_blank">I posted in this thread, what will really make a difference is an "eye Tracker". Maybe the next generation after me will go for the brain plug vesion.
Ben
-
QUOTE (menghuihantang @ Mar 24 2009, 08:41 AM)
LabVIEW is a graphic programming language which basically avoids text-typing.I wonder if touchscreen programming for LabVIEW is available. I mean it makes the best use of graphic language and much fun, like in the scientific fictions. That will be so cool.
In theory yes but in practice "it aint ready for prime time".
How to do youdistingisuh between a left and right click?
Dragging on a touch screen is hard if your finger starts buncing as you drag...
Tried and reched for my track-ball after very short order.
Ben
-
QUOTE (Cat @ Mar 23 2009, 12:33 PM)
Please tell me you have been talking with NI Support to address those issues (please).
That is one of the new widgets NI is pushing so you should be able to get some decent support.
PS After you have your issues solved and you become our expert on this tool, you may want to take a look http://forums.ni.com/ni/board/message?board.id=BreakPoint&view=by_date_ascending&message.id=409#M409' target="_blank">at this Sea Story I posted over on the Dark-Side.
-
HI Mark this is not directed at you but your post stuck a nerve with me.
When reply to "NI recommends to develop architecture which is state persistence and Restoration. "
QUOTE (Mark Yedinak @ Mar 22 2009, 08:35 PM)
This means that your system should be able to remember the state that it was in when you exit it and that it can restore this state when you run it again. In some cases you don't want to preserve the state and in others cases you do. However a good architecture would allow you to maintain this information between executions. In addition, your architecture should be such that different tasks within your system can obtain state information about the running system. Again, not everything needs to be exposed but there is some information that you may need to expose to all parts of your system.
...
I don't mean any offense by what I am going to say next so please don't take it as such. But these are pretty basic questions when it comes to a system architect. I have to ask are you really ready for the CLA exam? Perhaps you need to get some more large scale application development experience under your belt before you are ready for this exam.
[set Rant = True]
I did not study software officially so I don't even know where or what it was I was suppposed to read that would have taught me that. Now I have designed and developed app that meet your explanation but I never knew there was a fancy title that went with it. Sometimes I think NI writes up there req's like they are college course descriptions in that they are nebulus to anyone that has not taken the course but are really rather mundande once someone explains what all of the fancy words mean.
Done venting, thank you,
Ben
(CLA but I am always wondering "How did I pull that one off?" and "Are they going to write me out of the gang NEXT time?")
-
QUOTE (Jeffrey Habets @ Mar 21 2009, 06:28 AM)
This is actually what I do in most all of my code.. All my parallel processes are implemented as active objects. The object takes care of allocating all necessary stuff before spawning the process and cleans up afterwards. Depending on the nature of the task of the process, I'll simply use an "Abort VI" to stop the process or a message with response notifier. For me, the usage for one over the other is about 50/50 I guess.http://lavag.org/old_files/monthly_03_2009/post-906-1237631134.png' target="_blank">
Jeffrey,
Let me stop and thank you for that image of your active objects! That diagram reflects very well the scheme I used in when I guessed at how to implement active objects. I feel like I took a wild guess at bonus Q on a test and ended up with full credit! Whooo hooo!
Re: Aborting and keeping refs in the top level VI...
Seems like we are breaking some LVOOP rule by making the top level responsible for low level refs etc.
Ben
-
QUOTE (Gary Rubin @ Mar 20 2009, 11:59 AM)
I'm sure I've read something related to this, but struck out using the lavag search. I apologize if this is a rehash of something that's already been covered.We have an application in LabVIEW 7.1 in which we're using queues to pass data between parallel loops. Because there are memory allocations associated with enqueueing (and presumably deallocations for flushing?), would it be better from a performance standpoint to use an LV2 Global containing a preallocated array?
Also, I seem to recall that there had been some improvement in how queues are implemented in LabVIEW 8.x. I've been trying to get us to upgrade, but nobody seems to want to spend the $$. Are there queue (or other) performance issues that I might be able to point to?
Thanks,
Gary
Hi Gary,
The big performance related change is the "memory Control" palette that iclude the operators to explicitly tell LV to work "in-place".
Check NI web-site for the release notes for all of the intermediate version for something that you think would be a good selling point.
As far as development goes the Quick Drop functions added with LV 8.6 are absolutly adicting once you have your short cuts defined and memorized ! I can drop any my 53 most frequently used operators in the blink of an eye and even a confernce room full of LV Architects were impressed when I demoed the short-cuts for the rest of my group.
Ben
-
QUOTE (Aristos Queue @ Mar 20 2009, 08:57 AM)
.... It seems like a more effective way to stop a process than having to code boolean checks all over your code, especially when LV has such nice hooks right in the assembly code at the end of each clump of nodes to detect abort.Reading that reminds me of Ed Dickens signature that reads;
"....using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.".
Ben
-
-
QUOTE (Cat @ Mar 20 2009, 08:46 AM)
I have a main program that calls a lot of subvis dynamically. When the user selects a particular function, I open a reference for the corresponding vi and run the vi. When the user exits the vi, I close the front panel and close the reference.This works fine, except... I have a vi I call "Big Top.vi" that doesn't do anything but hold all those dynamically called vis on its BD, basically for debugging and organizing (this was originally developed in the pre-LVproject days). If I have Big Top open (not running, of course), and I call a vi dynamically with the main program, after the dynamically called vi exits and the reference is closed, the vi is still running. I can't see it (the front panel is closed), but if I open Error List, that vi is in there as "already running". Even after the main program is exited, the dynamically called vi is still running. I've checked, and the reference is indeed closed when it's supposed to be.
This isn't a huge deal, since the code will be really run as an executable. And now that I know what's causing the problem I'll just manually clean everything up when I'm working with the source code, or not open Big Top in the first place.
But my question is what's going on?? I'm assuming it has this issue because the vis aren't normally in memory when they're called, but when Big Top is open they are in memory since they're parked on the BD. But I don't get how this keeps the called vi running even after its reference has been closed. Or is there some other step for *really* closing the vi that I'm missing?
Cat
If the dynamic open a ref to itself, it can keep itself open.
Ben
-
For the BD constant explosion issue I use will put my type def onstants in a sub-VI with an icon mathcing the type def. as I mention in my Nugget on Type definitions.
It takes care of the type def expanding when editied and also gives you an oppertunity to document the data a little more.
Ben
-
QUOTE (rolfk @ Mar 20 2009, 02:58 AM)
.....It is a bit tricky to built it into a user application in a way that it can be used by people not familiar with LabVIEW or even programming at all. I made it basically a one button click operation in the maintenance screen of the application together with another button to discover any cFP target in the local network to fill in the IP address to use.
Seems trivial enough to use.
Rolf Kalbermatter
So its not an edge case after all.
Then our shared experiences having to fill this hole left exposed by the proj way of managing distributed LV apps highlights that fact the project can benefit form ... "Tinking outside the project".
Ben
-
QUOTE (shoneill @ Mar 19 2009, 04:15 PM)
I did actually learn (more accurately, I was taught) OOP in C++, but only many years later did the penny drop on the one issue I had serious trouble understanding. Inheritance.As soon as I realised that Inheritance was something dealt with at compile-time, it all became clear. This happened when dabbling with LVOOP. All those years I could never get my head around OOP simply because I never noticed (or my books never actually said) that Inheritance was basically static when compiling. I was never able to understand how run-time inheritance changes could possible be handled sanely and this really put me off OOP because I had the feeling I just wasn't "getting it".
LVOOP is for me the perfect somution for "same same but different" type of code. I realise that won't make sense until you're actually understood LVOOP, but for me that pretty much sums it up. Common framework, uncommon internals.
Shane.
There is a close relationship between inheritance and dynamic dispatching So I don't know where one end and the other begins.
In LVOOP dynamic dispatching is handeld at run time. That was the big plus for me because I needed to beable to add classes to an pre-existing exe. I just had to add the libray for the class to the right folder and the app found the new classes.
Granted I had to configure the new classes such that they knew what their inheritance was and that was done in the Project, but is was done after the exe was built.
SO the children have to know about their ancestors but the reverse in not required.
Ben
-
-
QUOTE (Yair @ Mar 19 2009, 01:44 PM)
They are better to use, but only if they are functional. If they just have read/write options (or get/set or whatever) for a single value, then they're no better than globals and in many ways they're worse. The power of functional globals comes when you place actual code inside them. If you're not doing that (and even if you are), you might wish to consider other alternatives like GOOP or LVOOP (probably using single element queues to transport the object if you want to have globally available data).Yair,
I have a project that still bears the scars of the Global on its bottom line (see the thread I linked about Globals causing Timed Loops to Finish Late).
When using globals to flag a stop condition, the Timed Loops would occationally finish late. That did not happen with LV2s and I never got a good explanation as to why.
So in that special case of using globals to stop a timed loop they performed badly.
Ben
-
QUOTE (Justin Goeres @ Mar 19 2009, 09:01 AM)
...And yes, at first OOP does feel like you're adding code on top of what you're already doing. In fact, it's possible that you're already doing good OOP-like things in your code to begin with. But using the native OOP takes some of the management work out of your code and puts it in the LabVIEW compiler.
But the LVOOP tools really make that a lot easier being able to create accessors and methods that are almost "code Ready" without having to edit Icons, wire connectors etc.
"An Introduction to UML and Patterns" the author name escapes me was very helpful for me when I was first trying to get my head around OOP. The book uses a recursive method to design a "point of Sale" (cash register) application and progressivle gets more specific until the next thing I knew, I was putting aside the book, drawing up System Sequence Diagrams, documenting contracts and creating LVOOP classes. I admit that waht I did may not get me a good grade in a college OOP course but the app did what the customer wanted and it sold me on LVOOP.
Just trying to help,
Ben
-
QUOTE (ASTDan @ Mar 18 2009, 03:08 PM)
I was having a conversation on facebook with crelf regarding the project in LabVIEW.Personally I only create a project at the end of projects to build exe, source code distributions, etc. Whenever I have tried to use it during development I throw my hands up in frustration.
The auto-populating thing really cheeses me. I creatle little test vi's all the time during development to test out ideas before I intigrate them in the main code. These show up in my project when they don't belong, and I have to go into the project to delete them.
My main complaint/misunderstanding is if I organize all my files properly on disk why do I need the project? What value does the project give me if I orgainize all my code and suporting documentation on disk?
Auto-populating:
A single developer may keep this on but in a team you run into issues with dirty projects (asterisk).
I use the "auto-populate now" occationally but usually place the VIs manually where i want them.
For the most part I use the virtual folder view since I can oraganize the VI differently than they are araanged on disk (very useful when working with LVOOP).
THe Right-click option "Find in Folder View" is also sueful sometimes.
Project are an absolute must very useful for distrbuted apps. to mangae and control all of the nodes and their options.
Source Distributions can help with cleaning up your floders (Old Save with Options)
Documentation and support files come along with the Source Distribution (a plus over the old Save with Options).
What I don't like about the project...
It has about ten zilliion save options! I still don't know which flavor of save saves what.
The tools in the project are only in the project. Say I have an app that has to talk to 500 cFP units. Without bending over backwards (which I did) you wil need a project with 500 cFP nodes configured to be able to load the same software on each but with different IP addresses and config files. Yes this is an edge case.
It combined with Shared Variables done in the DSC Engine and all of its processing power and efficeincy. I know cringe when faced with tag count apps with more than 500 I/O points. At high channel counts DSC would shine but I simply don't have the confidence in the Shared Variables to "look a customer in the eye" and tell them that Shared Variables will be able to handle the I/O reqs.
Support of the SV placed a heavy load on cFP units and some of the earlier version of LV 8, the goobled all of teh CPU to make them work. (Oh bother!).
Just my 2 cents,
Ben
-
QUOTE (Cat @ Mar 18 2009, 12:59 PM)
How could I fault you when I have been http://forums.ni.com/ni/board/message?board.id=170&message.id=175255#M175255' target="_blank">guilty of the same sin.
I have been global free for almost two years at this point.
Ben
-
QUOTE (Yair @ Mar 18 2009, 01:19 PM)
Go one version back - http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=352101' target="_blank">This was reported on Aug 28, CARed on Sep 2 and fixed on Sep 19. That's 22 days.Good point Yair, I forgot about that one. So we don't have a new record but we do have waht could potentially be a pattern of quick fixes for serious problems.
I like it.
Ben
-
QUOTE (BrokenArrow @ Mar 18 2009, 08:29 AM)
See http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=191864#M191864' target="_blank">reply #12 in this thread on the dark-side where Greg McKaskle explained why the VI Analyzer want controls and indicators that are on the icon connector to be on the "root" of the diagram.
Ben
-
QUOTE (rolfk @ Mar 18 2009, 05:20 AM)
I do not have any exact numbers but it is probably quite a fast fix indeed. ...If those VI based tool would not be password protected we might fix them ourselves and make them available but as it stands now we have to rely on NI to do that for us.
Rolf Kalbermatter
Thank you Rolf. That was the type of reply I was hoping to get.
Re:Fix it ourselves...
That is moving farther away from reality with every release. THe new version of teh Report Gen tool-kit has been implemented in LVOOP. We need a small change to a table in a report such that we needed it to include a header at the top of each page when a table spanned multilple pages. In the old version we could grab the right reference and "roll-our-own" enhancement. But now that;
1) the tool-kit is in LVOOP and
2) we don't have the password to the library, and
3) All reference are now private data
We had to duplicate the some of the Tool-kit code to implement the change.
Ben
Getting VI 'protoype' Information for Call by Reference VIs
in VI Scripting
Posted
QUOTE (LeeH @ Mar 25 2009, 05:01 AM)
Look seriously at LVOOP before putting any effort into writing anything that does not use LVOOP. It worked well in my plug-in app and since all of the low-level stuff was handled by LVOOP I could just concentrate on making the app meet specs rather than coding up a mechanism to do what LVOOP offers.
Ben