Rolf Kalbermatter

Yeah, I sometimes like to align functions inside multiframe structures too, so they are at the same place in all frames. But usually only if they do similar things and as form of meditation, while thinking about the rest of the algorithm.

It's not about wires going behind VIs without being connected; that is something I have done myself maybe 5 times in over 20 years of LabVIEWing. But seeing to which terminal a wire is really connected. Of course that may seem often unnecessary because of different and incompatible datatypes of the terminals, but can be a real gotcha when a VI has several datatype compatible terminals. And yes it is not as important in my own VIs since I know how I wired them, but inheriting VIs from someone else is always much easier if such rules have been followed.

I think that is triple-click. For some reasons I can't get myself to use that, but that could be also because I do not have a super-duper gaming mouse nor any experience in playing shooter games, or most any other computer games for that matter

Please upload your project! Without more details, nobody can help you here.

Are you a network engineer? This is quite specialized matter and I would not dare to start doing this without consulting a specialist in installing network infrastructure. The wrong protection circuit could rather slow down your network traffic and not really protect your network much from real surges. In general there is almost no technology that will not at least get fried itself by a direct lightning stroke to the installation or any attached appliance. But for less strong environmental impacts you still need to know quite a bit about both the network characteristics in question and the possible surges that you have. Is it static electricity or rather something else?

I can understand that sentiment But my rule comes from the fact that if I move a VI (by nudging it one pixel up and to the side with the cursor) to see if the wires are correctly attached to the right terminal, and yes that has been and is always one of my first methods when debugging code that appears to behave strangely, I want to see the wires move with it so I know approximately that they indeed are attached to the terminal they appear to. With hidden bends you don't have that at all and need to move the node sometimes many steps to see if they really attach correctly. And shift-cursor is not a good way to do it. And to Shaun and others, be happy I'm not in the LabVIEW development team. I would penalize any VI call that is not using the 4*x*x*2 connector pane by an extra 1 ms delay, and document it as a special optimization in the compiler of the 4*x*x*4 connector pane pattern.

Never hide bends!! That is über evil! But reduce them as much as possible by aligning the nodes on the error cluster.

Well Win8 RT is for several reasons not an option. Any win8 RT application has to be a full .Net application as it is based on the virtual machine execution of .Net to achieve hardware independence (so it works on Arm, Risc, and x86 CPUs alike). But the Pipes library uses Windows APIs that are prone to very slight platform differences in the kernel. While Windows tries to maintain backwards compatibility as much as possible, this API is exercised infrequently enough that they can let slip a few minor incompatibilities between Windows versions.

I wouldn't be surprised if the pipes offer higher throughput than network sockets. They are implemented in the Windows kernel most likely with some form of shared memory pool that is mapped into both processes. As such they do short circuit quite some overhead compared to going through the Winsock library. However I have no numbers available. As to the latest version of the available code, the earlier link to the CVS repository on sourceforge is indeed the most recent one that is available and more or less working. I did some more trials on this but didn't get any more reliable operation out of it, and also there is a good chance that it might have additional issues on Windows 8. This part of the Windows API is both rather complex and involved and can be influenced by many internal changes to the Windows kernel.

There is not an easy solution. The only proper way would be to implement some DLL wrapper that uses the Call Library Node callback methods to register any session that gets opened in some private global queue in the wrapper DLL. The close function then removes the session from the queue. The CLN callback function for abort will check the queue for the session parameter and close it also if found. That CLN callback mechanism is the only way to receive the LabVIEW Abort event properly in external code.

He just made a post replying to another post of one of his "buddies" asking if they have a trial version. Cute! Maybe Michael needs to add a specific check and reject any post with a link to yiiglo.com, rasteredge.com, and businessrefinery.com. Also interesting to know is that the "Company" link on the side arronlee likes to promote so much does not work at all. Always nice to do (online) business with a company that could literally sit in cloud 7 as soon as you are not happy about something.

Well, on that note I have all versions of LabVIEW installed on my system since about 5.0. A few months back LabVIEW 8.2.1 started to crash on startup but I didn't have any urgent need for that to work so left it at that. I did regularly check if it still crashed to because there was a potential project that might need a minor maintenance work in the near feature. Just before installing LabVIEW 2012 I tested again and it still crashed. After installing LabVIEW 2012 SP1 and the according device driver DVD I tried again and it now worked. And no, I prevented the DADmx driver from removing any support from the LabVIEW 8.2 directory by hiding it (and the other versions, the DAQmx intaller wants to rob of all DAQmx VIs) during the install! So while 2012 may be more stable, the underlaying device drivers can make a much bigger difference.

Those stubs could be the culprit. Your DLLs may in the initialization routine (the code that gets executed automatically when the DLL is loaded into memory) do call some of these stubs expecting certain values or behavior and getting stuck in an endless loop waiting for these to change. Without seeing the DLL source code this is almost impossible to debug though. During the initialization routine of the DLL, even on Windows the system is more or less monopolized for the current process which can result in a very sluggish or even completely locked up system. If you have a chance to look at the source code or talk to the developer of the DLL, make sure they are not doing anything complicated in the DLLMain() function. That is the function called on loading and unloading of the DLL. In fact there are a lot of things you are not allowed to do in there at all, according to MS, one of them is for instance trying to load other DLLs dynamically, as that will have a good chance to lockup your system in a nice deadlock.

