Black Pearl

Does it also relink as painless if you need to revert to an older OpenG-set residing in user.lib? I guess so, but I don't kown the internals how that automagic relinking takes place. What about the rare situation someone has installed an older version manually (copy&paste) instead of using VIPM? Then we could have an old vi with the same name in user.lib. Do we get a preference on vi.lib or does it happen (even if randomly) that we get a link back to user.lib? Had to many relinking troubles in my life... Felix

Concerning CC/BSD. As far as I have read this, we should normally use a software license like BSD, GPL, .... The CC licenses wher designed for non-software products (artistic) with the experience of OS software. Just think about warranty declarations, bad art work hurts the eye in a much less painfull way as if someone reuses your OS software code for eye surgery. Of course you have an 'interface' field where both go together, this is where you need a compatibility of both licenses and/or need to pass the CC license to the end user, e.g. when doing UI-reuse libs. Felix

As an end user of OpenG, I would prefer a simple instruction on how to deal with the license. Instructions/Suggestions where to copy/paste some text, e.g. 'if you write a User manual or help, place the following text under copyrights'. Concerning the names of the OpenG developers, could that be a simple similar to: This product uses OpenG. Visit OpenG.org for more information. Contributors: name1, name2 I don't see a problem if I don't use any VIs written by name1 but mention him in such a leagal document. Wouldn't it be the a similar situation as using a dll and never calling any routine written by developer1? Felix

At first thank you for supporting OpenG. I'm stuck with old 7.1 so my question, if it's posssible to get the code downgraded? I promise to do testing and to ask for an upgrade as well. Felix

I assume the queue might be better in performance. More use cases (SEQ, producer-consumer) -> NI put more manpower behind the optimization code -> better performance. I think 8.5 it was a big marketing about Qs and multicore performance, they never adressed notifiers. But might be completely missleading, as a notifier only needs 1 piece (the current piece) of data while a queue might queue up (as the name suggests), so those optimizations would be unneccesary for a notifier. Felix

No. Dreamed of broken resistors. Didn't replace a schematic. Wish you better dreams. Felix

