Val Brown

QUOTE(Ben @ Jul 17 2007, 12:25 PM)

I can hear the lawyers now "You want to copyright 'Loop'?".

Ben

Does it have to be copyrighted, trademarked or patented?

One call always do: "CompanyX's LOOP" as a copyright or iLOOP (if you're Apple) or maybe weLOOP...

I also always liked GOOP myself.

QUOTE(yen @ Jul 17 2007, 11:52 AM)

I vaguely remember having some problems with that (get serpdrv, put it in the right folder, watch it not working etc.), but the only thing I can say for sure is that the application was ported over to 7.0.

As you said, LV has the serial compatibility VIs, which maintain the old interface, but use VISA behind the scenes, but presumably they could disappear at some point in the future.

Actually what I'm talking about is using the legacy serial i/o VIs -- not using VISA. My deployed app, built in LV 8.2.1, uses the legacy serial i/o VIs and does not have VISA installed -- neither complete or runtime version.

If it ain't broke -- CONSIDER refactoring it as long as you don't "fix it" so well that it no longer works... ;-)

QUOTE(BrokenArrow @ Jul 17 2007, 11:43 AM)

Indeed, this old app uses the old serial drivers. It has to stay in 5.1 for reasons I won't go into here. Apparently, the old code does work on an XP system.

On a different application, when I converted it to 8.2.1, the old serial VI's caried over, but if you open them up, it's VISA.

Unfortunately, this one old program has to stay with the old serial port stuff (i.e 5.1).

I could probably have a good argument for taking the time to redo this old app in 8.2.1, based on the newer drivers.

What's the biggest drawback to the serial drivers of 5.1? I remember using them in 6.i, then switching over to VISA when 7.1 came out, but I don't remember the old stuff NOT working.

Richard

I have a slightly different perspective on this than do some others.

I would STRONGLY suggest using XP and maintaining the legacy serial driver routines (the ones using serpdrv). Not because they're necessarily better (there are problems with them) but simply because:

The code works using them.

Yes, I would update to LV 8.2.1 instead of keeping the legacy 5x code and, yes, it IS possible to still use the legacy serial i/o VIs in LV8.2.1 without using VISA. I do it with a large (1400+ subvi) project that I have developed and deployed beginning in LV5, all the way through the latest LV 8.2.1 release. Let me know back channel if I can be of any further help with this.

QUOTE(Ben @ Jul 1 2007, 06:22 AM)

Returning to the idea of perfoming unique calcualations and adhering to AE quote;

"The difference between genius and stupidity... is that genius has its limits."

