bsvingen

Another thing is that all dependencies is listed up automatically. This can be extremely usefull sometimes.

QUOTE (Cat @ Mar 18 2009, 06:59 PM) I have no idea who you are working for, or what tests are being done. But since this has not popped up before the application was finished, you should be 100% certain of what they actually mean. To "stop" the tests is usually not the same as "aborting" the tests. If it involves powerful/dangerous/(costly and easely breakable) equipment there could be a world of difference between those two concepts.

QUOTE (BrokenArrow @ Mar 18 2009, 11:30 PM) Exactly, so the reasons for placing controls outside of the while loop is simply not there for AE, unless you also pass through some additional large datasets.

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