jzoller

Yeah I didn't get offended but I know some people do. Even so it was a bad example, because you should have googled "what does kamahamaha mean" or "translate kamahamaha". And I did google it before posting, just out of curiosity and there wasn't an obvious answer.

Wiki:

Paiʻea is said to have had a dour disposition, and acquired the name he is best known for today: Kamehameha, from the Hawaiian language term for "the lonely one".

I am a scjp. I can do Java2D & 3D but do not have any C++ experience. I need to create real time graphic indicators to communicate with existing data acquisition software. I talked to the application engineer from the corresponding company. They said "using C++ to create a dll for the graphic indicators".

I'm still not sure of your motives, or what you mean by "real time" but...

If you're looking to learn something, C++ graphics (like OpenGL) has a fairly steep learning curve, especially if you are new to C++ as well. If you like a challenge, you'll learn a lot.

If you're looking to create something, have you considered LV's 2D and 3D picture controls?

Joe Z.

Edit: Another possibility: could you use Java/JNI to draw onto an AWT canvas? (http://en.wikipedia....ative_Interface)

Ask http://stackoverflow.com/. Much bigger crowd.

Joe Z.

Kamehame....wonder if that translates to any thing.

http://lmgtfy.com/?q=kamehameha

(Just a joke. Sorry, I love that site)

That is so true - I was hiking in the Rocky Mountains National Park a few months ago: it was a beautiful clear day, left at 6am, got back at 2pm, the clouds came out of nowhere at about 2:30pm

Yep, 2pm is the witching hour in the summer.

Joe Z.

Oh good we've got at least 1 person.

I'll be sure to post the info for the connection ASAP

I'll try to be there... can't guarantee, work's been, well, a lot of work lately.

Joe Z.

I'm curious how this came to be. Is it licensing issues?

Hrm. How to put this diplomatically.

I'll just settle for calling my IT management "extremely conservative".

Sorry for the delay, my RSS feed didn't pick up the replies.

Unfortunately, I work directly for the (40k+ person) company, and don't have the ability to keep virtual machines or separate partitions... or a modern browser, or a number of other things developed this millenium.

I guess I'm stuck with the manual version for now.

Thanks all,

Joe Z.

I don't think that's fair. Changing a background *is* close to skinning - it's a common component of skinning. Sure, it's not changing a whole theme, but it's definately better than nothing. Besides, in the industries that LabVIEW is used, I think that the ability to skin is pretty limited. A nice to have maybe, but I wouldn't suggest that the LabVIEW R&D spend too much time on it.

Skinning at least implies an intermediate layer of architecture that abstracts the UI (as in Model-View-Control). Changing a background is just an environment change.

I think skinning capability is a user-land responsibility, but, as the original topic shows, LV makes it painful.

Joe Z.

Edit: oh, one more solution. Use a picture control to imitate the appearance of buttons, and swap images on it.

Changing a background isn't even close to skinning.

There are a couple of social solutions as well.

Saying no to multiple interfaces is sometimes valid. Or, deliver an "initial version" with only a single interface, and see if they really want multiple interfaces.

Of course, if they're paying hourly, then you may not want to argue...

Joe Z.

For simple types, you can use <LV>\vi.lib\Utility\VariantDataType\GetTypeInfo.vi. There are other useful bits in that folder, too.

I wish they'd put some of these on the default palette... it always takes me a few minutes to remember where they are!

Joe Z.

Edit: "On closer inspection...". Of course, ShaunR's answer is more correct for your question.

Sorry, I'm not used to this side of the AM/PM

I usually go the other side around, doing the work in the older version and test afterwards that it still works in the newer one. Of course if you have to support runtime rather than the development system, you won't be able to avoid building a runtime distribution for each of these versions.

But then it is the question why won't they be able to install a newer runtime version? After all you can install several runtime versions alongside each other with no problem. In fact if you install driver software from NI, such as NI-VISA, DAQmx etc. you already have at least two to three different runtime versions installed since varous tools and utilities in there were developed in various LabVIEW versions.

My users are in a medical development environment. Sometimes, they're a little paranoid about updating.

Joe Z.

A state machine "should" (with a captial SH) be used to allow branching and "break" dataflow, not enforce it (dataflow does that implicitly). And you "SHould" only break dataflowas a last resort (it is after all LV biggest asset). A sequential statemachine is no different from a stacked sequence (in fact it is worse since it is more complicated). A procedural state machine not only flattens the hierarchy reducing abstraction and code re-use. It also hides functionality (making reading more difficult), is more difficult to debug and prone to transitional errors. Used sparingly, it is a powerful tool. Used excessively, well, you might as well write C.

With the exception of message handlers, I've yet to come accross a state machine that requires more than 10 states. I have however seen many with 30+. (In fact, the last time I saw that many I made him re-write it in 5....lol)

...

I agree with the comments on the sequential state machine: its use is primarily as a teaching tool.

The rest: nonsense.

A procedural state machine (PSM) doesn't break dataflow (certainly not the way locals, globals, refs and property nodes do). A PSM does allow much more flexibility over how the dataflow occurs, and that admittedly does increase complexity.

However, saying there are too many states is like saying something is "too pink": purely stylistic. After all, changing the structure of well written code doesn't result in any less code, or necessarily any more readability. Particularly where decision making is involved.

Better criteria for state machines: Are the states well factored? Single responsibility? Grouped by purpose? Well named and well commented? Is the code properly contained in sub-vi's for re-use? Are the states given some forethought, or just thrown out as they occurred to the developer? Can you shoot yourself in the foot by calling them in the wrong order?

The only time I've had difficulty with errors in PSM's is when they're interacting asynchronously with each other.

I'm still not particularly convinced that deep hierarchies have anything to offer besides complexity and brittleness. Do you happen to know any good references on the subject (seriously )?

Coding in C... nah, too harsh. Coding in Python is closer.

Joe Z.

I've got a utility that's written in LV2009. Some of my users only have the 8.6 (or 8.6.1, or 8.5, or 8.2...) runtime engine. They aren't likely to upgrade anytime soon.

Every time I release a new version, I need to back-port the code to prior LV versions and rebuild by hand, retargetting for different build locations each time: Error prone and time consuming.

Has anyone ever seen a solution that might automate this mess? Or at least help?

Thanks,

Joe Z.

Does anyone else feel bad for the the sheep? Constantly running around being chased by dogs and people.

No.

It obviously refers to vi.

I once worked at a place where IT insisted that the testers couldn't be on a separate sub-network: they had to be on the main network.

This worked ok until they found a set of computers on the network that didn't have antivirus, and didn't have the latest updates. Of course, they immediately pushed it out to all of them, and went home happy in the knowledge that their network was secure.

It took a couple hours to figure out why the Windows-based, $80k+ scopes all stopped working on the same day...

Joe Z.

This is a horrible abuse of SQL datatypes.

Agreed. Because of how databases work, it destroys your query efficiency.

---

I got a bit rushed on my earlier answer, so... here's my personal database rules of thumb. Maybe they'll be helpful:

Write data twice. Once as simple raw text to the local hard drive, and once to the database. Each test has a timestamp or ID that uniquely identifies it. Split text files by day or week so they don't get too large.

Every so often, the database compares its records to those on my tester(s), and match up any that were missing.

The database schema should not exceed two tables on the first pass design. Make it complicated sometime later.

For specific tools, I would probably use MySQL (with plans for an Apache web server) for a low cost version, and SQLServer (with plans for an IIS web server) if I could afford it.

Joe Z.

Problems to solve in advance:

What are you going to do when the database is down?

What are you going to do if the test station doesn't have a network connection?

How are you going to back up (and restore, if necessary) the database?

Don't get too caught up in the SQL side before you work these out. I know from personal experience that it's painful.

Joe Z.

Sure, that is what Microsoft has been thinking and doing all along. The world is their beta (and often alpha) tester! Who cares if it is good, as long as it ships.

Not sure how Microsoft got into this... they probably employ more testers than any other company on earth. For a high level description of their process, check out this pdf from MS research. It has some nice numbers on the impact of TDD, as well.

Joe Z.

I think his point is that too many developers try to make things complicated (for job security? bragging rights?) that you eventually have something so complicated that unforeseen bugs creep into the code weeks or months down the road.

It's worse than that: they do it to "make it better", or "more generic", or "more elegant". The best of reasons, but soon you end up with an overdue Observer-Decorator-Factory-Factory architecture and 6 levels of abstraction, when a polling loop would have worked just fine.

LV developers tend to be somewhat more prone to duct tape than, say, Java developers. I suspect it's because so many LV users are engineers and scientists of other disciplines, where code is not the goal.

Joe Z.

(I did find it rather funny that he held up a Netscape programmer as an example of programming excellence. Maybe Netscape failed because it was over-engineered. On the other hand, maybe it failed because there were too many duct tape programmers flying by the seat of their pants.)

Netscape's failure is fascinating, and pretty well documented.

Among other things, they decided to re-write their browser from scratch, "the right way". It ended up more than a year late, during which time Microsoft took the entire market.

Maybe they needed more duct tape

Joe Z.

I admit it: I like Joel On Software.

Besides, this article describes a goodly number of the best programmers I've met.

Joe Z.

http://forums.ni.com...hread.id=443021

Normally, I try not to cross post, but I think this requires a more official NI response that is usually seen here.

Any contributions would be most appreciated, though!

Joe Z.