Leaderboard

I've added this option to the Tools>>Options dialog for the next version of LabVIEW so it'll be easier to find.

I know, I'm flooding the forum today... I would like to share with you method for creating icons I invented recently. Up to now I used great Mark Balla's icon editor (and I still use it sometimes). But whole the time it was hard to remember which bakcgroud color and which abberation mean what, simply to fit on the icon all the information I need using only limited amount of text and few colors. Besides this I simply like graphics on icons. But preparing graphical icons using LV editor is time consuming as well as using external editor and copy-pasting (which often leeds to some confusion as LV uses its own 200+ color palette). What's more LV don't update smaller bit depth versions of icons - even if one don't care about them (who cares nowdays?) they should look at least different then default ones. To prepare graphical icons efficiently you have to have prepared common backrounds for projects or separate parts of code, glyphs for classes, glyphs for common actions as get, set, read, write, etc., glyphs for most important datatypes, some arrows or other symbols. If you have such a library (of course it is being created as project grows, parts may be imported from icon themes as Tango or Nuvola). I started this approach for the project I call temporaily LVODE. It is set of wrappers with some my code for Open Dynamics Engine (ODE) (BTW, I plan to relase it to public and although it is already pretty usable for me and even documented, I need some motivation to make it usable for others). I decided to use Inkscape - vector graphics editor. My icon development environment looked like this: I was arranging icon by few moves of mouse (when not creating additional glyph), selecting it and exporing as 32x32 png file with always the same name. For importing to LV I wrote a VI I put to Tools menu which retrieved current VI reference and used "VI icon.Set from file" method. Pretty efficient but there were 2 major problems: color conversion from 24-bit image to indexed color icon sometimes led to ugly colors and interpolation of vector-raster conversion often caused limited readability of an icon. Then I moved to GIMP. It is raster image editor, uses layers and has native indexed color support. I exported LV icon palette to ACT file, imported it in GIMP, so I was able to draw using target colors. The icon development environment looks now like this: Glyphs and backrounds are located in separate channels - I simply turn on/off their visibility, there is also a possibility for editable text layers. It was little bit tricky to find font and options to be able to write readable text with small font size. Now the best part: GIMP has so called Script-Fu - macro language to perform automated tasks. It also has Script-Fu server making it able to receive commands via TCP. So when the icon is made I do not have to export anything - just switch back to LabVIEW select a command from Tools menu and voila! Here is VI which do the trick: Maybe GIMP is not so efficient and elastic for creating icons as Inkscape was (belive me - I was able to prepare an icon with some glyphs and text in 15 s), but this is the price for guarantee of readability. Now one icon takes me 0.5-1 min and it is always worth that time. And I hope that some day my experiences and ideas will grow into new GRAPHICAL icon editor as fast and convenient as Inkscape and generating as nice effects as GIMP. ------ I was writing this post quite a long time uploading images successively as I was writing and after some time I wasn't able to upload anything more (Upload failed)... I had to start topic again. Is time to write the post limited?

I don't know what the "official" word is, but here are some thoughts from a hardware design perspective. They may not be good reasons, and they may not even necessarily be correct. 1) There are requirements on how much power we're allowed to draw from a PXI slot (I'm unsure how it compares to power from a PCI slot, but I would assume it is more because some PCI/PCIe cards require an extra power plug that their PXI cousins do not). Additionally, there are requirements on the chassis as to how much power they *must* be able provide to us. This means that when you drop $10k for a brand spankin new top-of-the-line oscope, you know that you wont have to worry about whether or not the overburdened power supply in your dusty 5 year old dev machine can handle it. 2) There are some requirements as to how much cooling each slot in a PXI chassis will get, whereas PCI slots are more of a crapshoot. It's possible to design a computer tower to have a rediculous amount of cooling for your PCI slots, but more likely you have an 80mm fan or two nowhere near your cards. Some devices, like high resolution DMMs, are heavily affected by the ambient temperature. 3) I'm pretty sure PXI is slightly wider, allowing for more space for components and such. 4) You can buy an 18 slot PXI chassis. Just try and find a motherboard with 18 PCI slots 5) RTSI cables are great for synchronization, but I believe there is a limit (due to signal integrity) of how many devices you can chain together. I'm also pretty sure that limit is less than 18. I'm sure there are more reasons than this, but these came to mind. That said, I currently own two NI PCIe cards and I love them to bits. Hugs, memoryleak Full disclosure: I'm sitting at my desk on the 6th floor of NI building C right now. P.S. surely there is a way to tag myself as being someone who is "drinking the koolaid"