No, definitely not! 4*2*2*4 should be the standard and strictly enforced for all LabVIEW programmers, if I had a say in this! And anyone using the 6*4*4*6 for a VI that is not private to the library should be banned from writing LabVIEW programs.

Or it might be that the cell boundary calculation was unnecessarily done in all updates for each cell. I doubt NI would not have some clipping optimization when updating for instance the cell background of many cells that they would even attempt to draw anything on the screen that will not be visible. They do have to go into the right cell and update its attributes accordingly of course so the cell can display correctly when scrolled into the visible viewport. So your optimizations in the past mainly may have reduced the number of times cell boundaries were recalculated . Now with them gotten out of the way your optimizations might not harm but likely won't improve the speed much anymore. And beware of changing the cell height accidentally for one row. That might disable the nice optimization from Christina altogether and get you back to the old situation.

Maybe I was a tadbit to modest here. Thinking about it you are of course right. FGVs are powerful and are easier to learn for someone not knowing much about OOP. The problem is that without some OOP knowledge such a person is likely to either get stuck at the "set/get FGV with a little extra functionality level", or starting to create FGV monsters at least in the beginning. So while the initial learning curve to start using FGVs is fairly easy, doing the real powerful designs is just as a steep learning curve than learning LVOOP, with the difference that LVOOP comes with some tools right in the LabVIEW IDE to ease the more automatic tasks and FGVs generally have to be created each time manually. Also the separation of methods and data is a definitive advantage and thanks to the project integration also easy to manage.

While I certainly also am among the people who should attend the aformentioned LAA group, I do not try to hide these bends. Alignment were it is possible yes, otherwise leave it. I prefer to see that the wire goes indeed to the terminal that it looks like and not some other one, even if that alignment may only be off one pixel. Nothing as frustrating for me but connector panes (pains) that are chaotic or wires going into an icon other than where they really connect.

You should mention that you have posted elsewhere too (NI forum) for this, as that can help people to see if they can add anything useful to the thread, instead of repeating what others already said. Also it is a good way of getting additional references for anyone coming across similar problems in the future and coming here instead of the NI forums.

That is a somewhat strong simplification! Technically you are right, conceptually AE it is a completely upside down way of doing OOP. OOP is about encapsulating the data which the methods can work with while AE is about encapsulating the data AND the methods in one place. The data is always together with the methods which makes things like instantiation a bit problematic. There is also the aforementioned problem of the conpane which is not infinitely expandable. While this is a limit, I haven't found it a limit in the sense that I could not do things I wanted to do. And the side effect is that it makes you think more about extending such an "object". And that is usually always a good thing (except sometimes for project deadlines). As to the code bloat, as soon as you start to do accessor wrappers for the individual AE methods, you go down the same road. AEs only work by discipline from the implementor and the user (unless you wrapped them at which point the AE implementation gets a fact that a user should not interest at all anymore). LVOOP works by certain contracts that the development environment and compiler impose on both the implementor and user of the class. You can make a similar point (albeit only in the aspect of implementing one with the other) between C and C++. You can write object oriented code in C just as well but you have no support by the compiler environment for that. Everything beyond the normal C rules has to be done by discipline of the programmer, rather than by the compiler checking that object classes are indeed compatible and can be casted from one to the other class, just to name an example. Also inheritance is a nice feature in OOP, as it allows to easily implement variations on a theme. At the same time, it is also one of the more abused features in many OOP designs. As soon as you find yourself trying to prop a potato class in a car interface, you should realize that you probably have just created a mutant monster that will eventually chase you in your worst nightmares. Inheritance in an AE context on the other side is simply not feasible. But I would certainly agree that anybody claiming AEs to be generally inferior to classes is simply ignorant. They can be created and used very successfully, if you have your mind properly wrapped around them. I would however hesitate to claim that they are worth to learn at this point instead of LVOOP. As an additional tool in a programmers toolkit they are however still a very valuable and powerful addition to any LabVIEW programmer expertise.

