-
Posts
2,767 -
Joined
-
Last visited
-
Days Won
17
Content Type
Profiles
Forums
Downloads
Gallery
Everything posted by Grampa_of_Oliva_n_Eden
-
Agreed! While it was possible to change the look of the LV 7.1 version, we can no longer get at teh properties of teh cursor legend. If you need to change it, you will have to code it up, Ben
-
The batteries should come packaged like a baseball bat, to be useful both before and after they discahrge. Ben
-
Yes a hat or a phased array antenana built into your belt. Would it sell? But since we are brain-storming, how about a backup beeper built into our belt. Ben Yes a hat or a phased array antenana built into your belt. Would it sell? But since we are brain-storming, how about a backup beeper built into our belt. Ben
-
In the thread that Tomi M started to demo the dynamic event feature he included a demo that let you drop square circles etc. Latter in that thread I followed-up and he posted a modified demo that showed how to do it in an exe. In a nut shell... You search for all LV classes that can be cast as the parent type without errors. The parents don't have to know about the children at compile time. Ben
-
I have written/read class data to from file and it worked great. Yes all references to LV resources (like queues etc) need to be recreated if they went invalidi ( I imagine you could get a ref toa queue stick it in a class data write to file read back and it still works if teh queue was kept alive elsewhere). Re: Writing to binary files I always imagined there was a flatten to string built-in to the Binary file operations. Is there a difference? Ben
-
How do you model this?
Grampa_of_Oliva_n_Eden replied to Daklu's topic in Application Design & Architecture
Here at home I am trapped at LV 8.5. So I checked out the Singleton design pattern that shipped with 8.5 and there it is, an Action Engine at the heart of the Singleton. Types and Anti-types can both be useful, so I'll use them where appropriate. The QSM was taught as part of the orginal LV advanced course and was presented as "the type". I have a customer (may be a past customer of someone else here) that was originally based on the QSM and he (the customer) was sold on the QSM being the only "right" way to code large apps (old advanced course). After 6-7 years of enhancing and adding to it resulted in a monster that he could not maintain, so he hired us. We now have two developers working 3/4 of thier time on that app. We need two because the code changes are so complicated that one guy does that , and the other runs through the 93 pages of acceptance testing for each release. The reason I sahre this story is to illustrate that the QSM simply does not scale well. The inability to document the flow is a major factor. Ben -
I don't know if this helps (or if I can uplaod it) but this PowerPoint presentation contains the complete design of an app I delevered years ago. It contains 64 pages of "nuts-n-bolts" with every state machine included as well as notes (see the notes pages!) telling you everything that that goes on in every state. The final code was implemented as shown with those images included in the final app. The customer's "Ben" did not like my auto-scaling so that code was modified from what is shown in the doc. I hope this helps, Ben System Architecture5.ppt About that app: That app was designed to characterize TPV diodes (Thermo-Photo-Voltaic Diodes) who's characteristic curve is afftected by both temperature and light. I had to control the temp via HP power-supplies driving a pelier crystal, the lihgt via another PS, ramp the lamp through steps and ramp the light through steps while acquiring curves. Lots of parallel process that needed coordinated. When I presented this design to replace an existing HP-VEE app one of the scientist said "why such a complicated design?" I replied that the HP-VEE implementation fialed due to lack of multiple threads, I want this one to work!".
-
..its fleace was white as snow... to this depth of sillyness Yair nevers goes. I pondered posting to this thread, with its many twists and turns. But the long term effect upon my head, would surely pound and burn. Ben
-
Labview anti-pattern: Action Engines
Grampa_of_Oliva_n_Eden replied to Daklu's topic in Application Design & Architecture
Sorry for the delay, I had lost track of this thread! That is a wonderful explanation of my Event Logger with some features mine does not have. I can't ignore the reentrant feature. Nice! The following is in the interest of learning what others have done about errors on RT tragets... I have never used my Event Loger on a RT target since the strings of the Error Cluster "Source" is of variable size. In an RT environment, dynamically allocating buffers for the strings when code starts "spewing errors" can crash an RT app. "Bad, Bad, Bad". IN RT apps I force the Source to empty strings and pass the rest off to a WIndows app to log, whenever possible. So... Have you tried your LVOOP based solution to RT yet? TO All: What are your experiences with logging errors on RT targets and what techniques have helped you? Thanks again Mark! Ben -
Yes but what YOU get is knowlege and an insight thatcan serve you the future. Did I ever tell you about coding up Control references in LV before control refs where released? Gave me a good appreciation of what had to go into control refs. Ben
-
2 executables, 2 computers, 1 calls the other
Grampa_of_Oliva_n_Eden replied to torekp's topic in Calling External Code
Thank you Scott. Another option inspider by a post by JPD years ago... He wrote a VI server based ap on his work machine to transfer file he forgot at home. Invoked all of the VI's on his home machine to do the transfer... Point is... A similar app could copy your exe and then invoke it. Done stirring up the mud, Ben -
WE can (and may) discuss this for days and generate a lot of clever and witty posts but in the end the common non-scientist amoung us can have a hard time deciding who to believe. I am bracing for the cocktail party where after answering what I do for a living them asking the follow-up question (paraphrasing form Glenda ?sp? from the Wizard of OZ") "Are you a good witch or a bad witch?" Ben
-
2 executables, 2 computers, 1 calls the other
Grampa_of_Oliva_n_Eden replied to torekp's topic in Calling External Code
NO! Not from experience. My replies where based on how it used to work mixced with mental notes when the new technology was introduced to the Champions. Ben -
[set humour in the midst of an disaster mode = true] That bump at 32,000 years ago represents the "Global Tree Crisis" where the false rumour spread that climbing and living in trees resulted in global warming from the branches rubbing together. The result was that man moved down out of the trees an learned to stand up-right so he could see the next scam coming from a distance. [set mode real] It does not take a scientist to understand those graphs. I don't like being lied too and those plots illustrate the lie we have been fed. I have to confess that part of my discontent is in the fact that I am being lied too. Ben
-
The question about password of block diagram
Grampa_of_Oliva_n_Eden replied to FengDe's topic in LabVIEW General
This question comes up often here and elsewhere and the answers (after endurring a series of one-liners about backups, bit buckets, and leasons learned) are always. If you don't have a non-password protected backup version, you are doomed to re-write it. Ben -
2 executables, 2 computers, 1 calls the other
Grampa_of_Oliva_n_Eden replied to torekp's topic in Calling External Code
With 8. and beyond this got more complicated... it is now possible to have the same VI running in more han one process context so we have to ID the context. Open VI >>> Owniing App >>> Project.TragetItem >>> Project >>> name should give you the name of the process your target is running in. then use Open Application Reference >>> Projects.Projects[] to locate the conext you found above. Once you have the right conext, then open the VI. It looks like you have all of the security chcks OK in you exe INI but double check those plus port number and possibly the fire-wall. Edit The news of not being able to do this after LV 8.2 is news to me. Ben -
2 executables, 2 computers, 1 calls the other
Grampa_of_Oliva_n_Eden replied to torekp's topic in Calling External Code
Yes and you have to specify the full file paath because the VI is not in memory yet. Ben -
You haven't heard of him? Why he is the bestower of Obama money, see this link. http://my.opera.com/BAMAToNE/blog/2009/10/12/free-obama-money-from-his-stash Which reminds me of Benjamin Franklin who wrote; "When the people find they can vote themselves money, that will herald the end of the republic." http://quotes.liberty-tree.ca/quote_blog/Benjamin.Franklin.Quote.CC66 Ben
-
Clear? I believe the term geek originally (? used to ) refered to a wlidman in a circus sideshow that would bit the heads off of live chikens. Anything but appealing. But on the other hand any women whose eyes do not glaze over when the conversation gets technical is by definition "hot" so geek really can not be applied to women. But for a man he could be one or the other or both. No, geeks are not a sub-set of nerd, since someone could be a geek with being technical. Of course the above is subject to the typical hob-nobbing that happens here. Ben
-
2 executables, 2 computers, 1 calls the other
Grampa_of_Oliva_n_Eden replied to torekp's topic in Calling External Code
... and in the network bind them. Ben -
2 executables, 2 computers, 1 calls the other
Grampa_of_Oliva_n_Eden replied to torekp's topic in Calling External Code
VI server works with an exe so.... what is the issue? Ben -
How do you model this?
Grampa_of_Oliva_n_Eden replied to Daklu's topic in Application Design & Architecture
Good point! many of my GUI's apps are of that form with a single event state taht transitions to a state then return to the event state. The following ideas are based on the QSMs that I have seen... I thought about this modeling Q and what I suggested earlier to draw-up the stacks that are queued up as individual diagrams. If you complete this work for your app I suspect you will find the the states that are called in more than one of these diagrams (example File Open, just guessing) could be turned into a sub-VI that could be used before exiting the state that calls them .... with the intent to eliminat that state from the stack that is queued up. If this process is repeated for all of teh "shared" states, and extended for the one-off states, a QSM can be converted to a normal state diagram. But the above is just a thought exercise and I am not telling yo to rewrite your code just so you can model it. But if you do the re-write in your head or on paper, you may be able to draw up the moel after all using "macro states". But then again if the QSM is pushing at both the front and the back of teh queue... I don't think the above will work. Ben -
And now that you brought up Tesla... Monday I was delivering an upgraded app that had to using a resolver to monitor to rotaion of a shaft. The customer (being young) never learned about resolvers and mentioned "I'd don't know how they work, there just seems to be a bunch of wire in there." If Tesla was not the person that invented resolvers, he would have loved the idea. Ben
-
Yes but... would it have happened by now? Who can tell. If we look at the state of physics prior to Einstien the general thought was "Well we know everything now so what's next?" Einstien had the same set of facts in front of him but it was him that had the idea and shared it with us. For my part I'll attribute the light bulb going on in her head as the reason we have compilers now. Ben