Could the memory density of the human brain (# of meories/ volume of brain) be use to show that memories must be stored in an element smaller than an atom?

I was trying to explain what I understood of string theory to my wife and how it genearally fails to produce a prediction that can be measured. So I suggested if there was an experiment that could be performed it would have to be something that science would scoff at being rediculous. We eventually talked about clairvoiance and as being a possible manifestation of the interaction, possibly at the string level. Evetually the mechanism used to store memories came to mind and then I asked myslef the question above and thought "what better place to post a Q like this than "The 5th dimension".

Of particular interest is those of us that have photographic memories. Depending on the "resolution" of the memories, it would not take long to accumulate more information than there are atoms in our brains.

Ben

Look at the work of Karl Pribram on the holographic nature of memory and adaptive-gabor based nature of perception.

QUOTE(crelf @ Jun 30 2007, 06:51 AM)

That, right there, shows the difference between an engineer and a scientist

I remember when dynamical, 4D spreadsheets were first coming on line -- some what after RDBMs were deployed in a number of easily accessed containers -- and I had an interesting conversation with an engineer. He was looking at what he called "spreadsheet data" and was bemoaning how others were using RDBMs to model and perform ad hoc querries on the data. In his mind that was REALLY "spreadsheet data" and one NEEDED to use a spreadsheet program to look at it. The idea that other approaches could be used -- just as easily -- and could perhaps yield novel insights was almost an affront to him and his perspective.

So I'm not sure how you're parsing the space in terms of "engineer" vs "scientist" but I do know that alternate models can be very, very helpful -- esp where they seem to violate some sacred cow.

Could you repost that link here?

I'm going to disagree with the fundamental premise of this article -- I personally have NOT found any "added value" in using an off the shelf Source Code Control product. I am (essentially) a single developer (ie not part of an extended team) and, while I make use of consultants at times, the majority of those kinds of interactions occur episodically or in re: to small units of code. I use three different development systems and frequently change those out (any ways every 2 months); and am now simultaneously developing in Vista and XP, with one of my system being XP running within Parallels. I have several different physical backup that I use, including china copies and I rotate these on a scheduled basis. My major project consists of over 1400 subvis and I am currently engaged in a major refactoring/restructuring process in anticipation of the next major release. Partly this is because of the nature of the project itself, partly it's because of demands imposed by both Vista and the necessity of maintaining legacy support of XP-based deployment.

Now I'm not trying to imply that any of that mandates not using SCC per se (ie not using a particular SCC software package) but I am trying to give a bit of context for my comments.

I personally have found that the use of Subversion actually slowed me down and led to my losing some work. It did not help me and, while using it, I actually felt far less secure in my control of the actual source code and frequently quite frustrated with the overall process. Now I'm sure that others can argue that this was due to my unfamiliarity with Subversion itself -- I'm definitely NOT saying that it's bad in any way -- but no matter how true that might be, my lack of familiarity with Subversion misses the essential point that, in my case, it simply didn't add value to my work flow. And taking time to have it POTENTIALLY add value to my process wasn't a very effective use of my time at that piont. It just complexified my work enormously without giving me any direct benefit. As a contrast I have found the LV Project to be quite useful in a number of ways -- not so much as SCC per se but it is a "new" tool, with which I was originally unfamiliar, but have gradually grown to find directly beneficial and which was intuitively obvious enough to me AS I was learning about it, to be able to make use of it in some ways immediately.

FWIW -- and just to be clear -- I think that Subversion is a very good tool and I know an enormous number of people who use it both in and out of the LV world. I have and would recommed it to others who want to make use of SCC and don't want to have to pay a lot for that functionality. But it just didn't work for me. I may look at it again in the future -- when I am at a different point in the current work flow and can take time and space to really get to know it -- but until that time, I am reverting to my prior style.

QUOTE(Michael_Aivaliotis @ Jun 7 2007, 02:38 PM)

This doesn't make sense to me. A required input just indicates to the user that they need to connect the wire. The only difference I see is that in one case the wire is connected to the input terminal and in the other case it is not. Perhaps this makes a difference, however the "required" flag by itself does not carry any valuable info for the compiler. Of course, there may be some black magic that only NI knows but at face value, I don't see it.

If a required input/connector is not wired then you get a broken wire -- meaning, among other things, that the LV code can't be "compiled". I think Tomi got it right -- without a required input/connector a memory buffer is allocated. How much "real world" impact that makes in a particular project would depend on a number of factors obviously but, if the project were large enough, and the computing resource limited enough, it could be discernible...

At least that's the theory, or my story (so far) and I'm sticking with it.

QUOTE(Neville D @ May 9 2007, 08:55 AM)

John,

For a complete explanation see http://openmeas.blogspot.com/2007/02/la-mort-du-serpdrv.html' target="_blank">Brian Powell's blog

Serial support isn't being removed; just the ancient serpdrv with its potentially buggy architecture WILL be removed in a future version. It's only a matter of time.

All the issues that people have with the VISA serial implementation (licencing, size) have long since been solved. Time to move on.

Neville.

That's simply not my experience and, for that reason alone, I think it's important to NOT preclude access to serpdrv. Don't make it "easy" to use -- OK. Give preference to VISA in forums, etc -- OK. Don't support serpdrv -- OK, and nothing new. But what is the real reason that it has to be precluded?

If someone could answer THAT then I might rest a lot easier in this. But until then, I'm going to continue to be a small voice in support of continued choice -- even if it means knowing the back door means to use it.

QUOTE(crelf @ May 21 2007, 01:34 PM)

Kind of, but not really - sorry I'm being nebulous, and I'm busting to spew out all the info (really, I am), but I just can't.

I understand both the "busting" and the not telling MORE -- and I'm really NOT wanting to put you on the spot. The "kind of" tells me what I need to know.

QUOTE(crelf @ May 21 2007, 12:25 PM)

That is indeed a substaintial component of being a CLA, and explains one of the major differences between being a CLD and a CLA nicely Ben :thumbup:

CLAD = Know your way around the palletes, know the vi.lib functions, have a little LAbVIEW experience, can code up a small app - this is a good certification for those just out of uni - we have out interns complete at least this level.

CLD = CLAD + Can design/use existing design patterns (architectures), have a lot of LabVIEW experience, can code up a decent app (and quickly) - this is a good certification for most engineers - we have our Test Software and Integration Group engineers complete at least this level.

CLA = CLAD + CLD + Can take a complex set of requirements and efficiently deliver a solution that just happens to be developed in LabVIEW - this is a good certification for technical lead engineers - we have our technical lead engineers complete this level.

Might I offer another clarification here?

CLA = CLAD + CLD + Can take a complex set of requirements and efficiently deliver a solution that just happens to be developed in LabVIEW from a particular point of view, viz, the assumption of a team-based OOP development and deployment process.

Is that accurate? It is what is being implied, or at least that's how it seems to me.

QUOTE(Ben @ May 21 2007, 12:19 PM)

Please let me add to the above.

This thread asked how to prepare for the CLA and not how to become a super LV developer. I work with another CLA who had very little LV experience but has been working in large software developement for decades. He passed the CLA on his first attempt.

The CLA is not so much a test of LV Grand-mast level but more about the skills required to take a complex set of requirements and efficiently delivering a solution htat just happens to be developed in LV.

Ben

Thanks for the clarification. Can you further clarify the differences between CLA, CLD, CLAD and any others??? I'm asking for "real world" clarification here, because I've read the relevant NI docs.

QUOTE(crelf @ May 21 2007, 11:08 AM)

That's a common thought: why should I do all of this added work, when I know what I want to do in my head, and I just want to get into it and do it. For small projects that don't need to be traceable to documented requirements, then that's probably a valid path. On the other hand, when you do need to be tracable to documented requirements, and the architecture needs to me modular and easily upgradable, then that approach (although it will probably work) isn't the best way to go.

It may not, but (as an aside) there's nothing like working in a team to help you improve your coding - education can help you along the road, but IMO working with good LabVIEW coders is absolutely paramount to the development of a coder.

And I would add that working as a single developer, with worldwide demand, under time constraints to produce and maintain code that is technologically advanced, does something that no other code does, and does it easily for the end user, is a really great way to understand how to code LV effectively and efficiently! I wouldn't say that 1400 sub-vis, three out of proc servers and 34 MB of deployed code that needs to meet very specific demands is a "small project" that was just done "in my head".

I'm not saying the other isn't ALSO useful, good, important, etc but I am trying to provide (perhaps) just a little bit of balance to the "assume a team-based approach is best" for all development work except (very!) "small projects".

Can you reply to the rest of what I've asked about the relative emphases of the other levels of certification? With your experience it could be helpful to share what you can while still respecting your NDA.

QUOTE(nhollenback @ May 21 2007, 08:33 AM)

The best prep for the CLA is to read and know how to respond to the tasks and objectives that NI has posted. Even though they were developed from the previous VIE LV Adv. Application Development, NI stated that they still hold true for the current version. Go with this assumption, you are walking into a client site who needs your help on a project that will likely take 2 man years (or 1 woman year) of development. What is your software development process? How do you architect the code for multiple developers to implement various components? Like crelf said there is that wee little complication of the NDA preventing us from saying much more...

FWIW I think this is a very accurate description of the process, which brings up the following question? What about LabVIEW "...for the rest of us..." who don't work in/with large development teams?

Let me say this another way. Unless I'm wrong -- which I've been known to be on a number of occasions! -- it seems to me that a lot of the effort that goes into setting up a large development project for work by multiple persons, especially spread out geographically -- is not so intrinsically important when the development will be done by a single person. It also seems that, at least in a fair number of instances, the work needed or the large scale process may actually simple be "additional" and so take away from the actual development effort FOR the project.

I'm raising this because it's beginning to seem like there is a preference for a certain orientation even when it isn't clear that the specifics of that orientation will bring direct benefits to what we might call "smaller" projects, or projects that are implemented by a single developer.

I'm very interested in education but I'm not certain that treating all of my LV work AS IF it involved a team really helps sharpen or improve my overall coding. Perhaps it does, perhaps it doesn't.

What is the relative emphasis in the other "levels" of certification? Do they share the same "bias"?

Does anyone else have the same kind of question, or is it just me?

QUOTE(crelf @ May 17 2007, 06:21 AM)

That's a most excellent point: don't be extreme and think that having just an NI certification and nothing else will get you a job. We (generally speaking) hire only experienced LabVIEW programmers, and whilst a certification is a plus, there's plenty more hoops you need to jump through, including in-house exams.

<soapbox = TRUE>

FWIW I have experience in professional education and certification processes across a number of contexts and my sense is that, in many cases, the value of the certification lies with those who offer it, much more often than it does for those who obtain certification. Let me clear -- the paper itself really doesn't add special value to the person qua programmer or capable professional. Undergoing the process that obtained the paper MAY add value for the programmer/professional. And it may add enromous value in a number of instances; however, it is the PROCESS that counts -- NOT the certification.

Does the process of pursuing certification re: LV actually add to programming expertise in LV? That's an empirical question which could actually be answered -- if the desire was there in the community of LV programmers to have that answered. However, it seems highly unlikely for that effort to be undertaken and, of course, there are many reasons for that but I want to focus on just one -- the issue of who sets the criteria for determining expertise? It is THE fundamental question.

I'm a pioneer in the field of neurofeedback and have been for the better part of the last 17 years. The issue of certification is raging now in that field, primarily as a context for pushing a particular agenda re: credentialing and to instantiate waht amounts to a "guild". This agenda is pushed under the guise of "education", "setting standards", "increasing effectiveness and safety", etc, etc but it's really about a kind of elitism that some want.

IME that push is fundamentally off target in the field of neurofeedback, as it is in a number of other fields.

Is that the case in re: to LV certification? I don't know but in reviewing the posts on this topic here and elsewhere, it's pretty clear that there's a large and obvious divide between those who think that certification is a good and/or even necessary thing vs those who think that it has little practical value for them qua certification. Those involved in large scale project environments support certification and I think that's in line with a lot of what appears to be covered and seen to be of high value in the certification process. Those who work independantly and/or who work on projects where scalability is not a preeminent concern, perceive less value in certification process.

Re: courses -- I have also attended a number of NI courses and events. Some were quite good, some weren't good. That's how it is everywhere I guess.

Re: abilities to program in LV -- I'm the programmer for our application in applied neurofeedback and offline analysis of EEG. I use the DB Conectivity toolkit, the Advanced Signal Processing toolkit, Internet Connectivity, etc, etc and I use them in ways that others have said were "impossible". Perhaps I'm really lucky!

I suspect that I won't pursue certification but who knows? For me it would be about education and seeing what others are doing with LV.

<soapbox=FALSE>

QUOTE(Gary Rubin @ May 16 2007, 11:08 AM)

Do you hafta sing too?

I wonder if it helps to sing like Betty B-OOP... ;-)

