Mr Mike

I'm building my own adapter. My girlfriend is studying at Sciences Po for her third year of law school. NI will allow me to work remotely for 9 months. With that perspective, it's not hard to figure out where I'd choose to be.

I thought you might say that. The two plugs I have actually swap the live and neutral. Wikipedia says the plug is polarized. Guess not. I know that since it's AC it's not a big problem, but I'd rather be right. :-)

DISCLAIMER: THIS IS A PERSONAL REQUEST FOR HELP HAVING NOTHING TO DO WITH NATIONAL INSTRUMENTS. I'M ASKING YOU TO STICK METAL THINGS INTO OUTLETS, SO IF YOU'RE NOT 100% SURE OF WHAT YOU'RE DOING, DON'T DO THIS. I'M NOT RESPONSIBLE FOR YOU HURTING OR KILLING YOURSELF (OR YOUR EGO). I'm moving to France for 8.5 months and leaving in 3 weeks. I have two CEE 7/7 plugs that I'd like to wire up to a NEMA 5-15P female plug. I'll then connect a US-style NEMA 5-15P power strip to the female plug. This is safe because all of my electronics automatically switch between 120VAC/60Hz and 240VAC/50Hz. I did it before in Italy where the outlets didn't have a polarization, so there was no question of polarity. However, I'm going to France now where you apparently have CEE 7/5 receptacles. I need to know what your polarization is. So, if you have a handheld DMM and you understand what you're doing, would you go plug it into your outlet? Please consider this socket and tell me which is the live and which is the neutral? I know the center (higher) prong sticking out is the ground. The voltage across the live and ground should be about 240VAC. The voltage across the neutral and the ground should be almost 0VAC. DISCLAIMER: THIS IS A PERSONAL REQUEST FOR HELP HAVING NOTHING TO DO WITH NATIONAL INSTRUMENTS. I'M ASKING YOU TO STICK METAL THINGS INTO OUTLETS, SO IF YOU'RE NOT 100% SURE OF WHAT YOU'RE DOING, DON'T DO THIS. I'M NOT RESPONSIBLE FOR YOU HURTING OR KILLING YOURSELF (OR YOUR EGO). Edit: I know there are power adapters, but what else am I going to do with these plugs? I picked them up years ago in case I ever went to France or Germany.

I think NI shares a lot with the community. There are a lot of internal details about LabVIEW in the NI KB. There are special INI tokens documented, how we flatten data, how LabVIEW behaves in a lot of solutions. You might want to look through some of our KB articles if you're curious about the internal workings of LabVIEW. However, I do not think that alpha releases are for incomplete features. Just because we have a feature that's half-done doesn't mean that everyone should be able to use it. There are good reasons we don't finish some features -- they aren't stable enough, they're too resource-expensive, they don't meet the needs of our customers, etc. If we release a feature, we will support it. We still support some decade-old hardware. NI has great technical support. But we can't support everything. I don't speak for NI, but I suspect we would rather support everything we release rather than release everything and have holes in what we support.

No. There is no chance at all that we'll release that. I will tell you that it's titled Primitives for Dummies and has at least a dozen pages. The only part you're wrong about is the watermark on every page. I should point out that the document starts with "Tremble young seeker for thou art entering a secret chamber in the LabVIEW shop of horrors." I don't have much more to say about this except that we keep parts of LabVIEW private because they are not ready for use by the general public or even experimenters. If you want to experiment, I suggest you check out NI Labs. I think it's great that you want to experiment, but there are a lot of Bad Things™ that can happen. You can corrupt VIs and not get them back. Or the corruption may have no effect for a long time and then suddenly things start to break in unexpected ways. I'm not telling you to protect you or because I feel NI is threatened; I'm telling you because there's the potential to break things for you, and other people if you release tools that use unstable, unreleased features.

Yes. A new VI takes a few minutes to develop. A new node takes a few days at a bare minimum for the simplest node: type propogation, compiling, marking which inputs are in place to others, adding documentation, potentially marking which versions it's available in, enumerating each of the terminals, potentially adding properties and methods, maybe making it support different types (do you have any idea how many numeric nodes support clusters of numerics?), building the intermediate representation for the compiler, building the compiler code for it, etc. Plus all the time it takes to actually compile LabVIEW. Plus time to check for type-safety bugs (e.g. dereferencing null), save for previous, etc. LabVIEW takes care of all of these things for VIs. We have a document for creating new primitive functions that is 12 pages long because there are so many different things you need to worry about. Creating nodes (which are more complex than primitives) is much harder.

