ShaunR

Well .this isn't a new phenomena. And the accepted way is to create a LV2 style global to get the reference. In fact. I supplied exactly that solution for this thread (although it was for events). I've also noted that JGCode uses this method in his classes. KISS.

Sweet. The padding length (in most cases) is dependant on the size of the block (16=128 bit block) so it really needs to be configurable. I've modified your padding VI (to account for the block length) and added the ANSI, ISO and PKCS5 (Ver 2.0) methods.

Rather than register et al. Wouldn't be more appropriate to use "add mapping" and "delete mapping"? (in a similar vein to add to list, delete from list). That semantic is fairly universal and you yourself used "add" to describe the register.

Give this a try

This Shawn bloke obviously knows what he's talking about

Hmm. So are you saying it is data tracking rather than interfacing (like different comms interfaces, different functions etc)? Maybe a DB would be a better way forward and could simplify your heirarchy to series 1,2,3 etc.

There are a few of the NI example exams coded in LVPOOP here. That'd be a good place to start since NI have equivelent examples in "proper" labview .

Operator Error

Like Tim_S. I assume this is an NSV issue since I've never seen 8 second delays with TCPIP. I havn't timed it, but it usually breaks the connection as soon as the LED goes off on the port although WiFI can be problematic for this sort of thing. You could open another connection with straight TCPIP just to monitor to see if it disapears since a lost wire will affect all connections on that wire/card. If you go that route, then it's sometimes a good idea to have it in a separate exe running in the background so that it also crowbars your main application (taskkill /f kinda thing).

No. You cannot cast clusters containing variable length items (like strings and arrays) but the clusters can be contained within an array and can be compund types. If you could set the length of the arrays to be a specific value, then you would be able to use arrays etc within the cluster (as you can with FPGA), but this feature isn't available in normal LabVIEW. The cluster is synonymous with the C "structure" (struct) which also cannot define variable length arrays within its definition.

Is that a euphemism?

Not quite what you are probably thinking. I added serial to the transport.lvlib. So I didn't exactly produce a polymorphic VI directly from the serial frames of the AE, but to all intents and purposes it is the same.

Well. My "negative" comments are'nt so much about your code. More about the serial implementation of VISA. The fact that once you are in a "read" you are stuck until it times out (not even the vi stop button will have an effect) means that you are forced into checking bytes at port and re-implementing the timeout. This makes any serial vis far more complicated than they need to be (and incongruous with all other VISA interfaces). My "positive" comment would be "if it's not broke, don't fix it" and you have proven it works since you state that you have "used for some time". Therefore it's only a style thing if anyone is going to comment. Anyhoo. Up until recently (well a year or two ago). I too used the action engine approach also. I eventually split out the sub-frames into separate VIs and pulled them together in a plymorphic VI. This has a couple of minor advantages over the AE in that you can have different terminals for each action, different icons (if you so desire) and a nice little drop-down under the VI instead of a typdef (slight readability improvement IMHO). You could just wrap the current vi in some more VIs to achieve this rather than pulling out the frames as I did, but it was just a personal preference and brought the serial in-line with tcpip and others that I chose to go that route with. Wrapping in a polymorphic VI at this level does have one disadvantage though. Since you cannot nest polymorphs, it means you cant wrap higher level protocol vis that use these into a polymorphic VI. It forces you to make protocol dependant serial transactions (e.g reads based on a byte length) an item in the drop-down at the same level (flattens the hierarchy and couples dependancy).

2011 SP1 Bug Fixes

Unlikely to be Cat. Ballistic weapons don't work too well in submarines Must be using LabVIEW 2010

OK. Which one of you has a brown sweater? : http://www.dailymail.co.uk/sciencetech/article-2108129/Railgun-Video-shows-hit-targets-100-miles-away-7-times-speed-sound.html

Event structures have been screaming to be re-vamped for years. Shame the focus so far (and for the foreseable future) is on less useful wizards and eye candy.

Zener diodes.(clipping)

Not if he gives them away free too

Indeed. Your mileage will depend on what you want. The advantage of the license/waiver is that it's not a per-seat license (effectively a site-wide license) so you can have lots of developers and install it on as many machines as you like (for developing that product) as well as no new fees for updates (of the toolkit) or periodic payments. 100 developersx1 product = about $1200 for the lifetime of the SQLite API (free upgrades). And lets not forget that if you are using it internally (e.g for your production line) it's completely free. I prefer to think of it that businesses that are interested in using it for monetising are supporting the development so that everone can benefit (after all, if you are selling product, the commercial cost is passed on, is it not?). The other way you have to pay per developer and everytime a new release (of the toolkit) comes out. 100 developersx1 product= about $69,900 every time you want to upgrade. It always strikes me as funny (as in ha, ha) that Labview people are prepared to pay tens of thousands of dollars every year to NI (basically just to get bug fixes) but balk at trivial costs for anything non-NI. I'm not making huge amounts off of it. But if others are, shouldn't a little bit of that come my way? At the end of the day, though. It depends on how much you value your time. For the amount of time I have spent on the API, I would have quoted considerably more if a customer wanted it. (the gochtya are the dlls )

Wow. I'm a crowd? I really can be in two places at once (multiple salaries ) For raw speed. It's the only way. Labview is fast (in comparison to, say Java), but not the fastest. A dll call will probably only add about 1-3 usecs of overhead.

Source.

Well. The database logger is shipped, as an example, with the SQLite API now (so it is covered by the sqlite api license). But it's not a lot of good without the API. I suppose you could hack the api stuff out and use something else, but I think it would be a lot more complicated. "Fair Use" is a bit moot since the SQLite API is distributed under a non-commercial share-alike license, so for evaluations, articles etc (where fair use is targeted) it is perfectly acceptable to use it under the current license.

....and get rid of the queues.