QUOTE(Val Brown @ May 15 2007, 05:36 PM)

I'm having what may be a related problem with my application (built in 8.2.1) throwing error -823, related to lvalarms.dll as a support for timed loops. I'm trying to factor out whether this is Vista/XP or 8.2.1/8.2 or application build specification determined.

As a follow up, the same project built in LV8.2 throws this error on 8.2.1 as well as 8.2 systems.

Curiouser and curiouser....

OK my problem is separate and had to do with an out of date lvalarms.dll on the deployed systems.

I'm having what may be a related problem with my application (built in 8.2.1) throwing error -823, related to lvalarms.dll as a support for timed loops. I'm trying to factor out whether this is Vista/XP or 8.2.1/8.2 or application build specification determined.

As a follow up, the same project built in LV8.2 throws this error on 8.2.1 as well as 8.2 systems.

Curiouser and curiouser....

QUOTE(Michael_Aivaliotis @ May 7 2007, 09:12 PM)

Steve Jobs is an iWitch

<object width="425" height="350"><param name="movie" value="http://www.youtube.com/watch?v=xgZKjJt-TkU"></param><param name="wmode" value="transparent"></param><embed src="http://www.youtube.com/watch?v=xgZKjJt-TkU" type="application/x-shockwave-flash" wmode="transparent" width="425" height="350"></embed></object>

