bsvingen

This seems to be an ideal that has little significance for action engines. An action engine make use of shift registers to store data and/or states, and if you wire from the outside and on to the register, you accomplish nothing because you (re)initialize the shift register for each call. If you use the action engine to read and buffer data from some source, you will have to bypass the left shift register somehow during read, no matter what. I don't see how doing this inside the loop will be any worse than outside the loop. When there is no data to send to the AE, the worst thing that can happen is a copy of an empty array. When sending data from the AE, this can be done "on the other side" of the shift register. The rest of the input end of the action engine usually is some low byte count initializing stuff anyway (references etc). I mean, the data going into the AE may not even be of the same format or type as the data going out of the AE. If you have to pass huge amounts of other data through the AE, this is completely different, but why would you want to do that?

But then again, my understanding of buffers is fuzzy at best

QUOTE (jdunham @ Mar 18 2009, 07:14 AM)

Nope. A+B will only create a buffer if you need to keep A and B around in addition to the result. While I agree LV can get squirrely when you work with huge datasets (I realize that's exactly your concern), but not normally needing to worry about assignment or storage at all is a huge benefit.

If you do a lot of work with huge datasets, you might want to buy IMAQ Vision, and treat your data as images. There are all kinds of inplace math functions and I bet they will be tons faster than native LV for million-point datasets.

Well, I still find chasing for buffers is more of an black art. Maybe some day I get it

I think my example was a bit too simple (try the slightly more complex c=sqrt(a*a + b*b) and make that execute faster than a formula node version ) . But the point remains, this would be much easier with a three input "+", or a more generalized version of that principle where no buffers are created in the first place. Nevertheless, a = a +b (in contrast with c = a + b) will also create a buffer because LV has no assignment, there are only functions returning for instance a+b where the result pops out of nowhere.

But those in-place structures and things looks cool. I have to look more into them.

It occured to me that the primitives + - and so on always create a buffer. With large datasets this is not good, and it is especially evident when using LVOOP. Basically this means that the primitives are made as functions returning a (new) value. For instance, + is written as:

double plus(a,b)

{ return a+b }

More often this is actually what I want (I have omitted references for c, because this has nothing to do with it):

void plus(a,b,c)

{ c = a+b }

What I would like to have is a "+" primitive with 3 inputs and one output, where the result is set in the third input. This will create no buffers. LV can be tricked into doing this, but it is counterintuitive and not very elegant compared with using a primitive, still it executes faster. I have included a very simple example. On my whish list.

Download File:post-4885-1237247031.zip

QUOTE (zmarcoz @ Mar 16 2009, 04:42 AM)

After I fail in my LV job interview, I really want to know what knowledge should a LV programmer should know? I understand that the answer may depend on the company, but any general knowledge that I should know?

Maybe I should give an example, I would expect a webpage developer knows about Photoshop, Dreamwaver, php, frontpage, etc

This could include all and everything I think. Take signal processing. It is all mathematics and algorithms, so you need to know C/C++, FORTRAN, Matlab (in an "algorithmic" and "performance" kind of way) + being able to learn new mathematics quickly. In process control you would need basic knowledge of the process and knowledge of how to communicate with all kinds of hardware and software, new and old.

It is my impression that Consultants in LV tend to focus on UI and general software engineering, while "users of LV" focus more directly on applications and function (signal processing, process control, hardware control and of course DAQ and analysis in all shapes and forms).

I have a similar problem I think. On single core machines, no problem, but on dual core machines there seems to be some memory allocation bug kind of thing. For no apparent reason the whole UI becomes sluggish when showing graphs. It can happen when only 3-4 vis are loaded dynamically and with severe sluggishness that varies from pc to pc (slowdown of a factor of 10 or more and worse on laptops than desktops). I have added a "other 1" execution thread vi that runs in a main loop. That seems to make it somewhat better - sometimes. It seems to me it has something to do with display card RAM and buffering or something, but it is random, it can suddenly start, and once started the only remedy i to restart LV.

I think the backward compatibility ghost plays a major role here, and probably hardwiring to the front panel? along with hard resistance from the "Wire Nazis" and tons of patents, copyrights and other corporate stuff, plus no competition. The LV "editor" hasn't changed practically speaking since LV 1.0, that is over 20 years. When looking at how even the most basic modern software handles charts, flow diagrams etc (for instance the freely available yEd ), I think it is safe to say that the LV editor is stone aged in comparison. Still, there are addons and toolkits from NI that incorporate some modern things and more sensible layouts, but nothing of that makes its way down to the basic editor.

The "de-spaghettify" function in 8.6 certainly is a huge step in the right direction.

I'm not sure about the null-wire though, basically because I think adding yet another wire that doesn't really do anything, is IMO a step in the wrong direction. I would rather have a less intrusive sequence structure border.

FWIW, here is a 8.2.1 version that works. I modified Daklu's 8.6 version and saved it to 8.2. The object entering will allways be initiated with data, and the state machine is part of the data essentially, not the other way around (that was the logic error of mine, wanting to initialize with a child) . The modification on the data should be done before the test and also include the data class (with the initial data), so I changed that back again. On the real version the test will also include a stop signal, stopping the loop depending on the data, and there should be no more modification on the data after that. The test method could now very well be inside the process method, but it is more evident what the loop does if it is left outside, and easier to get access to. I also deleted several unesessary get/set function calls (like to keep things as clean as possible). Anyway, Thanks Daklu for your help

Download File:post-4885-1236235140.zip

There obviously must be a bug in 8.2.1. When I have the help window open, it start kind of "shimmering" when I try to wire the child class directly into the shift register, and the wire gets broken. Have to start using 8.6 I guess.

What I meant with those "pregnant" objects was simply that it would not accept the child class except when going through a parent output first (the bug). It made no sense what was going on.

QUOTE (Daklu @ Mar 4 2009, 06:39 AM)

It's a logic error in your program. All three child classes use 'Set and Test.vi' within their 'State.vi.' The parent class does not. Therefore, when you start the program with the parent class, SSSM:State is executed, bypassing 'Set and Test.' Neither the data nor the object on the wire ever change.

You can't simply add 'Set and Test' to SSSM:State since your child classes make calls to that vi. You need to refactor your VIs so all instances of 'State.vi' do essentially the same thing--return the current data. There are lots of way you could refactor this... I've include one way in the attached file.

I had no problem hooking up any of the child classes.

So you are saying that there is fishiness in my programming? I have to look at this later today, but thanks. Did you try the child classes on the original? I used LV8.21 and there was no way. LV even reported an internal error when closing down and starting up again.

I am trying to use the LVOO2 mechanism of AQ (see this board some place) in state machines. I got it working, but there are one thing I just don't understand. When initiating the state machine, it needs to be initiated with some of the child classes, or the state machine won't do anything because it will never "get out" of the parent class. The strange thing is that I cannot simply use a child class, the wire will be broken. I have to make a vi with a parent output that is wired to a child class inside. When looking at the probes it is evident that there are actually three kind of classes.

1 parent class

2 child class

3 some sort of hybrid parent class with a child inside (pragnent??)

Also, the input must be a dynamic dispatch, but the output cannot be dynamic, since this creates output of the same child class as the input. The output has to be a parent class (again creating this hybrid). Only these hybrids will make the state machine run.

The odd thing is that the "pragnent" class that is supposed to be a child, is not wire compatible with a child. I have included a super simple state machine that shows what is going on. It has three states inc, dec and a random jump.

Download File:post-4885-1236126673.zip

QUOTE (crelf @ Feb 26 2009, 02:17 PM)

It'd need to have a parsing routing that was modular and easy to change, since a lot of us use different state machine transports (string, enum, queue, custom ecapsulated...)

That would be a major problem. Didn't AQ make a LVOOP version of a state diagram some years back? or was it action object? I was thinking more in those terms. It is certainly doable. In HyVisual (Ptolemy II), state diagrams (including every little piece of parameter) are saved directly as XML and of course read again from XML. We don't have to do all that, just the main logic structure.

QUOTE

special baby-poo-brown colour

:laugh: But what do you mean by tuning them out?

When thinking about how layers are used in CAD, it is very similar to OO. Typically you have a layer consisting of the main structure, then add different kinds of detail and functionality. There is a lot of things that can be done I guess, and highlighting when mose over certainly would in an instance make things much clearer in a crowded diagram.

QUOTE

I think hiding elements in a block diagram does not make it clearer to understand. Does it not encourage making a mess because you can use the hiding tools anyway ?

Maybe you are right, in LV the wires simply represent the data (or dataflow depending on your point of view) and their actual position is irrelevant for the functionality. In a CAD drawing the "wires" are the data and their positions and dimensions are the whole point. Anyway, the only information we need is knowledge of where the data comes from and where it goes to, everything in between is irrelevant, so it is a bit absurd that something completely irrelevant for the functionality is the one single thing that messes up everything. Obviosly there are lots of improvements that can be done with the basic wire concept, but it has not changed since LV 1.0

Something that could be usefull is reverse engineering of state machines. The coding challenge would be to design a state machine framework that also displays the state diagram (in normal state diagram form). This is maybe a bit backward, I guess the other way around would be more intuitive, but the end result would be a nice diagram that also would be useful in debugging as well as documentation. There are probably many different ways of doing this.

QUOTE (Justin Goeres @ Feb 26 2009, 04:48 AM)

Dataflow code (i.e. what you write in LabVIEW) is fundamentally the expression of relationships between pieces of data. That's one of the key differences between dataflow and imperative programming. And those relationships (in this case, the wires) determine the execution order of elements of your block diagram. If the error wires, or any other wires for that matter, were hidden, you would be hiding key information about your program's execution from yourself (not to mention anyone else unfortunate enough to see it!). Just for starters, you'd be unable to tell if a particular new wire you create would form a cycle (circular data dependency). And if it did, you'd be equally unable to tell why your diagram was suddenly broken.

At runtime, the error wire also contains critical information about the outcome of whatever operations preceded it. That information is used to make all kinds of decisions, as other people pointed out. In the process of making these decisions, the error wire can branch and merge in complicated ways that affect the execution flow of the program. Masking out that kind of information would break the entire relationship between looking at your block diagram and understanding how its code executes.

Hiding the error wires would break the whole dataflow paradigm. It would be like hiding all the individual "if" statements in C code, but not the code inside the { } blocks that follow them, or something.

I would suggest that if you really are having trouble with error wires polluting your block diagrams, you've got too much going on in your diagrams and should use more subVIs.

I think we are sliding off topic here, but I just want to say a few things. To "shrink" diagrams into smaller sub vis purely for the sake of making things modular ,is the same as hiding key information. This is modularization without abstraction, and is IMHO often worse than no modularization at all. The main problem with large diagrams are the shear number of wires. This is exactly the same problem we have with large CAD drawings (a huge amount of information). I am simply saying that if we had a mechanism like layers, so that information would be shown on a "need to know basis", large diagrams would be a breeze to read and understand and change. Layering IS an abstract modularization process, and it is abselutely vital for all serious CAD/graphics applications. The error concept is not a fundamental entity for dataflow, it is more like a "wrapping" to put around sub vis. If we could at least have an error layer that can be turned off, it would unclutter a lot and emphasize the real dataflow. But then again, it could be a completely undoable concept all together for all I know.

These are all very difficult questions. But the basics like FFT, filters and so on should be as fast in LV as it is with any other method. There should be no room for improvements in those things since optimized algorithms have existed for ages, and there is no good reason why LV should not use the best algirithms.

I think improvements can be better measured in LV specific things. Efficiency of queues, sub vi calls, compiler optimization of large diagrams vs using sub vis, efficiency of LVOOP operations, graphs and charts and so on.

QUOTE (crelf @ Feb 25 2009, 09:25 PM)

I don't agree - I make a lot of decisions in my code based on what's in the error cluster, even before it gets to an error handler.

Yes, but I don't see how the ability to make the wires invisible (transparent) will prevent you from doing that. I mean, this would basically be an implementation of layers, that have existed in CAD/graphical programs for decades.

QUOTE (crelf @ Feb 25 2009, 09:25 PM)

I don't agree - I make a lot of decisions in my code based on what's in the error cluster, even before it gets to an error handler.

Yes, but I don't see how the ability to make the wires invisible (transparent) will prevent you from doing that. I mean, this would basically be an implementation of layers, that have existed in CAD/graphical programs for decades.

QUOTE (crelf @ Feb 25 2009, 08:20 PM)

Errors are data too.

He he, funny Yes, but everyone knows what that data is... It is only when debugging that the data in those wires are of any interest, if at all. The main purpose of those wires are to transport errors away to an error handler of some kind.

QUOTE (crelf @ Feb 25 2009, 08:20 PM)

Errors are data too.

He he, funny Yes, but everyone knows what that data is... It is only when debugging that the data in those wires are of any interest, if at all. The main purpose of those wires are to transport errors away to an error handler of some kind.

There is a PlxApi.dll missing (on my computer at last) so I cannot test it. But you are using WINAPI calling convention, is this correct? The alternative is C calling convention.

Or better, make the error wires invisible. Seriously, they mess up the diagram wile serving only an implicit function that distracts away from the flow of data. I mean, LV is dataflow - not errorflow. There could be a switch that makes them visible/invisible, and the connectors could be "filled" when a wire is connected and unfilled when not.

Or better, make the error wires invisible. Seriously, they mess up the diagram wile serving only an implicit function that distracts away from the flow of data. I mean, LV is dataflow - not errorflow. There could be a switch that makes them visible/invisible, and the connectors could be "filled" when a wire is connected and unfilled when not.

I think the best source is the Ptolemy web site, with tons of info. Here is a ppt file with some basic info. Ptolemy is open source, and the best way to study actor oriented design is to download and use Ptolemy, or at least look at some examples. Ptolemy is really super high quality stuff.

An actor is very simple. A LabVIEW vi is an actor by the definition of an actor. Data flows through it, and it has input and output ports as well as parameters and/or states (state machine). In contrast, no data flows through a GOOP/C++ object, a GOOP object has data that has to be initialized and methods that has to be invoked.

An LVOOP vi is like a super star (Marlon Brando ). It can take different kinds of data and do different things according to what data actually enters + lots of other usefull stuff (encapsulation, better modularity, less coding and so on).

An actor IS the machine firing up automatically when data enters, while a GOOP is a vague representation of what the machine can do with no concept of time, it has to be told to act.