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.

I tried your VI and it doesn't work for me, either (LV2013). You could try to use Win32-API SetFileTime(), it looks pretty straight forward.

I agree, a wrapper is necessary. But you can write that wrapper with LabVIEW! Here is how it works in general: Write a VI to be called back. Create a build specification as a DLL, containing that VI, and build it. Load the DLL from your application via kernel32.dll/LoadLibraryA(). Get the address of your callback VI within the DLL via kernel32.dll/GetProcAddress(). Pass that address to the function wanting a callback. when finished, unload the DLL via kernel32.dll/FreeLibrary(). Please note, the loaded DLL runs in a separate application instance. So you can not communicate via queues or events. You can use IPC mechanisms like UDP, but actually the DLL is loaded in the same process, so other methods may be available, too.

I agree, there is no guarantee. It says so in the manual for the Save for previous version and every developer knows how hard it can be to develop new features while keeping full backwards compatibility. But the aforementioned manual clearly states: And such a report is not shown, which definitely is a bug. A fix could be to show a report or - better - to make the saved VI run in the previous version. I therefore contacted the NI-support. The answer I received from there is a case for the cabinet of curiosities (I asked twice and got the same nonsens) but the good news is, they already have a CAR for the issue: 487412.

Thanks for the upload! When I tried to use it with my LV2013 it was broken. The reason was the ability AdaptToInputs.vi which was broken because of the Clear Errors.vi. Apparently LV2014 does nothing to it when saving for a previous version while the functionality in LV2014 actually was extended. This appears to me to be a bug in LV2014 that should be reported to NI. I'll do so in the next couple of days. When viewing the help pages for the LV2013 version and the LV2014 version of the Clear Errors.vi you see that it is not backwards compatible while LV2014 acts as if it was. But back to the topic: I like your XNode and will definitly put it into my archive of LV-gems This is what LV2014 saves for 2009: This is what it should have saved:

Yeah, LabVIEW is, VIs are not. LabVIEW is because it has to, otherwise you would need a "Save for future version" in your old LabVIEW. And VIs are not because every save VI would have to contain a specific block diagram (or parts thereof) for every previous version. Long story short: Would you mind hitting the Save for previous version button on the XNode and exchange the original attachment? Probably save for 2009 or so? That way you would not only do me a favor but you could also reach more users in general. Thanks, S. PS: I do the same in my XNodes. Real hackers don't read the generated code anyways, they read the generator Although I find the concept of optionally cleaning up the code via a constant or using templates worth investigating.

libpq-LabVIEW now has its own SourceForge-project.

I really like the power of XNodes, this is what they are meant for Also, you could have used OpenG like this: This way you can select ascending or descending sort order. I think the real difference between the three methods (XNode, OpenG, plain LabVIEW) is the performance for large arrays with memory intensive elements. Unfortunately your code is LV2014 which I do not use (yet), so I can't test your XNode nor investigate the generated code

Oh, you mean like XNodes? I think NI's options are quite limited given the fact that they certainly do not want to break existing plug-ins. The whole thing seems to be a forced QA to control how LabVIEW is modified. After all, people pay money for LabVIEW and expect it to behave well, while the PPF gives developers many ways to screw things up, resulting in support calls on the NI hotline. One alternative for NI could be to establish something like a "approved by NI" logo. Everybody can create a working PPF plugin but to have it "approved by NI" it must be signed (as in signature, not in checksum).

Hi flarn2006, nice work, I take my hat off to you . I don't know how you did it, but it clearly shows us two things: Kerckhoffs's principle proves true again the INI-file key should have read Checksum instead of Signature I personally never heared of the PPF before and certainly will investigate what its opportunities are. Regards, Sebastian PS: Maybe you want to share how you found the algorithm? I would think if it was by some reverse-engineering neither our friends at NI nor the guys here at LAVA would appreciate it. I have a hard-copy anyways

Sorry for the repeated upload/release, but VIPM really got me with those source file prefixes Version 1.0.0.12 now is as intended. However there is some good news, yet completely unrelated: I found the 64bit-Edition of PostgreSQL and it includes the libpq.dll in 64bit and all the dependencies. So all you LabVIEW-64 users out there look forward to the 64bit edition of this package.