iSee, iHear, iLaugh...iFallOnTheFloor and iCan'tGetUp.

QUOTE(JFM @ May 7 2007, 04:51 AM)

Hi,

LV Punk is correct in that the easiest way to do this is to simply enter a smaller value to the right.

You can also open up the properties dialog for the slider, and mark the scale as inverted (the result is the same)

http://forums.lavag.org/index.php?act=attach&type=post&id=5749

/J

Thanks for the follow up posts. Somehow I didn't see them when they came in and ended up calling NI for support. I got the same idea from them and the odd part is, I didn't even think of such an obvious option. I was looking for a property node or something -- and I didn't see any particular reference in the documentation. Oh well, frequently it's far simpler than you (or at least I) think!

Now I'm looking to make some further modifications to the slider images so that they look like brackets or a "box" when close enough together. My sense is that I may need to go to an XControl but, as I posted elsewhere, I've not seen a fully enough developed example of an XControl that modifies its appearance (among other features). In any event thanks for the follow up. I'm going to do some further digging/playing and will post on this additional idea presently.

QUOTE(Val Brown @ May 9 2007, 02:24 PM)

I just noticed the idea of using inverted but, when I tried that (originally) it didn't reverse the scaling.

I'll see if that's still reproducible on my system(s). Given how hectic it's been here lately it may very well have just been a visual hallucination on my part.

