crelf

Ummm, the code that I'm writing for the presentation... Yes, it'd be great if there was a central replacement for the current error handling schema, but I'm presenting a method of extending the current native implementation into something more comprehensive. NI doesn't have to do it, although I'm hoping that the result of my presentation will be community discussion and perhaps the design of a new schema that NI might want to adopt. NI certainly isn't against the idea of us helping them grow their product, and this is an opportunity for us to tell them what we don't like about the current implimentation and give constructive ideas on how to make it better - I figured the best way to do that was to build something ourselves that will either be leveraged directly by NI because of how awesome it is, be a catalyst for something else due to how okay it is, or be a warning on what not to do based on how crap it is.

Any chance of recording and uploading it? Or, at least, the presentation file?

Right - and that's what I'm working on - a base "error" class and an "errors" class that is a collection of "error" objects with some extra stuff thrown in. You're right, but I haven't designed it that way for a couple of reasons: I'm under a wee bit of a time crunch, and I'd like this paradigm to be a community-driven effort after the initial paradigm idea is presented at NI-Week. I am toying with uploading a good chunk of the code here, but I don't want to derail my NI-Week preparation schedule with too much stuff. Another great idea. I've created methods that convert native to verbose and vice versa (I'm calling the new structure a "verbose error" - anyone got a better name?), but it would be great if, sometime in the future, this process were to work automatically. That said, since we'd need to essential wire the verbose error list around native subcomponents to preserve the upstream error list, I'm not sure how this could be done without it looking a little icky. I like how the combine waveforms thingy is automatically added when you try to wire two waveforms into a log to disk express VI (or the like), and that technology might be an appropriate implementation to use, but this is all stuff that I'd like to talk about after NI-Week.

Almost - we only secured all the image files this morning, so expect to see it onsale sometime today.

You're right - I should have mentioned that it's an LVOOP object.

So I'm putting some work into the presentation, and I want to share an error structure that we came up with. Rather than the three elements in the native structure (status, code, source), we thought this was a great opportunity to expand that to include some of the items that we see all the time. Here's a idea that I'd like to present without comment, because I'd like to hear what you love/like/dislike/hate without me skewing your responses: You've got the native three (so you can be backwards compatible), plus a few extras: Time Stamp = when the error entered the error handling subsystem (or, alternatively, you can set this using a public method) so you can handle errors with respect to when they occurred. Classification = categories: DAQ, UI, File, Database, VISA, etc Priority = set a number here so that errors can be handled with respect to their priority. Front Panel Title = notice that's the title, and not the name of the VI? Just so we can identify a VI that's either a dialog and/or had it's title dymamically changed. Ever had a situation where a user complains of a phantom error that they just clicked "OK" to? CallChain = this is, we'', the callchain Message = if you want something custom to be shown to the user once it gets to the general error handler, put it here Custom Properties = a variant where custom things can be added as the variant's attributes (which are, conviently, variants themselves). Things like images (see Aristos' error module for an example) can be stuffed in here

For those looking for GOOP Developer, the site is here.

You needn't be intimated by lil' ol' me - I've only got a high post count because I generally ignore the SNR principle hey Hey HEY! I'm trying to keep a reputation goin' here Mike Seriously though, I'm really really looking forward to getting some good BBQ with all of you at NI-Week - it's the highlight of my week. Now there's somewhere I haven't been in a few years. Best damn beef brisket I've ever had. And I think I recall the beans being pretty special too. I also seem to remeber photos floating around of LAVA members dunking other LAVA members in big pails of ice water a few years ago at the LAVA/OpenG BBQ at the Salt Lick... I actually thought of three come backs to that, but none of them were appropriate for this forum

