hooovahh

No blind trust. I trust it until I find an issue which to be honest isn't all that often.

Another option, but a more ugly one, is to just copy the VI files from your Windows machine to the Linux machine. Going around VIPM is not recommended because you loose your configuration management, and the inter dependencies between installed packages. But if this is a one time thing and you just want it to work with the least amount of effort, then you can go to your <Program Files>National InstrumentsLabVIEW 2010User.lib then copy all the folders to your Linux machine. There are of course other files that VIPM can install, things like tools menu items, help, quick drop functions. VIPM can basically be used to install any file anywhere in your system so grabbing just the user.lib might not be enough but for many that is all that is needed.

Google Translate. As logman said, contact Keyence for documentation. In the future please respond in English. This forum does not support the German language. Wie logman sagte, wenden Keyence für die Dokumentation. In Zukunft bitte in Englisch antworten. Dieses Forum unterstützt nicht die deutsche Sprache.

I don't want to insult you, but you are generally a text based programmer aren't you? I say that because at least from my perspective I don't care what LabVIEW does with memory, but I've seen other text based developers get hung up on trying to understand the low level of what is going on. The compiler is better equipped to do as it pleases, releasing and reallocating memory as it needs. I trust the compiler until I see a reason not to (crashes, or run away memory). I suggest you do the same, trust the compiler. You stated that memory is released properly when you close LabVIEW, and the memory is reused within the application when it needs to be so what is the problem? Where is the bug? If it doesn't release the memory then it must need it for a reason that I could not predict. I do not see is as a bug, and I deal with very large amounts of data in the form of larger sized arrays of clusters of arrays all the time.

I have never seen this mentioned before. I have a 4 channel 400Ks/s device and I can read all 4 at once at 100KHz each. Maybe what the NI tech support was trying to say is that when you are maxing out the speed of the card and switching that fast, you usually end up with a "ghosting" affect where the other channels appear on top of the wrong one because the impedance of the line is being affected by the previously measured channel. For this reason adding some extra time between channel reads is a good idea, or even reading the same channel twice and throwing away the first reading as suggested in the linked article.

Nope not going to find a m series equivalent card, and suggesting an Arduino sounds crazy now that I know what you wanted it for. Sorry I don't have anything like that.

I really think given NI's support, it would make a lot of sense to stick with what they have available. Rolling your own sounds like a big undertaking and while I really enjoy owning my own tools, the time and effort needed in building, deploying and supporting them just doesn't seem like a good idea. Especially on a thing that involves testing code components. Sorry to hear the NI solution is slow but because you have a license you should be able to get some support from NI to investigate this, or at least get some feedback from them. JKI's timing for their VI Tester was unfortunate. I felt bad for them when I heard the Unit Test Framework was coming out in what felt like a few months after the JKI one. As a result I get the feeling JKI is focusing their attention on other tools that they have a competitive advantage with.

What is the NI-9134? I searched NI's site and couldn't find anything on it. I ask because a cheaper option maybe to use a m series USB solution depending on your needs. They have a variety of AIO and DIO usb devices but without knowing what the 9134 can do I can't suggest an equivalent m series device. And even cheaper still depending on your hardware needs, is a Arduino running the LIFA toolkit which can be used for DIO and AI but no AO. Again depending on your needs that may be an option.

I was thinking about it and I wonder if when LabVIEW first introduced event structures, if people had one event structure for each control. Certainly not knowing the intended way to work with a tool is a common way to use it improperly, and generally speaking having multiple event structures is a red flag for this. But when advanced users know what they are doing, powerful things can be done with these tools.

Why are you using that function? The reason I ask is because no program that I have ever written has needed it. Every time I see it used it didn't need to be. I'm not saying it doesn't serve a purpose I am just trying to say you don't need to use it. That function as stated will release memory not being used. How do you know which memory is not being used? The compiler will decide what memory it needs and doesn't and will best optimize itself. So you running that function may do nothing and that would be expected. Or it may do something but what the something is, will likely be unpredictable. My advice is to just trust the compiler and not use that function to release memory, unless someone at NI has said to for some fix to an issue. EDIT: Okay after re-reading the function description I think it could be used and have some benefit in some programs that perform some work seldomly, and you want to discard the data before exiting the application. One reason your code may not work is there is a race condition, where you are requesting a deallocation in parallel with creating your array. Perform one then the other using some data flow or sequence structure.

That's great but doesn't answer my question. Why aren't you just calling the subVI like normal? Drop it on the block diagram using the Select a VI... from the block diagram. If you can show some code, maybe a simplified version of what you are doing it may be easier.

Yeah I've used this technique. Newer versions of LabVIEW have issues with this but I have had some minor success in trying it. More research is needed. At some point it does get a little ridiculous trying to develop in 7.1 when you are used to modern features. And my modern I mean things like Listboxs with the properties and methods you are used to. And of course I'm familiar with the segmenting of the RTE. Very cool stuff I haven't got around to messing with it yet, but is another option for sure for a situation like the one I described.