QUOTE(kai_n @ May 8 2007, 01:00 AM)

Sorry for answering so late. I found a link some weeks ago giving some VI-files and a dll-file, which has to be given away with the final application. In my Eyes, these VIs are even better than the original Labview ones. Just check them out!

http://www.mhst.de/downloads.html''>http://www.mhst.de/downloads.html' target="_blank">http://www.mhst.de/downloads.html

Thanks for the reply. Yes, I had already tried that code and, as I indicated in a reply further up in this thread, I ran into some problems with that code and could not get it to work. I still haven't been able to get that other serial code working -- for whatever reason -- but the good news is that the NI legacy serial code was successfully used for a deployed version built with LV8.2.1. AND, that deployed version works in XP as well as in Vista.

I have a request for a "reverse" fill control -- ie one that has its scale moving from right to left instead of the more standard left to right. And I'm having trouble seeing any really good way to implement this request.

I know about the fill options and how to use those -- as well as negative values -- to have the APPARENT fill move right to left, etc, but none of these methods actually reverse the entire control and, thus, leave the scale intact, ie oriented left to right.

Does anyone have any ideas?

QUOTE(Pablo Bleyer @ May 6 2007, 06:19 AM)

IMHO, if you are not having major problems with 8.2, I'd suggest that you stick with it and avoid 8.2.1. One of my reasons to update to 8.2.1 was that rings didn't allow elements out of sequence, and it was a hassle to translate ids from/to case statements. Also there are other annoying problems with controls. I've found that 8.2 is far more stable than 8.2.1.

Regards.

I tried copying the VI contents to a new one and I still can replicate the problem. Don't know if copying everything would fix the issues, though, in the event that that is the case (maybe the error is sticky). But I don't think a corrupt VI is the problem, because I am working with several projects and have had crashes in all of them. I only used recovered backups once.

Anyway, never seen this before, but... is there a way to inspect the contents of a VI and perform a consistency check?

Regards.

I've also had crashes on "ThEvent.cpp" and "memory.cpp", and yes, even with tiny VIs like yours. I guess 8.2.1 was not thoroughly tested.

Regards.

I'm just not seeing this at all and am actually quite intrigued at your report, esp re: controls. Can you post some code that consistently crashes?

Yes, I use large data sets, JTFA toolkit for real-time processing as well as offline analysis, etc, etc. And as far as size of my final application goes -- how does one that 33 MB, with two out-of-proc servers and WMP being called?

QUOTE(Pablo Bleyer @ May 4 2007, 01:05 PM)

Ok. I am starting to regret having upgraded to 8.2.1. It is crashing on my machines almost on a daily basis with my current applications. Before I submit a report to NI, is anybody else having problems processing *big* data files into LV and displaying it in graphs? (See attachment). After working with the resource hungry 8.0 and 8.2 series, I have a deep longing for the stability and reliability of the old LV versions... In fact, I am seriously considering downgrading to 7.1 at this point.

Regards.

I suspect this won't be of any help to you at all but I'm not seeing this kind of behavior. I have experienced no crashes with 8.2.1 and that's both on XP as well as Vista platforms.