Dan Bookwalter
-
Posts
103 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Dan Bookwalter
-
-
Here is what I suggest. Write one or more interface classes for your temperature controller. Add dynamic VIs to these classes that define the interface methods. These interface classes do not need to be the top most classes but if you think there is even more general interface that you can take advantage later on, you can derive temperature controller from some general controller class. Put all of these interfaces into a single lvlib library. Define which of your methods are public, which are private and which are protected for each interface class.
Then write one or more implementations of the above interface classes. As you do not want anybody to use your implementation directly put the implementation into another lvlib and define it to be private (from the lvlib properties). Then only VIs inside the library can access the interface. Add a VI to the implementation library which returns the class constant of your interface class typecasted to the interface class (My Temp Controller) or returns an initialized class if your implementation needs initialization. This VI should be outside your implementation class and it should be defined public from lvlib properties/item settings. Now you can access your implementation by placing this VI to the block diagram. The whole of your implementation however is hidden from the class users. They can only use the API classes you have derived your implementation classes from. This forces the user of your API to keep strictly using your API and that only and not the private properties of your implementation. You can also access your implementaion in a plug-and-play way by opening a VI reference to the above mentioned VI. If you want, you can search plugin directory for such VIs and then dynamically open the plugins as needed. You can allow user to define the path for the plugin, or perhaps you'd like to call it the driver. As you have encapsulated your driver into a lvlib, you can easily distribute it.
So your stucture would look like this
- Driver Interface.lvlib
- Interface Class.lvclass
- Dynamic API method 1
- Dynamic API method 2
- Dynamic API method 3
- Dynamic API method 1
[*]My Hardware Driver.lvlib
- Get Initialized Plugin.vi (public)
- My Hardware Implementation.lvclass (private) derives from Driver Interface.lvlib:Interface Class.lvclass
- Dynamic API method 1
- Dynamic API method 2
- Dynamic API method 3
- Dynamic API method 1
- Interface Class.lvclass
Jimi
That is the general direction I was thinking of going , but , I wasnt too sure how I was going to do it .... I think I will follow your guidelines and see where I end up...
thanks
Dan
- Driver Interface.lvlib
-
I really have not put any consideration to implementing HW drivers using LabVOOP, however I've implemented LabVOOP API on top of other "physical" resources. The best thing LabVOOP can provide, I think, is the fact that you can abstract the hardware away into an OOP API. If you make the API general enough, it works for any similar hardware. So you can write one or more interface classes and then hardware specific implementations for specific hardware instruments. This way the rest of your code remains the same even though you change your hardware into a different one. You can even use hardware plugins that you can plug-and-play into your system that implement your API classes for specific hardware (there was some discussion on this subject in another thread).
Jimi
Well this is something i have been thinking about for a week or so , i have to interface to several types of temperature controllers and i have been thinking about abstracting the HW as you mention , all i have to do is indicate which controller i want and use dynamic dispatching etc... this would make things a little easier for a couple of other people in the lab who are beginning to do some LV programming , but , have limited or no experience with these controllers and serial communication etc...
Dan
-
Well I am looking into writing an instrument driver using OOP , does anyone have any suggestions as to what type of architecture/pattern would work the best. I think my biggest problem is that in addition to figuring out which design pattern to use as a guide (after looking at it for awhile longer I am currently leaning towards the Specification Pattern along with the Factory Pattern) I also have to figure out how I am going to use the implementation in the real world , any thoughts ???? i know this OOP stuff is new to most everyone , at least in its LV incarnation....
Thanks
Dan
-
I sitll think the problem of the crap code will stall a beginner, and be too comprehensive to expect an advanced user to do it for you for free.
I just opned this mess up and the very first thing i said was Holy Crap (actually it wasnt crap i said
) i wouldnt even want to try to take that apart , let alone have a beginner try it..... -
Disco lives on through samples. Here's a recent chart-topper using the very same one we're talking about...
I have been sort of following along with this thread and i envy anyone who DID NOT have to live through (read endure) the Disco Era !!!!! very few of the 70's rock bands actually made it through those few years , mainly just the super groups (that were still alive) , since then i can really only think of one band that came out of the post Disco era that i would classify in the same catagory as the 70's super groups and that would be U2....
Dan
-
Fascinating... it bugs you too! I thought I was the only one. Someone should do something about that.
Stephen
One thing I would like to see is when you right click a class New -> VI that the vi would have the class controls and error clusters already on the FP.
Dan
-
Ok.... attached is my first try at using this OOP stuff.... can some of you look at it and tell me what i am doing wrong , this is based on hardware so you really wont be able to run it , but , you should get the idea.... it still needs lots of work , but , i figured i better stop now before i get too far into it and figure out that its all wrong...
dont be too harsh
Dan
-
anyone claiming to be past the learning stage of OOP with LabVIEW is not being honest with themselves.
Past the learning curve , hell i am still stumbling around tryng to FIND the curve
-
Lake Superior does not frezze over but around the edges its 15 feet (5M) thick.
No speed limits on the lake.
Ben
Previous resident of Duluth
Yes but when you crash do you call the Coast Guard or the Highway Patrol
-
Okay... I don't know if I'm having somewhat of a depressing day or what, but I was thinking of my experience, background and knowledge and was wondering what I'm "worth" to an employer as far as a test engineer/labview programmer.
I've worked for 3 different companies and have done LabVIEW in all of them. I've only ever had LabVIEW Basics I, but have been using learning and developing in LabVIEW since 1999. I've used LabVIEW with serial, gpib, vision, pxi, analog/digital I/O, TCP/IP & UDP etc, I've been using TestStand for a year now (no formal training) and have integrated LabVIEW into some pretty custom/complicated applications. I've learned a lot about LabVIEW software architecture and useage and am always eager to learn more. I would typically consider myself to be a "good", advanced LabVIEW programmer (compared to most of you guys, I'm not, but have been relative to the experience at some of my companies). I've designed and built test fixtures and done LOTS of engineering work.
But here's the thing... I have an associates degree in Fiber Optics and Electronics. I've been titled an "Engineer" at this company and my last, and have been told countless times that I perform well within an engineer's level, even moreso than some of our degreed engineers. Only problem is that my tangible "certifications" limit me career-wise and have often prevented me from getting jobs that I really wanted... including but not limited to self employment and NI Alliance partners. I'd LOVE to get a job with an NI Alliance partner because then I would be GUARANTEED to be doing just what I enjoy... LabVIEW and NI stuff. I would love even more to find a place willing to help fund my LabVIEW/TestStand development and even help me gain certification. I'm a quick learner, so this wouldn't require much patience. It's tough with my current job as LabVIEW and NI stuff involves a small portion of my job. I'd love it to BE my job. Hell, to get my current job I just about begged John Howard (former board member before he moved to the mountains... "JRH") to test my LabVIEW knowledge so that I could prove to him that I knew my stuff. (LV2-style functional global knowledge I think got me in
)I guess bottom line is that I feel like I'm worth something as a LabVIEW programmer/Test Engineer... but when I start looking at job postings and comparing myself to other LabVIEW gurus, it diminishes my view of my own competence.
On the plus side however... I can advertise myself like: "Get an Engineer's work without having to pay an Engineer's salary". Only problem is that I want the Engineer's salary, so that would only really get me in the door.
I'm sure if a potential employer were to take the time and sit down with me to discuss my experience and relative work-history and set degree aside, I'd be able to prove myself competent. Sadly though, you have to impress them enough on paper to even get to that point (interview). Without the often sought after line items (degree, GPA), it's tough to get.Bryan
i would have to agree with what Ben mentioned about looking at the smaller companies who dont have so many "filters" between you and the job you are after...
Dan
p.s. i am in the same boat that you are in , my title is Test Enginner and like you i don't have a degree... i have kicked around looking for a new job , but , as of yet i havent been to serious about it , i may be in the spring though...
Good Luck
-
Why does this NOT excite me?
Oh... I know why. Because Firefox was there first!
Dont woory in time you WILL be assimilated :-) they even got Picard and Data
-
Does anyone have a simple OOP implementation they could send me to take a look at .... i have gone through the examples etc... and for whatever reason i dont think i am "getting it"....
thanks
Dan
-
Damn! I learn something new every day! :thumbup:
Thanks Mike! :worship:
For grins, I pinned the Decorations Pallete, then with the Front panel active (Decorations Pallete visible) drag-and-dropped various decorations to the block diagram window. I got the No-Can-Do circle with slash, then let go anyway and still get the decoration on my BD.
Stupid is as stupid does... See this
I wonder if there is a LabVIEW.INI file option to enable the decorations pallete with the block digram active?
in 8.2 it doesnt give you the no can do circle when you drag and drop the decorations from the FP Pallete to the BD , at least it doesnt for me on XP.
Dan
-
Works like a charm. Sweet. Many, many thanks.
Regards, Denise
No Problem.... glad i could help...
Dan
-
Hi Dan,
Popping up "ROBO init" brings up a Robo operation.ctl that is not found (in ROBO Cylinder (VISA) folder). Any chance you have that handy?
Thanks, Denise
Ooops......
-
Hi Dan,
LV 8.2. An example would be lovely.
Thanks much, Denise
Ok here is everything i have to work with the ROBO's , you will need to change some of the defaults since you have a different lead length. the first 3 things you need to do is INIT, POWER ON, HOME after that you can do whatever you need. these VI's still need some work , but, they got me through what i needed , i actually want to try to re-write them using LabVOOP. if you have any questions feel free to ask.
good luck
Dan
Ok here is everything i have to work with the ROBO's , you will need to change some of the defaults since you have a different lead length. the first 3 things you need to do is INIT, POWER ON, HOME after that you can do whatever you need. these VI's still need some work , but, they got me through what i needed , i actually want to try to re-write them using LabVOOP. if you have any questions feel free to ask.good luck
Dan
Here are the the protocol manuals that i have in case you or anyone else needs them ....
-
Hi Dan,
Thanks for the amazingly prompt response.
Finally found the documment. (Their site is difficult to navigate.) I'm trying:
7) Position Inquiry
To poll the current position of a system addressed as #0 that has been homed to
the motor end and has a 12mm lead, send the following string:
Chr$(02) + 0R40000740008F + Chr$(03)
I'm sending this using the Basic Serial Write and Read at
38400,8,N,1, FlowControl=None, and a 1 sec delay before read. I've tried FlowControl=RTS/CTS. I've tried \n and \r\n.
Any suggestions?
What version of LV are you using ?? i will send you what i threw together to talk to these things....
Dan
-
There are a lot of broken links on their site, I could not get to the Serial Communication White Papers.
Have you tried Hyperterminal first? Proper serial cabling? Correct termination character used in LV?
THese cyclinder are really easy to deal with ONCE you figure a few things out , do you have the ROBO Cylinder Serial Communications Protocol document ?? if not i can scan it and send it to you....
Dan
-
Crelf and Mike,
What I want to do is to to take a bunch of data points on my N part and then a bunch of points on my S part, then calculate some statistical vaules such as max and min. So I used the Enabling Index concept and it seemed to work. However I kept getting 0 for the min and I am not sure why. Please help.
Meo Cop
Try something like this
Dan
-
I don't believe that the solution to your problems can be resolved with software...It looks more like a "dispcipline/responsability/maturity" issue that can only be resolved by a supervisor, or the supervisor's supervisor, or the supervisor's supervisor's supervisor...and if this does not fix the problem, then
i dont want top resort to that , but , i may have no choice...
-
heh heh heh Sorry Dan - I don't mean to laugh, but it's an issue that I'm sure all of us have been through at least once. I feel for ya mate - keep your chin up!
Chris
yeah i know , it just seems to be getting worse , i try to make my programs as flexible as possible so i dont have to keep editing etc... but it also tends to come back and bite me i the A** at times
ah well jus a couple more hours then it's :beer: time.... i think it may be a Guinness night after the past couple of days.
Dan
-
on the one hand, this a good idea, on the other hand, it is not, because, you add some extra difficulties to your development:
during development, it's easier to open an *.ini file with the notepad and edit some entries, than open regedit and edit data stored in the registry.
if your software is in production, it is easier to request someone, "plz send me the *ini-file, I need to see your settings" than to request an export from the registry.
maybe a combination of *.ini file and registry would be a good solution: when closing the programm, make a MD5 hash and store that hash in the registry. Then you can detect any changes and display a "corrupt file" message !?
cheers,
CB
I thought about using the registry but i really dont want to get into that whole mess... i am going to try the checksum for now and TRY to force the burden back onto them.... maybe , just maybe , they will learn if they get burned a few times...
luckily these guys dont fit into this category "Nothing is fool-proof for a clever fool." , but , i wish they would jsut stick to letting the program do what it is desinged to do , everything that needs to be done can be done from within the program i wrote....
oh well i guess it could be worse.............
-
I normally use readable files for configurations and the philosophy is that if a user wants to screw up the system he will be able to anyway (if he is not able to read the content of a file he can still change or delete it so encryption is not much help), the only important thing is to prevent him from doing so by accident. If he does delete or edit a file intentionally then that's his fault, not the software (you have to draw a line of responsibility somewhere).
You can off course reduce the risk by making the files less accessible and/or make the content look less tempting to edit (adding warnings within the files is an option). If possible the software should also be able to detect and filter out invalid configurations. I store most configurations in the Applications Data folders. The only time I use encryption is when I store information that needs to be secret (like passwords, proprietary parameters etc.).
Mads
ARRRRRRGHHHHHHHHHHHHHH.....
i had a long talk to the techs about modifying these files etc.... and explained to them that it messes things up when these files are played around with , and , guess what , you got it , they still messed around with them... rather than go through all the hassles of changing everything over to hidden and encrypted files i have decided to play games with the techs and put the burden back on them... i am simply going to add a checksum to the end of each file and check it when the file is loaded , if they dont match they will gete a message that the file has been changed and is now corrupt and a new file must be created etc... that way THEY have to go through tthe hoops and not me....
Dan
-
What do you want to do? You can monitor the bus with an NI-CAN card (and many other bus tools), or use an off the shelf reader to get the DTCs (Diagnostic Trouble Codes) or monitor various vehicle parameters.
Ideally i would like to monitor various parameters of the vehicle , at the moment all i need is RPM , but , as soon as we start this i know what will happen and they will want to monitor everything , i have run across this device http://www.drewtech.com/products/cardaqplus.html
which looks interesting. it actually will do everything i need i believe , especially with its 6 general purpose analog inputs...
Dan
The most totally awesome LAVA Members!
in Announcements
Posted
Chris
It is very obvious by your posting prowess on LAVA and the NI Dev Zone that you are a committed (or should you be committed
) member of the LabVIEW community. I doubt there are very many individuals that haven't taken something away from at least a few of your postings.....
Congrats , you deserve it :worship:
Dan