SDietrich

I found the reason for the error message and thanks to hoovahh a solution, too. When comparing the .xnode files from the two incompatible versions, the offending line is this one: <Property Name="NI.Lib.Version" Type="Str">0.0.0.0</Property> It was changed to: <Property Name="NI.Lib.Version" Type="Str">1.0.0.0</Property> This again makes LabVIEW look for an UpdateState ability-VI so it can migrate from the old version to the new one. Because there is no such VI, an error is displayed. The OpenG Filter Array XNode already has such an UpdateState ability VI (which basically only passes its input back as output) and it works as expected. No errors are shown, even if I mess around with the version number by hand. So I would ask to create such a VI in all the XNodes and no future update will break existing code. The interesting question remains, why the version number was increased in the first place...

We all focus on the horrible image we see when looking at this piece of code. But the actual horror lies underneath it. As Neil said in his original post: The indicator gets updated but according to LabView semantics it should not! How does this happen? I can only imagine the VIs outside the loop internally save a pointer to the array and the VI inside the loop writes the new data to this memory location and returns the number of bytes it has written. This is the actual horror, because this only works as long as the LabView-Memory-Manager keeps the array in its original spot. If for some reason it decides to move this memory, unexpected results will happen. If you're lucky the application crashes. If you are unlucky you read out wrong data and keep working with it. So it holds true again: If the code looks ugly, it probably is ugly. By the way, the solution would be so simple: Just pass the array to the VI inside the loop and have it write its new data to that memory location. The memory-manager does not shift memory around while in a call-library-node.

While replacing all the broken nodes in our code I found the OpenG Empty Array.xnode to also suffer from the mentioned incompatibility. It could be in a different version though, because I am now updating directly to the newest version of OpenG Array XNodes.

Hi folks, am I the only one hit by an incompatibility issue between versions 1.3.2.31 and 1.3.2.32? If I place an OpenG Index Array Element.xnode with version 1.3.2.31 (or earlier) and then upgrade to version 1.3.2.32 (or later), I get the following error message: Library version is incompatible with XNode version. I have to replace the Node with a fresh one from the palette, then everything works as expected. Note that this seems to be the only XNode suffering from this problem, all others I used upgrade just fine. As fixing this bug would probably mean breaking code that was created with version 1.3.2.32 or later I would suggest to investigate it only for the sake of avoiding it in the future? Thanks and keep up the good work, OpenG Array XNodes rock!

Thanks hooovahh, but I think have to elaborate a little more. At the moment, I don't care for source and sinks. The idea is more to go along a wire and sum up the lengths in pixels or the number of junctions, bends and so on. So I end up having an endpoint and I need to know, what terminal it is connected to so I can find the object and work on from there, e.g. highlighting it or getting the name of the object or so. So if the first endpoint always is the source (and a non-broken wire has only one source) that is a good start. But I also need to get the terminals for the sinks.

Hm, that finds all wires on the block diagram, not just the ones connected to a GObject the user selected. But maybe I can check each wire for whether it is connected to the object in question. Thanks!

Hi all, a quick drop plugin I am currently working on needs to traverse along wires. Using Wire.Joints[] one gets a good representation of where the wire runs. And of course at every Endpoint there is a terminal, one that is returned by Wire.Terms[]. But how can I say which terminal is at which endpoint? The order is different for the endpoints and for the terminals. I could use the position and bounds to find out which terminal overlaps which endpoint, but this feels like some voodoo that will go wrong sooner or later. Any ideas or suggestions? FYI: I already have SuperSecretPrivateSpecialStuff=True.

Hi all, I want to write a quick drop plugin and it will deal with selecting things on the block diagram. It needs to traverse along wires to find things that are connected to the object the user selected. So the first question is: How do I get all terminals (or wires) of a GObject? TopLvlDiag.SelList[] returns an array of GObjects and that does not have a property like Wires[] or Terms[]. At the moment I tend to use a big case structure and cast the GObject to whatever class the object is (Node, Constant, Tunnel, ...) and use the Terms[] property of that. Isn't there are more elegant, easier and less error prone method? FYI: I already have SuperSecretPrivateSpecialStuff=True. Thanks for any idea or advice.

It isn't much but the Style member of the cluster is the same type as the Style member of the Pen input to the Draw Line.vi. Maybe LabVIEW uses these routines internally to draw the block diagram?

And that is exactly what I wanted to find out: What does the stub loader do if it determines there is already a LV-runtime loaded, but with a different version? Does it crash or abort? The answer is as expected: It simply loads the correct runtime version and they coexist side by side. I attached a little program to show this. The EXE is compiled with LV2009 and it uses a DLL that is compiled with LV2013. When the program starts two front panels are shown, one from the startup VI in the executable and one from the called VI within the DLL. Use the "Help->About" in each of the front panels to verify. Of course if the runtime (or IDE) for 2009 and 2013 is not installed it won't work. Test2009with2013dll.zip

RolfK, that is an interesting point of view. I agree, the only advantage is to stay within LabVIEW the whole time and every developer may decide, how big of an advantage that is for him. For me it is a big one because otherwise I would have to document and maintain a complete second toolchain. However, I think the following is not true: "LoadLibrary() loads the DLL into the calling process", which is our process. That is also the process, into which the original third-party DLL is loaded, so there are no other processes involved. The whole concept of callbacks would not work if there were multiple processes, because one process can not call a subroutine within another process. Unfortunately I also doubt the statement about a separate "LabVIEW runtime process", because I never heard of such a thing and found no reference to it, neither on NI nor on the internet. As I understand it, a runtime-engine is a library that is used by a process (our LabVIEW executable) not a process itself (e.g. a server process). The interesting question remains: What happens, when a process uses two different LabVIEW-runtime-engines? This obviously would be the case, if I compile the EXE in LV2013 and the DLL in LV2012. But it would also be the case if a C program uses two LabVIEW-DLLs compile with different versions of LabVIEW. And because the latter surely must work, I expect the former also to. Nonetheless I will certainly test that in the next days and post my findings here. When moving platforms one has to recompile no matter what method is used. After all, a C wrapper is platform dependent and last but not least, the original third party DLL is, too. One interesting thought to close with: Why do we even have to create a wrapper-DLL? A nice feature would be to have LabVIEW "export" certain VIs in an EXE, too. This way one could just use the GetProcAddress() without loading a DLL at all. Maybe this way the callback VI could even be run within the same application instance?

I agree. If it compiles, don't break it. Like in C where your code compiles, even if you use uninitialized variables for example. A warning would be the right kind of thing to issue. And please allow the terminals of the event structure to be hidden to avoid false warnings.

The other folder classes you mentioned sound more like special things dealing with objects, XNodes and such. Probably not what you want.

I know it's an old thread, but I had one idea you might find interesting: Do a parallel wait and whichever receives data sends "dummy" data (e.g. NaN) to the other one. When inspecting the received data, ignore it if it is the dummy data. This way you can make sure both wait-nodes will abort when at least one receives data. But personally I would prefer using events. Of course this means you get all the data from your high frequency channel. If that is not a problem it could serve as a nice side effect.