The LAVA BBQ is a great part of NI Week. I just bought my ticket!

The Matcha Design blog has an excellent series (1, 2, 3, 4, 5, 6) on generating QR codes. I've used it to develop all of what I've got so far, but there seems to be something wrong during error correction.

Haha, I just realized that. I read it so quickly before that I completely skipped the first half of the sentence! I'd use the oops smiley if I didn't think it was obnoxious Darin, check your messages

Yes, but did you make that with LabVIEW?

Wow...I don't know how I missed that. I'll take another look at it in a few days.

I didn't dig too deeply, but I'm 95% sure that the worst thing that will happen is you might get an extra recompile when loading the VI. The remaining 5% is a suspicion that you'll get some wonky behavior in your class in terms of what VIs belong to a class that will get fixed when you change the VI in most ways that would require a recompile. I'm pretty confident it's safe to overwrite that value.

This one always confused me. It seems to be different for each VI. But I never went and tracked down what it meant. Now that I went and tracked it down, it looks like we use it to help decide if we need to refresh the connection between the VI and the class. I'm going to check with some people who know LabVIEW Classes better. I think it's safe to overwrite those numbers, but I'm not entirely sure.

LabVIEW does not allow recursive type definitions. You can have objects of parent types in a child class, but you cannot have a class contain itself.

I've done most of the implementation for supporting QR codes, but I'm having a lot of trouble generating the error correction codes. There are four error correction levels (L, M, Q, and H). 100% of my tested QR codes have the correct error correction for Q and H. About 50% of M codes have the correct error correction codes, and none of the L codes have the correct error correction data. I can't figure out what's wrong with it. Does anyone have experience with generating QR codes? I've looked at some other implementations (MIT license only -- I'd like to stay away from GPL code just in case), but their implementation is very confusing to me.

No, there's nothing about LVOOP property nodes that prevents them from being inlined. The only reason (that I know of) that it's not done is because we haven't gotten to it yet. (Edit: there's some work in handling the new inlined node type, so it's not just a matter of flipping a switch)

This isn't so much of a trick as it is a manifestation of two cool features that aren't really advertised: If you copy FP / BD objects it puts a picture of them on the system clipboard and it places a copy of the objects themselves in LabVIEW's internal clipboard. You can paste from the system clipboard in the icon editor.

I've done it before using .NET methods. I don't remember where I did it, so I can't give you a copy. It's fairly easy to do if you just port the .NET example to LabVIEW.

It's a combination of the price and time. I (the author) work on the LabVIEW Language team and developing libraries for users is not one of my job responsibilities. Most of the work on the bar codes is done during my free time or on our free form test days. I recently added (but have not yet cleaned up / tested / published) support for PDF417, which may be an acceptable alternative to QR codes. I noticed recently that tcpdf supports QR codes and it's distributed under the LGPL. I may be able to port it, but it's not very well documented (and neither is the source of their QR code support. It seems like a very complex bar code from what I've seen, so I'm not optimistic about being able to implement it quickly. (I'd also need to double check with NI's legal department regarding porting from LGPL code)

I think it's possible in any version. I did a quick test and it looks like you should be able to call resource\Framework\Providers\VILibrary\LIBUIP_Properties_Dialog.vi with a reference to the new class then it will do exactly what you want. You just need to invoke Save after the dialog closes.

I'm pretty sure you can hook into the New... menu and can control where in the project item is added. Is there a reason you didn't add the item to the New... menu? That's where I would expect to find it. (I know that everything in the New... menu is added to the project item that is selected and this would be different. But that's still where I would expect to find this.)

The main reason that you can't debug into class property nodes is that we didn't have time to implement it.

Ton, I took another look at this and I saw that the default mode for encryption is Electronic Code Book. I think that following secure by default guidelines, you should set the default mode to Cipher Block Chaining. I'd also suggest you change the default value of the enum to be CBC instead of ECB. I recently wondered if there's ever a good use for ECB. Sometimes there is, but using it is almost always it's a bad idea. I played around with it a bit and I was very confused about how to enter the key and IV. My comments about data as strings apply less so because I learned you're using a string to represent a hex value, which is then converted to arrays of U8s. To me, it would be much simpler if the plaintext, key, and IV all were arrays of U8s. I think the IV should be required.

Sounds like a network stack issue. What OS are you running? Is this your problem?

Right now we're not planning on sharing the how you can deprecate properties. However someone posted the idea on the LabVIEW idea exchange.