Justin Goeres

Bringing just a minor point over from this thread...

QUOTE(crelf @ Jun 18 2007, 09:38 AM)

QUOTE(Justin Goeres @ Jun 18 2007, 09:18 AM)

*

Unless you have an employment contract that prohibits you even seeing GPL code; I've heard rumors of some people in that situation.

I can tell you that I was told that a few years ago by one of the developers of MAME. At the time, MAME was considering (actually, in the process of) moving to the GPL. But then this dev took a job with Microsoft (they bought his employer) and the license change got killed because his new employment contract specifically forbade him from having any contact with GPL software in source code form. He also said he was not the only person inside Microsoft subject to those restrictions. Whether or not that sort of thing was practically enforceable was up for debate, but he certainly wouldnt've been able to contribute to MAME anymore, which would've been a disaster.

Basically, what it amounted to (he surmised) was that Microsoft was paranoid about being accused of misappropriating GPL software into their products. Sort of the "1% Doctrine" of software licensing . This was about 4 or 5 years ago now. I don't know whether it's still true.

QUOTE(Eugen Graf @ May 7 2007, 11:43 PM)

Thanks Michael, I need generally informations to publish subscriber in relation to Labview, how to and examples. Are there any? Or should I make me one myself?

Queues in array should be variant? I think, yes. A little example code, which only explains how to implement a easy one?

I regularly do something like this, but the term I use for them is observers. I have a hunch that Publish/Subscribe and Observer may have very distinct meanings in software design, and I'm not completely sure my term is strictly correct -- if someone has semantic arguments to make either way I'd be all ears.

I frequently use a variant queue, although it depends on the context. If all my observers to a particular resource will be getting the same type of data, I would typically define the queue for that data (and typedef the data). But in a general sense, the variant queue works fine.

I've hacked up a little example (in LV80) that illustrates basically what I do. This example has a simple "Publish!" button and an associated DBL value that is published to any of 3 registered observers. Each observer can be registered and unregistered with buttons on the UI.

Good Luck!

Justin

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

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

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

I'm looking for a tool to facilitate some online collaboration. Specifically, I'm looking for a virtual whiteboard. Something I can use while I'm on the phone to engineers/customers/whoever at a remote site that we can use to all doodle on the same canvas.

• Built-in chat is not required. That's what Skype/IM/the phone are for.
  
• Browser-based software is highly preferred over something the users have to download and install.
  
• Useful tools include freehand/line/basic shape drawing, arrows, and text annotations.
  
• Being able to upload existing images and PDFs would be very good.
  
• Ability to save/export the whiteboard and (preferably) reload it later is good (partially covered by the previous bullet).
  
• Cross-platform is good, but not strictly required.
  
• Cheap is OK. Free as in beer is good. Free as in speech is better.
  

The only thing I've found so far that seems to hit those bullets pretty well is Vyew, but I haven't tried it. It seems to be free right now, but they mention moving to a pay model for a "premium" level service in the future.

Has anyone tried Vyew? What do you think of it? What else is out there?

As a final note, does virtual whiteboarding software even work? I mean, there's no real substitute for standing around a physical whiteboard and screaming at each other, but do virtual whiteboards come close enough? If not, what do you use instead?

EDIT: I signed up for a Vyew account to play around and it looks like they've already implemented some of their "premium" level stuff. The free version still seems fairly accessible, at least for fairly simple tasks.

If you go into the "Plug in Preferences" (click the little button to the lower right of the movie), then uncheck "Play movies automatically"...

Whew, thanks. And since that's plugin specific instead of site-specific, it fixes the entire Internet! :thumbup:

Please, be patient while video (2.28 MB) loads:

Did the video auto-play for everyone else? It's kind ofprogressively more annoying when it plays every time a page containing it loads (e.g. on the front page, on the thread page, and now on the reply page). Apropos as that may be given that it's a Dilbert video ...

As a side note, in order to find it the first time I had to play whack-a-mole in a forest of new Firefox tabs I'd just opened. There was kind of an "aha" moment as I scanned through them trying to figure out which site could possibly have the video embedde... oh yeah, it's probably LAVA.

ARGH. I clicked "Preview Post" and it played again. Unsurprising, and ironic. And now it's going to do it again when I click "Add Reply."

but you do win a body shot at Coyote Ugly ;-)

God Bless Coyote Ugly.

This behaviour is described in the Vi description of the used vi ...