Lets say you have a set of customers that each have some version of LabVIEW run-time engines installed, but not sure which ones. You can't build a LabVIEW EXE to give to them because you don't know which one they have installed and if you give them a 2013 EXE but they only have 2011 it won't run. You could send them an installer with the 2013 RTE but that is ever growing and can be a pain to download when the customer isn't sure if they need it or not. Well my idea is to use AutoIt to get a list of the LabVIEW versions (development or Run-Time) and then choose to run a EXE built in a version that is compatible with the version installed. This means building your EXE in multiple versions of LabVIEW and for larger applications this may make less sense then just distributing the full RTE for a single version of LabVIEW. Attached is my source. Extract it and you have a Source folder with the project and VI that just reports the LabVIEW version and path. And a Builds folder which has the AutoIt source (au3 file) and the built EXE from the au3. This EXE should run on any version of Windows XP and newer. Then there is a folder of EXEs all built with different versions of LabVIEW but from the same source. When the AutoIt EXE is ran it finds a RTE compatible with an EXE that is included and runs it. In the zip is version 2011, 2012, and 2013 but to add others just add the folder and EXE named the same as the others. I wouldn't be surprised is someone like JKI or Wirebird Labs has done something like this in the past but I thought I would share what I have done anyway. My use for this is with a new and improved version of my LabVIEW Tray Launcher. It is assumed if you are using the tray launcher that you have a version of LabVIEW installed, but which one? I could distribute multiple versions in a single installer, and then have the shortcut launch the AutoIt EXE which decides which LabVIEW EXE to run. I haven't fully tested it but it appears to work properly. EXE Test.zip

I think it is a bug but NI may disagree. The only other thing I have to add is I wanted to see what control LabVIEW though was in focus and found a private method called "Text Focus" using the front panel reference. By the way I think this method should be public if NI is listening. In either case when I went to read the control that has focus it returns a reference with a value of 0 once you enter the Mouse Down? event. So this means that even before the event structure has a chance to discard the mouse change it will already have lost the focus so by the time LabVIEW discards the mouse down it will be too late. I also tried disabling the control and it still would steal focus. FocusLab hooovahh.vi

I'm a little confused? Is there a reason why you don't just call the subVI like normal? What you are doing here is opening a reference to the VI by name. This will only work if the VI is already loaded into memory, and depending on your setup it may not always be, especially if you build it into an EXE. After the open you are closing the front panel. But the front panel was never opened so it will generate an error unless you already have the front panel open for some reason. All you did was open a reference to the VI it was never ran, so the code you are showing will not open the front panel. If you are trying to run the VI asynchronously use the Start Asynchronous Call function is the easiest way.

Is it very reproducable? Can you make it crash every time? If so this makes life a little easier. I'd recommend disabling large parts of the code and see how it effects the crashing. This can help narrow down what code is causing the issue. If I had to guess I would say it is likely a bad DLL call, or a .Net function that isn't being used properly.

Nope, I've never used more then one event structure in a single VI. That being said hearing how others use it it doesn't sound like a horrible situation as long as you know what you are doing. There are pitfalls that new developers will likely get caught in, but I feel like there are plenty of places that LabVIEW allows you to shoot your self in the foot. So while it wouldn't affect my development at the moment, put my vote to "This should probably just stay the way it is"

I don't know if I fully understand what you are talking about. You have a look up table so I get the feeling you aren't reading an analog channel but instead are using that table as an output but your topic clearly states "measurement" Please also try to use terms that are more appropriate. The "Refresh Rate" can mean many things. If instead you said your output rate, or sampling rate then it would be more clear what is going on. We will need more information to understand what you are doing. Post some code of what you are doing as well if you can.

XControls are wonkey at best. Every time I try to make one I find my self coding around issues with them. I'm not saying this is one or not I just haven't had good experience with them. One time I remember having a system Ring control that I had some difficulty with for updating items, and allowing a right click menu. I can't remember what didn't work about it but as soon as I replaced it with a classic Ring it all worked fine. I posted this issue at NI when I had it but it didn't go anywhere.

Did you mean to attach something to that post?

I agree but there has to be a limit right? When LabVIEW was first developed maybe 32x32 was a good size. Maybe they didn't have very complex sub VIs needing a bunch of inputs and outputs. If you do want another way to view a subVI you can right click it and choose to un-check View as Icon. Then you can resize the subVI (dragging down) and your terminals will be displayed in a larger manner.

I believe the built in function mje was referring to is the graph cursors. Right click the graph go to Visible Items and choose cursors. Then you can make a cursor that will snap to existing points. There are several examples if you search the example finder. One is called Programatically Control Cursors but I have seen some other's that work better and can and and and point out the maximum value of a graph. Again if these functions don't meet your needs you can just draw a picture and put it on top of the plot using the property nodes of the graph it self.

How about keeping track of which database connections have been made. Then when a Mouse Down event happens on the string control disconnect any database connections that are open. If none are open then do nothing. If one was open from the last session then close it.

I like how you actually handle window resize properly where a very large majority of the custom probes do not. I also like the ms timer column. Have you ever thought about having a dt column? Or replacing the ms timer with a dt column? I only ask because it isn't too important to me that case A was handled at 3946013 and case B was handled at 3959319. What is useful is how much time went between the two cases, which can tell me how long it took to execute case A. I can of course get that information if I do math but it would be nicer if the probe did it for me. At the moment I'm using VIBox Probes by SAPHIR which has a History Probe for strings. This has a few features yours doesn't like being able to set the history length to a number (not window size), and being able to pause based on the string value. One feature neither you nor the History Probe has that I've thought about is the ability to Pause the probe. I haven't needed to use this feature yet so maybe it is stupid, but I wonder if it would be useful if you could press a button and then have it no longer update the probe with new values but have the VI run like normal. My use case is what if my VI is running like normal, and then I see some case happen that wasn't expected. The probe will overwrite its values if the VI keeps running and handling cases but I may want to see a snapshot of the cases that were handled to figure out what led up to going into that case.

Yup that was what I was thinking. Possibly a ring with the string values in a look up table or something so you don't need to read the string values with a property node every time you want to know which item was selected. Although that gets me thinking. So with an Enum we can read what all the possible values are using the OpenG Get Strings from Enum function. Is it not possible to read the string values of a ring control the same way because that information is not contained in the wire, only the numeric representation is?