ShaunR

I'll take any opportunity to razz you up

Is that a euphemism?

You did what!?!

...Lol

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).

Cat has been MIA for a while.

Abort!!!!! Haha...

Unlikely to be Cat. Ballistic weapons don't work too well in submarines

Looks awful unstable in that first video, but I guess at 5600 MPH it's more about brute force.

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

This all sounds great. For some reason I thought this was done in some LabVIEW challenge a few years ago was it not? I can't seem to find it at the moment.

Yeah I totally agree that this should be a native LabVIEW function in the event structure.

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.

Ah, but 1 developer x many (small) projects that could use logging and it gets expensive.

Not if he gives them away free too

Sorry, I know little about the terminology of licensing. At a consulting firm I’m doing some work for, they would like a reusable error/debug logger for use in their many projects. I suggested your logger. But, if I read it right, the SQLite API has to be licensed for each project (each “product”), which isn’t going to fly. My other options are a non-database solution, using Saphir’s SmartSQLVIEW, or calling the SQLite all directly with SQL statements. I actually prefer the last option (even though it will be much more limited and less polished than your stuff) as I can then use it as a logger in my message/actor framework without inheriting any licensing issues. Need to polish up my SQL, anyway.

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 )

You've now heard the position of the "OO is bad" crowd.

Wow. I'm a crowd? I really can be in two places at once (multiple salaries )

So maybe I'll try a C++ .dll instead... sigh.

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.

but not fair use to use in commerical apps?

Examples of fair use include commentary, criticism, news reporting, research, teaching, library archiving and scholarship

Common misunderstandings

• Any use that seems fair is fair use. In the law, the term fair use has a specific meaning that only partly overlaps the plain-English meaning of the words. While judges have much leeway in deciding how to apply fair use guidelines, not every use that is commonly considered "fair" counts as fair use under the law.
  

Source.

Hi Shaun,

Can you clarify the “fair use” of your database logger (and SQLite API)? I’d like to use it (or a modified version) as an error logger in custom software projects for clients.

— James

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.

Depending on Irrespective of the size of your point data, does it make sense to use LVOOP? I have no benchmarks to point to, but I imagine for small data, the overhead of LVOOP will outweigh the performance of, say, a cluster of {prev, data, next} for loop that you don't get the nice OOP-ness with. There will probably be more less legwork with that route (and you may won't have to be more careful with memory allocations) but I think for the performance spec you're looking to hit, the simple route may be more effective.

....and get rid of the queues.

So. Where can I download the IDE? (I like it!)

The example of an electrical circuit was the original premis of labview. We have had this sort of functionality since day dot (custom probes with a waveform graph). I think custom probes are generally underused and i'd love to see a custom probe pack with waveforms, plots etc.

hmmmmmmmmm sounds like a non-announcement announcement of an as yet unknown capability.

Naaah. He just means they've added more wizards

So.

Anyone offering the car wash and traffic lights?

(BTW ShaunR, I see u no longer have your "lvoop bugs" jingle. R u now a convert?)

Nope. Apart from the odd list encapsulation. I steer well clear of it unless dragged kicking and screaming.

However. LVPOOP is now a part of LabVIEW and the CLD exams are specified tasks with example answers. So for people learning LabVIEW (and have been infected with the OOP virus), they are an ideal way to learn the pro's and cons of adopting the paradigm. More importantaly though, they can show that elusive aspect of how to go about solving a specific task using LVPOOP rather than trying to review more complicated private projects (that have no exampled equivalence to classical LabVIEW) and then trying to figure out how to apply it to thier situation.

The CR/LF constant in labview is platform dependent. It also depends on which browser you are viewing in (some are happy with only one EOL char, others require both). You should use a constant string with "\r\n" which will work on all platforms and browsers.

I was thinking we could just make a new category in the code repository? That's essentially what we're talking about, after all, it just happens to be a specific implementation instead of reuse code.

I guess the choice will depend on if you want to track the code and related posts (comments etc...) or just the code.

Hmm.

The CR seems a bit "formal" to me but has the "pro" that each submitter is responsible for their submission so no centralised maintenance.

Not keen on the document idea which would basically be just a list of links that someone has to maintain.

I was thinking of just an extra category in the forums (like the Object-Oriented Programming, User Interface, Remote Control, Monitoring and the Internet, etc) that would just pull together the current posts and people could add theirs as and when they were created. People could also use that area for requests for code reviews of examples they want people to comment on.

I posted the sprinkler controller here a while ago.

Sweet.

I wonder if we could get an "area" on Lava for these so they are all in one place and easy to find

Here you go:

http://lavag.org/top...abview-classes/

Great.

Traffic lights, car wash anyone?

It's still not clear to me what the overall goal is.

Well. I really can't think of any other ways to phrase it that I haven't already.....

then maybe some of the LVOOP gurus could post unofficial, demonstrative LVOOP implementations of the example exams (ATM, traffic lights etc).

To provide (unofficial, demonstration) LVOOP solutions of CLD example exams

for the benefit of potential CLDs

Think of it this way guys.

An architecture astronought has designed the system (no matter how crap it is) and supplied a spec for a contractor code-monkey to code against. It's not the code-monkeys remit to re-design the system and re-write the spec (that's what the astronought is paid for) - just code to spec. If you (not you specifically, but generally) cannot code to spec, then your not much use within a team of coders lead by an astronought (you could be considered argumentative). That's the first rung you have to master before you can climb to where the oxygen is thinner. That is where the CLD sits - can you follow instruction and documentation. It may not be glamorous, or exercise your artistic/thought provocative nature, but it can be hard and daunting for many-even in classical LabVIEW. When it comes to OOP, it's harder by 10-fold if you aren't of that mind-set and those that are, maybe unsure of how to achieve it in LabVIEW. Whether it is close to real or not is irrelevent. It's to help those at that level by giving examples (in LVOOP) that they can analyse and compare.

I'm just suggesting (with all the super-guru LVOOP talent in Lava) that perhaps if examples of the CLD practise exams where demonstrated with LVPOOP, then maybe a lot more people would grok and maybe ken the advantages/disadvantages and methods. Maybe on your efforts you might see all submissions in the future in LVOOP rather than classical. But if the thread goes in the direction of "it's too simple and uninteresting for LVOOP" or "it's not a real project therfore LVOOP isn't applicable" then those are just weasel words and LVOOP has already failed.

James.

The CLA exams don't target code (you can use the same UML for both right?) and I'm not sure what you could take away from it. But sure, if you have an example, post it.