Jump to content

SDietrich

Members
  • Content Count

    39
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by SDietrich

  1. 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 ab
  2. 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 s
  3. 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.
  4. 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 th
  5. 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.
  6. 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!
  7. 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 SuperSecret
  8. 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 elega
  9. 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?
  10. 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 pan
  11. 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
  12. 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.
  13. The other folder classes you mentioned sound more like special things dealing with objects, XNodes and such. Probably not what you want.
  14. 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.
  15. 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 event
  16. 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
  17. 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 b
  18. 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'
  19. libpq-LabVIEW now has its own SourceForge-project.
  20. 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
  21. 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
  22. 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
  23. 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.
  24. The current release includes the following DLLs: libpq.dll (the actual driver) libintl.dll libeay32.dll ssleay32.dll According to Dependency Walker these are the only external dependencies. Everything else is Windows stuff and the Visual C++ runtime, of course. But I think, this might even be bundled with Windows itself, so no problem here.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.