Just some unqualified basics from my experience. I care about EE safety in germany (little experience from my side and tech not legal dep), so might be different with american steam engines . But statistically touching 230VAC is giving you a chance of about 2% to get killed. For the legal issues, you have 'employers responsibility' for anything that happens (in germany: BGV A1 and BGV A3 for EE). So for me, if someone is killed by bad electrics I produce, my boss (= employer) will hang. If he has no idea about EE, he can delegate this responsibility to me (in written form -> vEFK=responsible electrical skilled person?). Note: not written -> no proof in court! And as an vEFK you should get insurance like management (you actually are in this position -> you are the leader of/responsible for all E-staff). But this actually is designed for big companies. So normally (I don't think most do, which is actually illegal) you outsource this to an electrician who takes care about DIN VDE 701-702/BGV A3 regulations. A second legal aspect is, that you get exemtions for small companies, e.g. a risk analysis of a work place is necessary for companies with more than 10 employees. And finally, I can mix everything to make it more complicated. In europa, you have two different norms covering machine safety, one electrical and one mechanical. Doesn't work in practice, because you need electrical signals to transmit the emergency off to the motor. So you need to conform to one of these, not both. All confused? Well, I read 4 books about the tech stuff for safety, and above is a short summary. In germany, we have an institution called 'Berufsgenossenschaft'=BGV (yep, that's equal to the BGV from BGV A3), translator gives me 'employer's liability insurance coverage'. I think any company is required to join one of them. And they need to pay for any accident I get at work -> they don't want this accident happen -> ask them about necessary safety requirements. A lot of safety concepts I learned was from their publications. I don't know if you can go for a similar institution, otherwise I'd just get a lawyer specialized into this -> half an hour isn't much money, and he has no interested in selling you much insurance! Felix

I'm developing a LED based light source (solar simulator) for the photovoltaics industry and research labs. Public information is available in this scientific publication. Felix

I second Daklu. After all, we have an undo operation. Maybe we can just have a checkbox 'do not show this message again'. And make sure there is an ini file entry for this, so we can keep this setting across machines by simply copying the ini file. Felix

I havn't used Ton's API, as I wrote my own (less complete) at the same time. It is useful if you use some automated process (e.g. build scripts). For my reuse packages, I use a pre-build hook in the OpenG builder to extract the log from hg and create a LogFile.txt that is deployed with the package. Also, I have written (but I don't really use them) small vi's that allow you e.g. to rename a vi (save under new name + tell hg that it's renamed) and the like. Didn't had the time to continue on this. But for integration of hg with the LV-IDE, you need the API. Felix

Depending on the complexity of the problem, I also start with pseudo-code. On the more detailed level, I keep an uml model together with the code. For state machines, at least a bubble and arrow diagram (using dia, OpenOffice/MSOffice, or simple a paper) will be my starting point. Both get pasted as pictures on the BD. The most 'primitive' form is a simple comment on the BD as Val pointed out. I think this practice is 'good' and even is encouraged by NI for the exams (I think you get points when just commenting 'this vi will save the data' as much as coding it actually). Those design comments also serve as documentation later. Felix

Offline commits sounds interesting. The main troubles I had with SVN is to manage changes I coded at customers location. At least took me a frustrating half an hour or so. Using mercurial (and above article statesit is pretty similar to git) did resolve these issues in an elegant way. It proved to be robust enough to accept copy&paste behaviour instead of the correct push&pull way to sync between the hard disc of the dev PC and the USB Flash drive. Having to deal with possible IT infrastructure changes, I'm glad to rely on a tool that will be able to adapt to those changes very quickly. I'm unsure if SVN will be able to catch fully up yet with the robustness I found in mercurial. Concerning binaries, the members of my team doing electronics use mercurial as well. And I think they were transfering their schematics and layouts via USB from one member to the other as hg repositories, as available manpower and project timeline did require. One thing we do is to reflect the modules in the system and not the complete system (doesn't really make sense to store electronics design and software/code in the same location/container), and keep those small enough to be managed by one person and passed along quickly. Second we have a very fast and direct communication inside the team, so we actually very much fullfil the requirement of 'collaboration' imposed by DSCVs. It's pretty much an evolutionary process you can have in R&D teams, but might be problematic if you need to manage production throughput or document formally (documentation is always worth the effort, even in case of failure) to fullfil regulated industry standards or the like. Felix

Difficult to say, if I'd follow AQ, a must have is the hitchhickers guide. On the practical side, I found it difficult to get a book with the reason that I'd like a library on my workspace. The promise to get a new worker addicted to LV gives me a free wish-list on LV-books, and let them do their own selection some more. But actually, there aren't many books on LV, and I don't use any of the other exept the two you mentioned. Look at the projects you like, get some domain information. I've got a cool set of EE books. My bedtime lecture at the moment is (rough translation from german) 'electrical equipement of machines and machine-like installation' from VDE explaining the DIN EN 60204-1 (VDE 0113-1). Stuff you need to know when you wire machines instead of SW. And, I don't think books are too important. I've tons of sientific papers I could download from the net on the subjects I had to deal with, and even greater: you can find some stupid videos on youtube. Stuff with less than 1k clicks that demonstrates you a electrical control cabinet and the like. Would have been propably cheaper to invite me to their fabs instead of producing the video. (no, I don't link it, after it's has more than that 170 clicks!). Please note that I was working over the weekend (you can guess what I had to design from the text above), so I'm a bit dim in my brain. Felix

I'd say templates are the way to go with VI scripting. And copy/replace operations. If you need to create things completely by code, you need to write a lot of code. And most of the time 'useless' code just to make the created code look nice (minimizing wire bends). You can take a look at my latest project here. I think about 50% of the scripting-related code is just to get the wires redrawn as they were before. Felix

You need to enable VI Scripting in the options to have methods/properties for this. (LV2009 and later). If you open the BD of a protected VI without a correct pswd, you receive an error. Felix