And now you know about the rocky on-again/off-again relationship I have with documentation

Any bitmap in LabVIEW can have 24 bits. And for importet bitmaps that are only imported to be placed on the front panel for instance, LabVIEW even allows transparency (GIF, PNG). Last time I looked (LabVIEW 7) the Picture Control itself did not support an Alpha channel (32bit bitmaps).

As a follow-up to this, here's an example of a 32-bit (RGBa) PNG image:

on a LabVIEW (8.2) front panel (1) as a decoration, and (2) loaded into a Picture Control.

As you can see, the decoration handles the alpha channel just fine. But the picture control appears to be thresholding it to a single transparency bit.

Transparent is: x1000000

Yes, but that's outside the 8 bits of space in the color map for the icons. Icon transparency is done by masking the 8-bit icon with (the envelope of) the 1-bit icon if I recall correctly.

What I was talking about is full RGBa 32-bit color. That's 8 bits of alpha instead of just 1 like the "T" gives us now.

Not that there aren't a lot of other things I'd like to see fixed/added in LabVIEW before that, of couse!

EDIT: Before someone else points it out, if I'm not mistaken we do have full RGBa color on PNGs when we use them as decorations. I don't have time to test out exactly where else we might or might not have that, but that's at least one place.

It looks like they're pretty much using the web-safe, 216 color pallete. There's a fantastic representation of it here.

Aha! That's it, then (plus 5 colors??). Thanks!

Which makes me think: would it be possible to exchange the color picker in the icon editor with something more useful, much like how Mike Balla's Icon Editor can be dropped into the right location to use instead of the default one? There's not a lot of reason to have a color picker with millions of colors if it only lets you use a few of them.

It depends on where the limitation is being enforced. If it's actually the _editor_ that's doing the color substition, then maybe such a thing would be possible. But if the substitution is happening when LabVIEW itself stores the icon bitmap, then I think we'd probably always be at its mercy.

Perhaps someday NI will just give us support for glorious 24-bit (no, make it 32-bits with an alpha channel!) icons for our VIs.... :thumbup: .

Ben,

I noticed similar things (and actually, 0 and 255 are multiples of 51 also ) when I decomposed PJM's and my colormaps into their RGB values.

Every valid channel value is some multiple of 17. This is slightly, but not entirely, surprising because 255 / 17 = 15 (which is hex 0xF). It's basically the equivalent of taking a 24-bit colorspace (8 bits per channel) and dropping the least 4 significant bits for each channel to get down to a 12-bit (4096) colorspace, then dropping a few more colors to get down to 8-bits-worth (255) in total.

I have a hunch that the 8-bit colorspace LabVIEW is using might be some kind of very standard one, but I don't know enough about this kind of thing to just come out and claim that . And then for icons they're just using a further subset of it.

FYI, the 16-color and B&W icon versions in the Icon Editor impose their own restrictions on the colors you can choose, as well. 16-color is (of course) a subset of the 256-color, and it's particularly humorous to use the color picker while editing a Black & White Icon (does anybody even do that anymore???).

I think you can use the attached VI to get access to the LV 8-bit color map. I think the colors are the same than the one used in VI icons, although I might be wrong.

Thanks! I checked the RGB values of your color map against what I'd generated. Your map matches what I'd found, but you indeed have extra colors (a total of 256). It appears from a quick comparison that the extra colors come from:

(1) A few extra shades of grey.

(2) The same few extra shades of each "pure" channel (e.g. RGB (136,0,0) -- a darkish red).

However, if you actually try to locate any of those colors in the Icon Editor color picker, you can't find them! Additionally, if you manually enter the RGB values into the color picker fields, the Icon Editor substitutes a different color to the one you picked! (It looks like it picks the closest one it can find.) This leads me to believe that your palette is the "correct" one, but that for some reason LabVIEW is restricting us to the smaller set of colors 221 colors I originally found.

I even checked this programmatically. I created a rectange of (136,0,0) and set a target VI's icon to that (via property node). When I open the VI's icon in the Icon Editor, however, the rectangle's color isn't (136,0,0), it's (153,0,0)!

It's all kind of weird.

EDIT: Here are the colors that you have in your map, but that you can't actually use in VI icons:

(Note that the last 5 elements of the last row are black and shouldn't really be there. They're just an artifact of reshaping the array so it's prettier. There are 35 extra colors total.)

I've been scrubbing over the color picker in the LabVIEW Icon Editor and have noticed something. When you use the color picker in the Icon Editor, even though your monitor displays a ton of colors, LabVIEW restricts what you can pick.

Along the "greys" bar at the top, there are actually only 11 unique RGB values you're allowed to get at. They are:

Grey RGBs

(0,0,0)

(17,17,17)

(51,51,51)

(68,68,68)

(102,102,102)

(119,119,119)

(153,153,153)

(170,170,170)

(204,204,204)

(221,221,221)

(255,255,255)

Likewise, in the "muted" & "saturated" areas (stealing my terminology from Christina), my manual scrubbing so far indicates that you're limited to any combination of the following hues:

Saturated & Muted RGBs

R: 0/51/102/153/204/255

G: 0/51/102/153/204/255

B: 0/51/102/153/204/255

If we calculate all the possible RGB colors we can select from these, we get 6³ = 216. Adding in the grey shades that weren't already duplicated in that calculation, we get a total color palette of 216 + 5 = 221 valid LabVIEW VI Icon colors.

This raises a question: Are these all the colors we can use in LabVIEW VI icons, or are there 34 more that I'm missing? The motivation for the question is that I'm trying to dither some images for use in LabVIEW icons using an external tool, and I want to do it right (LabVIEW's color substition is rather lacking).

EDIT: I generated a colormap of all 221 colors described above, as a PNG. Each color is a block (and black is duplicated a few times), but it's all in there. Just in case anyone besides me finds it useful:

1x1:

3x3:

File Name: ImageMagick Batch Image Converter VI

File Submitter: justin.goeres

File Submitted: 27 Nov 2006

File Updated: 12 Dec 2006

File Category: Machine Vision and Imaging

ImageMagick Batch Image Conversion Tool V1.0.1

Copyright

(If you're not using a LabVIEW-generated XML file)

I've had a pretty good experience using the LabXML toolkit. I had to move some files around to get it working (it didn't want to find a couple libs or dlls, as I recall), but once I got past that I found it fairly easy to use. I use it to translate the XML output of my bug tracker to generate nice-looking plaintext release notes.

Look what I found looking into the file lvapp.rsc (LabVIEW 7):

<snip>

I wonder if it is needed for something actually useful...

It might be an image bitmap. Anybody care to convert those ASCII values to an 8-bit picture control and see what colors we get?

Back in v7.1.1, I used to be able to create a reference to the Cursor Legend (an Array, as it happens) by right-clicking on the Cursor Legend of a Waveform Graph on the front panel:

However, if I save the code above (in 7.1.1) and open it in 8.0.1 or 8.2, the reference constant I created disappears and the code (rather obviously) breaks! See below:

The general question this raises is how can I programmatically control the properties of the Cursor Legend (now "Cursor Palette," I guess) in LV8.2? I've scoured the property tree and either I'm missing it or it's gone. Am I just blind?

I've also attached the VI file shown above, so you can play along at home. Open in 7.1.1 and it's all kosher. Open in 8.x and it's bad joss.

Justin

Download File:post-2992-1163018529.vi

I wasn't sure where to drop this topic (Hardware >> Macintosh, or is it Windows-related? ), so apologies if it's in the wrong spot....

I saw this thread about running LabVIEW on the new Intel-based MacBooks, but I have a different question. Has anyone booted Windows on these machines and tried to run Windows LabVIEW?

There are basically two ways to boot Windows on the MacBooks. One is to dual-boot, and the other is to run a virtualization solution (like something from Parallels).

I'm imagining that LabVIEW itself might run fine in at least one of those scenarios (as long as Windows is happy, which reports indicate it is), but I'd be more concerned about NI-DAQ.

Any experiences? Any hypotheses? Any brave souls want to give me a bag of money to buy a MacBook with so I can carry out this daring expriment... for the good of the community and all?

Justin

But what would be considered a quine in LabVIEW? In text languages, usually such a program has a string output that contains its code. But in LV, that's not possible (I think). I have developed a VI who creates a new VI with its same code. Does that count? What's my prize?

Since LabVIEW source code is binary by nature (rather than text-based), I think the only way a quine makes sense is if you generate the code into the development environment (e.g. via Scripting). Another idea would be to actually write the binary representation of the VI to disk. I think that would still qualify.

The trick, however, is that a true quine can't require access to its own source code to do its magic. I.e. a LabVIEW quine should run correctly even if its block diagram has been removed.

I'm not sure. It would be a pity some day we should start quarantining all VIs to be sure they have no malign code. On the other hand, the tools are there, easily available to everybody. And when scripting licenses become available, the possibilities will grow much further (documentation, access to all functions and objects...) :ninja:.

Exactly. Just because an idea or tool can be used maliciously, that's no reason for everyone to run away from it. Malicious code is a fact of life in every other language, and humanity still limps along in spite of it.

I suppose some day we'll all wake up and find someone screaming on LAVA about their whole project tree being ruined, and that will suck. But one could argue that having proofs of concept floating around would allow the LabVIEW world to prepare itself for that.

Justin

I've been rummaging through this idea and I have managed to create a piece of self-reproducing code (I have to admit it's no difficult). It copies it's own code in other VIs, then when those VIs execute, they copy that code in others, etc. As a concept I find it fascinating, but it's a little nasty if you aren't careful.

You're orbiting around the concept of a LabVIEW quine. I've been meaning to raise the same idea in this forum for a few weeks, but I wanted to play around with VI scripting a bit more seriously before bringing it up.

Quines are mostly an academic exercise (unless you're Evil... :ninja:), but they're really fascinating from that point of view. I'd love to see a quine done in LabVIEW. More importantly, I'd love to see lots of different quines done by different LabVIEWers. Care to share the code?

Justin

I've used the PCRE library for years in lots of contexts (including in LabVIEW back before 8.0). Based on that experience the attached code looks like a bug to me.

The regex ^$ should match a string that has nothing (the affirmative kind of nothing ) anchored to both the beginning and end of the subject, i.e. the null string. But the LabVIEW Match Regular Expression function returns a match offset of -1. It seems to me it should return 0.

Maybe the -1 match offset is technically correct (because the subject string is length 0), but even if that's the case it seems like Match Regular Expression should return some indication that it matched successfully.

I really liked how the old PCRE LabVIEW returned a boolean for "Matched?" instead of just the match offset...

EDIT: OK, here's what I'm talking about.

This is the same subject and the same regex, but the old PCRE library returns a successful match, and also returns the proper (strictly speaking) null string in the substrings array.

I now eat up recursive algorothms for breakfast...

I would like to further note that anything involving eating and recursion is just sick.

Well, well, well. We've hit on a topic here that is at the foremost of my thoughts lately. And of course, it all happens while I'm on travel and away from LAVA. :headbang:

I recently left an Alliance company to start freelancing. I've been doing LabVIEW for around 7 years now, and at my previous company LabVIEW development was my primary job, although I never got any certifications (took one TestStand course and enjoyed it very much). I'm considering it now, but I'm daunted by what the certs will do in the short term to (as someone else put it) my bottom line.

It doesn't particularly matter to me whether NI says I should or not. It's a matter of what the certifications bring me in terms of my personal and professional goals. So far, I have not had any experiences where I missed a bid or anything by not being certified.

Most of what I have to say has already been touched on by others, so I'll just make some comments

Bottom line, certification is an absolute must for anyone serious about calling himself a LabVIEW expert -- if only to understand the process and expose him to a variety of concepts. Certainly, I gained a lot by obtaining my certification (I am a CLA, and have previously held my instructor certification) -- I learned about areas of LabVIEW that I was weak in, and I subsequently strengthened those areas.

I strongly agree with this. The fact is that LabVIEW is getting really large and really versatile. I tell people that there are probably 1000 ways to do everything in LabVIEW, but that most of them are wrong. "Wrong" is subjective a lot of the time, but you all know what I mean. All of us homegrown LabVIEW jockeys have our own ways of doing things, and those evolve and grow as time goes by. (I, for instance, had a brief and torrid love affair with Global Variables about 6 years ago. It didn't end well.)

A lot of what we come up with is "pretty good." It gets the job done, it's probably fairly reusable (because Engineers Are Lazy), and it might even be efficient or elegant. But there are people better than us at these things. Some of their techniques are what NI teaches in the Cert courses. Why wouldn't it be a good idea to go to the mountaintop for advice? What's the possible drawback? I don't really see one, from a technical standpoint.

Another component it work very closely with experienced and learned LabVIEW developers/architects - when I was in business for myself as a sole trader, I missed out on a whole lot of intellectual stimulation and learning - there just wasn't anyone else to push me to think outside the box. If you are working on your own, not doing any formal learning and/or not looking for certification amongst your peers, then you might not be pushing yourself enough - there's so much out there to learn, and if you rely solely on what you know yourself and don't try to expand then I can't see how you'd truly grow as a LabVIEW aficionado - you're just treading water...

This is a great point, too. Part of my problem at my last job was that, as the only LabVIEW developer, a lot of my methods seemed OK. I guess they got the projects out the door, and I guess we made money. But I wasn't involved in the LabVIEW community, and I didn't reap the benefits of knowing where I stood relative to my real peers (the LabVIEW World, not the other engineers at the company).

I think Certification is a great way to maintain a check on oneself to ensure you're not getting tunnel vision (ha! A structure joke! :thumbup: ) about software engineering, LabVIEW, or your own abilities. It forces you to interact, and the best stuff happens when you collaborate.

You are still alluding to the same positive side that I am actually agreeing with you on. No, NI, being envious of MS for making "certified" people and making half the alliance members misfits seems unwise to me. I have seen other NI mistakes over years, I was a huge beta tester of TesStand and I advised tons of changes many that made it in. As to making misfits of alliance members because that is not the angle some wanted to pursue (certification) (not the learning or "good" you bring up) I don't see it. I have worked with certified alliance members too, some with good technique, some I simply would advise avoiding. I see it as a negative by NI overall, and really a MS envy type of play some manager probably got a bonus for.

I disagree with that. I think it's a bit cynical, although I'll also register my vote for (what I've been told is) the ridiculousness of the MS certifications.

I see it a different way. I think that we should be celebrating the fact that LabVIEW has finally reached a point where it's useful to have certifications. There are lots and lots of people using LabVIEW now, and the crowd continues to grow. That's terrific, but the problem (to hijack Jim's metaphor) is that as more people start to use LabVIEW, more people start to do it BADLY. Certification is a way of (A) standardizing practices that are known to be "good," and (B) differentiating the professionals from the rabble.

If there is a problem with NI's cost structure, that's a different topic. But charging too much or requiring frequent renewals (which I'd be glad to discuss) doesn't undermine the value of the certifications themselves.

My very next gig-- at a time when I was far less busy than I like to be-- was a client who wanted a simple LV program to plot some data from a PLC which was publishing the data to -- you geussed it-- an OPC server. "Sure, I've done that before." Got the gig.

This is an excellent point, and is a big part of the reason I'm leaning toward certification. I'm smart enough to know that there are still whole subpalettes hanging around that I've basically never used. Surely they're good for something....

Think of it this way, if you go for a job interview, you want to make sure your credentials are as top-notch as possible, right? So why wouldn't you do the same for your business?

Michael touches on an important point here. What counts is the credibility of the certs. For some companies, the certs are a joke either in terms of cost or difficulty. But in my experience, the CLAs I've met are without exception very, very good LabVIEW developers (that sounds way more obsequious than it's intended). That gives the certificaiton credibility, and if I see a CLA in someone's credentials I can be confident they know what they're doing.

Give it 10 years or so, when there's 100k CLAs in the world, and colleges offer CLA certification to all seniors majoring in LabVIEW. Then we can all complain about the good ol' days.

When I went at 8:30 in the morning with Rocky in the park 2 police cars pass me with the policemen looking at me.

In the park a secret police guy code dressed with brown pants, blue jacket looking at me.

At opposite side of the park a black Volvo and a guy smoking close to the car; of course I went to see the car and when I was closer the guy I saw he has a receiver in the ear. He started the car and left when I was 20 meters from the car. Was the same Volvo with the plate SE-FOOD but another driver (the other secret police guy was promoted after he watched me for 4 years).

When I arrived to the company at 10 am another Volvo (plate AWSC-750) with the flashing lights in the front of the entrance. When I left the company the Volvo was there with the lights flashing.

I think I know who can help you. Please visit this site. I suspect you will find you have things in common with these people.

You may also want to avail yourself of some of these fine products.

Cheers! :beer:

Justin

P.S. If people really are monitoring you or following you around, especially "secret police," you should really call a counseling service and speak with them. That's no joke.

Is it a game show any of us have heard of before?

-D

Maybe. It's Lingo, on GSN (Game Show Network). If you've got digital cable (or satellite) you're fairly likely to have it. In the Bay Area it's even on regular cable. I won a trip out to LA to be on a taping, after qualifying playing it online. It was an awesome experience.

The episode airs late next month. Like I said, I'll probably try to shop up the trainer program and post it here, and I'll include show details when I do .

(I suppose this thread is officially hijacked now )