Hi all, I was wondering if we should have a naming convention for VIPM packages made available in the Code Repository? For example, I see that Norm named his LV Speak package "lava_cr_LVSpeak" and I normally name mine using my last name (for internal references) "normandinf_lib_rcf_insert_typeconversion". While I understand that NI's and JKI's packages have the company name, I have no use of my name on the package name. It's already in the package description for copyright and that's enough. So the question/proposal is: should we have a standard for naming packages to keep our VIPM interface clean and easy to sort out? I'm thinking there's gonna be more and more packages when all the stuff in the CR will be made available in the VI Package Network someday, and now could be a good time to start thinking proactively. Any thoughts?

I'm to the point that I get annoyed if I have to code without it. That, to me, is the sign of a good tool.

I mentioned several potential improvements, so it's hard to say which one you're refering to, but here it is: Caption.Align.Left Label.Visible. Label.Change to easy to read font. Again, part of the issue is that with a parser, once you wrote the "change to easy to read font" VI, you can call it on any piece of text. The framework will need to be responsible for getting to the text part of the object. Why? If you know it's a parameter, just pass it as one into the align VI, which will attempt to cast it into one of its allowed parameters. For example: The first part is correct, although in this specific case, label is of the Text class which does inherit from GObject. You're definitely correct that finding the right type might be tricky. As I said, it won't necessarily be simple, but I think it's required in order to make it really useful (as opposed to the very useful it is now).

I have found that I can speak very quietly and still get picked up. None of my co-workers have started calling me crazy yet, so I guess it's not bothering them. My favorite part of this tool is the ability to quickly align code and labels in any number of ways. It saves so much time - especially when dealing with other people's code who might not be as fastidious as I am in keeping things pretty.

I think you should upgrade to the new version of LV when it is released. You might like it

OK, Something clicked with this while I was having my coffee and Vegemite on toast. I think your problem is that your dynamic vi has dependencies on LabVIEW vi.lib, user.lib or instr.lib. The runtime engine doesn't have the capability to include vi's that are outside the vi's root folder, ie if you call a dynamic then all the depenant vi's and ctls must be in the same folder or they all must sit in a llb. So what you need to do is in your project create a Build called a Source Distribution for your dynamic vi Beta.vi that will copy all the dependancies to a distribution folder. I've included an example in 8.2 that demonstrates this. DynamicCallDemo.zip Included is the source and a build that demonstrates your issue and one that resolves it. The demo is dependant on OpenG Lib so included is Packages.vipc use VI Package Manager to install the OpenG Packages you need. Hope this helps

Ok, was just about to detail it all out, but head to http://eyesonvis.blogspot.com/2009/07/lvspeak-automating-vi-development.html and the newest info/details are on that there. and once that's done come back here w/ questions Thanks, Norm

In that case, here's another iteration. CaseSelector.zip

Yes, let us know if you have trouble making this work. Here's how we do it with the JKI plugins in VI Package Builder: crelf's utility should do the trick. Let us know if you have any trouble making this work.

I've used the OCR from the NI Vision toolkit, it is quite good. It has a good training interface and good accuracy when trained well. I like using it with the vision builder interface to prototype. I've tried out various 3rd party OCR API toolkits too and found Transym OCR to work the best out of the ones I've tried. Both have a free evaluation period so you can try them out.