Basically this whole discussion of perceived differences between LV2Global, FGV, Action Engine, or IGV (Intelligent Global Variable) are a bit academic. Traditionally the LV2 style global were the first incarnation of this pattern and indeed in the beginning mostly just with get/set accessor methods. However smart minds soon found the possibiity to also encapsulate additional methods into the LV2 style global without even bothering to find a new name for this. In the over 25 years of LabVIEW use new terms have arisen, often more to just have a new term, rather than describe a fundamentally different design pattern. As such these names are in practice quite interchangeable as different people will tend to use different terms for exactly the same thing. Especially the distinction between FGV/IGV and AE feels a bit artificial to me. The claimed advantage of AE's to have no race conditions is simply by discipline of the programmer, both of the implementer as well as the user. There is nowhere an official document stating "AEs shall not have any possibility to create race conditions" and it would be impractical as that would for instance mean to completely disallow any set and get alike method altogether, as otherwise race conditions still can be produced by a lazy user who rather prefers to implement his algorithm to modify data around the AE, rather than move it into a new method inside. I would agree that LV2style globals are a bit of an old name and usually mean the set/get method, but they do not and have not excluded the possibility to add additional methods to it, to make it smarter. For the rest, FGV, IGV, AE and what else has come up, are often used interchangeably by different persons, and I do not see a good cause in trying to force an artificial difference between them. Daklu wrote: Well it is true there is a limit to the conpane, and one rule of thumb I use is that if the FGV/AE requires more than the 12 terminal conpane (that includes the obligatory error clusters and method selector), it has become to unwieldy and the design needs to be reviewed. I realize that many will say, ohh that additional work to refactor such an FGV/AE when this happens and yes it is work, sometimes quite a bit in fact, but it will also in-evidently result in refactoring parts of the project that have themselves become unwieldy. With OOP you can keep adding more and more methods and data to an object until even the creator can't really comprehend it anymore logically, and it still "works". The FGV has a natural limit which I don't tend to hit anymore nowadays and that while my overall applications haven't gotten simpler. Michael Avaliotis wrote: You bet I do! Haven't digged into LVOOP yet, despite knowing some C++ and quite a bit Java/C#. Daklu wrote: I think it has a lot to do with how your brain is wired. AEs and LVOOP are trying to do similar things in completely contrary ways. I would agree that AE's are not a good solution if you know LVOOP well, but I started with FGV/AEs loooooooong before LVOOP was even a topic that anyone would have thought about. And in that process I went down several times a path that I found to be a dead end, refining the process of creating AE's including to define self imposed rules to keep it all managable for my limited brain capacity. They work for me amazingly well and allowed me often to redefine functionality of existing applications by simply extending some AE's. This allowed to keep the modifications localized to a single component and its support functions rather than have to sprinkle around changes throughout the application. The relatively small adaptions in the interface were easily taken care off since the LabVIEW strict datatype paradigm normally pointed out the problematic spots right away. And yes I'm a proponent of making sure that the LabVIEW VIs who make use of a modified component will break in some ways, so one is forced to review those places at least once to see if there is a potential problem with the new addition. A proper OOP design would of course not need that since the object interface is well designed from the start and never will introduce incompatibilities with existing code when it gets extended . But while that is the theory I found that in OOP I tend to extend things sometimes, only to find out that certain code that makes use of the object will suddenly break in very subtle and sometimes hard to find ways, while if I had been forced to review all callers at the time I added the extension I would have been much more likely to identify the potential problem. Programming AEs is a fundamentally different (and I certainly won't claim it to be superior) paradigm to LVOOP. I'm aware that it is much less formalized, requires quite some self discipline to use properly, but many of my applications over the years would not have been possible to implement in a performant way without them. And as mentioned a lot of them date from before the time when LVOOP would even have been an option. Should I change to LVOOP? Maybe, but that would require quite a learning curve and maybe more importantly relearning quite a few things that work very well with AE but would be quite a problem with LVOOP. I tend to see it like this: Just like with graphical programming vs. textual programming, some brains have a tendency towards one or the other, partly because of previous experience, partly because of training. I trained my brain over about 20 years in programming AEs. Before I could program the same functionality in LVOOP as I do nowadays in an AE, would require me quite a bit more than weeks. And I still would have to do a lot of LVOOP before I would have found what to do and what to avoid. Maybe one of the problems is that the first time I looked at LVOOP turned out to be a very frustrating experience. For some reasons I can fairly easily accept that LabVIEW crashes on me because of errors I did in an external C component, but I get very upset if it crashes on me because I did some seemingly normal edit operation in the project window or such.

I compiled a version but that crashed, so left it at that for the time being. No use in releasing something that does not work. Should get some better test setups soon so that debugging will work more easily. And the Pipes library was never officially released, so we never ported it over from the CVS repository to the SVN one. It's still in the CVS only.

As with all OpenG sources, they are on the OpenG Toolkit project page on sourceforge. All of them!

"Never" would seem a very strong statement to me. See the OpenG LabPython, LVZIP and Pipe library just to name a few. It seems the person having done the vxcan API wrapper did indeed "forget" to add the C code to the download, especially since that wrapper doesn't really consist of any magic at all, but simply some C to LabVIEW parameter mapping. I fully understand that providing multiple platform wrappers can be a real pain in the ass, which would make it a good idea to add the C source of those wrappers, so others can recompile for new platforms, but doing everything on the LabVIEW level is not a maintainable solution in the long run at all. Usually APIs are anyhow different enough between platforms that a pure LabVIEW wrapper gets a real pain to do, such that it works on multiple platforms, unless the API developer kept in mind to keep the API binary consistent between platforms.

Unless you want to hack into the import library wizard VI code yourself (and create a maintenance nightmare since there is no publically documented VI API so far AFAIK) I don't believe there is currently an option. And the command line approach does not seem to me the ideal way of creating such an interface, since the import library wizard potentially requires an entire page of possible command line parameters if you consider things like header directories, defines, etc.

That is not cheating but the proper course of action unless you enjoy playing C compiler yourself and create a badly maintainable VI.