I thought about this a bit a few weeks ago, and the answer that I came out with was that everyone is going to have a different perception of what constitutes a good or a bad post. I thin you should just vote something up if it appeals to you - irrespective of whether it's LabVIEW related or otherwise. A high rating means that you're appreciated as a LAVA member, not necessarily as a LabVIEW guru. Yep - that's a flaw with just about every reputation system. I think that if people take it seriously then the good stuff will eventually separate from the noise. And no, we're not allowing anyone to apply negative ratings to anything (topics, posts, members) - as I said, something of little (or even anti-) value to you may be of high values to others - that's the power of community. Actually, this is the limitless power of community: PS: anyone else lovin' the new "Insert media" button as much as I am? No more pasting in embeded code - I just pasted in the url to the youTube page:

I'd love to see a photo of a 50 chassis system!

I knew someone was going to ask! I don't remember where I got it from, but I remember it took me days to find it Sorry I don't have any details - it was several years ago... As a side note, whenever I needed to put PCI cards into a PXI chassis, I've used 6U PXI carries inside of the NI 3U/6U PXI Combo chassis. I don't think a 3U PXI PCI carrier exists (I'm happy to be proven wrong).

! The goal should NOT be increasing your total post count, it should be increasing your reputation points !

I appreciate your promise to behave Unfortunately, there's no way to hide the warning indicator at this time.

That's a *great* idea! I would *soooooo* buy that! What do you think Stephen? Congrats mate - when's the CLA scheduled? You should be able to kick that one in the arse... I wonder if the person marking your exam freaked out, and thought "crap - I have no idea what these funny coloured wires are! This guy gets an A+!"

me too

Damn right!

That's a really great point - we generally used NI hardware because we know it works and it integrates well with our development environments and established architectures. If a particular need for a card outside of NI's range comes up, we're okay with using a 3rd party vendor's PXI cards, as long as integration is relatively straight forward (eg: Pickering have some great switch cards that are IVI compatible, so they work with NI-Switch). Another thing to remember is that CPCI (Compact PCI) cards will work in PXI chasses too (eg: the PXI-GPIB card from NI isn't actually PXI, it's cPCI), so as long as you have the drivers, you're golden.

Good stuff dannyt That's one of the reasons that we've brought the reputation system online - so the post count becomes less important, and I think your posts are pretty high SNR, so I expect your online reuptation to become even more important - well done!

Yes and no - it allows for synchronisation, but doesn't have things like the common-length trigger paths that PXI has. It's not a direct replacement for PXI sunchronization functionality, but it's pretty good at what it does.

That's a really good point. I'm not against PXI (I use it *a lot*), but I've often quizzed engineers on why they are using PXI over PCI, and the blank "because NI says it's better" stares I get back make me shake my head. It's a good form-factor (can get cards in and out more easily than a PC, depending on your access to the PC - think rack builds) and the synchronisation kicks arse - if you don't need either of those features, then you're probably wasting your money. Also, there are some cards that are only available in PXI or PCI format, so that's a factor to consider too... In that case, it might be wise to consider a PCI-based PC with an MXI link to an external PXI chassis (we do that a lot too). I already mentioned MXI, but there are carriers out there that allow you to put PCI cards in PXI chassis, and PXI cards in PCI PCs. I've done the former with great success before, but only ever tried the latter with an MXI link.

I like to call it the "naughty step". We're still working out the full details, but one of the new features is that admins and mods have the ability to warn a user for forum behaviour that violates our rules.

Yep - that's right. You can give a star rating to a whole thread (which includes your posts, as well as those of others) so you're marking the thread as valuable, not just your initial post. On the other hand, you can't vote up your own posts

Here's an example of exactly that - a subpanel controlled by a list of categories (subVIs that are loaded into the subpanel). It's a half-arsed job that I was mucking around with, so use at your own risk. There are three VIs: the preferences dialog itself, a template preferences page and an example preferences pages (there are some OpenG dependancies that you'll need too). One added bonus is that the preferences dialog saves an ini file of all the values on the FPs of the preference pages, and recalls them from that file each time you show the preferences dialog again. The implementation I had it in would look in a particular folder for any VIs with "prefpage_" at the start of it's name, and attempt to include it in the category list. The top bar updates to the title of the subVI too. PreferencesDialog.zip

Me too - I'm planning on making that one the front.