Leaderboard

13 rep points awarded in 18 posts? Not a sniff of LV in sight.

There is IQ and EQ difference. Maybe engineers and scientists have high IQ, but not necessary high on EQ. Part of IQ are born with, but EQ is trained in life. Enginners/Scientists don't have time to train their EQ which is necessary for politics and people skills, they are just happy to play around with their high IQ, maybe? :-)

The children of a LVClass library are Project Items. Sorry I don't have 8.6 available at the moment. Here's a screenshot (LV2009 snippet). I was being lousy... there's another computer right next to me with LV 8.6... AccessScope_LV86.vi

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.

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) The readablilty issue is clear (as it applies to stacked sequences). Here is a dataflow implementation: Same thing written as a state machine:

The container state has a refnum to the actual control from which you can get the owning VI: The exec State Change Event (which you are looking at) returns the VIRef in the Event data as well. Ton If you crosspost, please mention. Or preferably, start the discussion in one place, and if you don't get rewarding answers in a few days (>2) start at the other forum. This will keep the discussion clean. Ton

The dutch minister for 'Culture, Education and Science' Ronald Plasterk was a molecular genetecist. Ton

Chancellor Angela Merkel (Germany) was a quantum physicist before going into politics. Well, quantum politicians are not liars... they always say the truth, but only if the wavefunction is not collapsed. Who knows if it's not happening in the 5th or 6th dimension?

Look, a LabVIEW byte array (string) is like this: typedef struct { int32 len; uInt8 elm[]; } **LStrHandle; So you hav a number of problems to pass this as a C String pointer. 1) The actual character array starts with an offset into the real memory area. 2) The LabVIEW string is a handle (pointer to pointer) 3) Last but not least LabVIEW data can be "hyperdynamic". This last one is very important! LabVIEW reserves the right to manage its memory in anyway that makes sense to it. So if you create a string containing a set of characters, then run some magic like memcpy() (I prefer the LabVIEW manger call MoveBlock() for this) through a Call Library Node to get at the pointer that points to the actual string and try to pass that pointer to another Call Library Node to your API, LabVIEW might have reused, resized, or deallocated the original string already at the time your API is called. This in the best case could mean a simple Access Violation or crash or if you are unlucky a much less noticeable effect such as strange interactions with other parts of your code that operate with the reused memory, where your API now tries to write something into (or the other function reusing that memory writes something in and your API reads suddenly gibberish). There are tricks such as making sure the original string wire runs through the diagram without any branching to some place that due to dataflow dependency will execute after the call to your CLN API, to hopefully make LabVIEW retain that string memory until after your API executes. However while this did work in older versions, there is always the chance that by new and improved optimization strategies in newer LabVIEW versions, this suddenly might fail. The reason this works until now is that LabVIEW does not usually do diagram optimizations across structure boundaries, so if you run your string wire to a sequence structure border that depends on your CLN being called and finished too, you are nowadays safe. But if you just wire that string wire to the border without using it, there is a good chance that a newer LabVIEW version with an improved optimization algorithme might realize that this string is never used after your memcpy() hokuspokus call and suddenly the string is gone anyhow, at the time your API call tries to access the pointer that you retrieved with so much virtue from the LabVIEW string handle. Rolf Kalbermatter

You can not pass LabVIEW clusters containing variable sized elements such as strings or arrays to a C function. LabVIEW stores its arrays (and strings which are in fact just byte arrays too) very differently than what a C API function expects. So the best apparoach is usually to write a wrapper DLL with a function that takes the elements in the cluster as individual parameters and constructs the C structure to pass to the real API. There is in principle also a way to do it all in LabVIEW, but to be able to do that you need to know a lot more about C programming and its datatypes than you will need to write a wrapper DLL in C. Rolf Kalbermatter