Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


SDietrich last won the day on December 30 2014

SDietrich had the most liked content!

Community Reputation


About SDietrich

  • Rank
    More Active

Profile Information

  • Gender
  • Location

LabVIEW Information

  • Version
    LabVIEW 2014
  • Since

Recent Profile Visitors

1,026 profile views
  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"></Property> It was changed to: <Property Name="NI.Lib.Version" Type="Str"></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 and If I place an OpenG Index Array Element.xnode with version (or earlier) and then upgrade to version (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.
  • Create New...

Important Information

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