Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


planet581g last won the day on February 3 2017

planet581g had the most liked content!

Community Reputation


About planet581g

  • Rank

Profile Information

  • Gender
  • Location
    San Francisco Bay Area

LabVIEW Information

  • Version
    LabVIEW 2015
  • Since

Contact Methods

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Can you show me how to make LabVIEW crash by doing this? I created and destroyed 1 million DVRs that were cast to integer and cast back to DVR and couldn't get LabVIEW to crash. Attached VI made with LabVIEW 2013. DVR to integer_2013.vi
  2. There's this reference design framework, but as far as I know it doesn't have scripting to create accessor methods. https://github.com/JKISoftware/JKI-State-Machine-Objects
  3. I'm happy to report that the bug seems to have been fixed. I opened the example code I originally posted using 17.0.1f1 (32-bit) and the buggy behavior has gone away.
  4. It might exist in 2015 as well? I realize if we can't make these issues reproducible then it's difficult to report. I'm going back and forth between two projects right now - one uses LV2015 and the other uses LV2017 - so I'm forming opinions about the apparent stability of each. The LV2015 project is YUGE!!! and it's mostly stable as long as I don't right-click on anything in the project Dependencies folder and select 'Why is this item in Dependencies?' which will instantly crash LV. The safer bet is to right-click an item and select 'Find>Callers'. So one of my few gripes with 2015 is I've seen some really strange dependency issues that have been difficult to track down because there are no typedefs, globals, etc. in these classes that would cause dependencies to exist. The LV2017 project only has about 50 classes so far, but the latest issue I'm experiencing isn't hard crashes, but the project getting stuck with a spinning wheel indicating it is working, but it just never comes around and I have to force quit the application. It seems to happen as soon as I right-click a class to save it after I've added some methods. I'll give it 3-5 minutes in hopes that it will finish whatever it is doing, but every time I eventually have to force quit and restart LV.
  5. I've been encountering so much strange behavior in the 2017 dev environment that I started taking screenshots of all the weird stuff I was seeing and I finally just gave up. I already mentioned the weird stuff with parallel access DVRs, but I keep getting some non-parallel DVRs where the wire in the DVR in place element structure is just broken for no reason. Reattaching seems to fix it for a while. One screenshot I did keep was an error state that occurred from a class appearing as a duplicate within a Typedefs folder (attached). Don't ask me how that happened. How can a class exist in two places? It certainly didn't exist in two places on disk and definitely didn't exist in the typdefs folder. Oh, and if 2017 seems to be eating up processor usage, but you have NO processes running and everything is just sitting there idle, try closing the breakpoint manager window if you have it open. That worked for me. Like I said, this is just a partial list...
  6. Glad someone else is seeing the same behavior in the example I posted. The fact that you were able to create a new VI and couldn't reproduce the behavior is indicative of what I've been experiencing. These bugs are intermittent, but the example I posted on the NI forums wasn't the first time that happened to me. LabVIEW didn't crash while I was working on the example I posted. I've got another example that exhibits the same behavior and uses code from the actual project I was working on. I haven't yet determined what will cause the code to compile that way, but imagine how difficult and strange it is to track down these bugs when all of a sudden your code just stops working. Another strange artifact I've seen by creating accessor methods this way is that sometimes LabVIEW has changed these VIs to reentrant execution and turned on inlining. I can't tell you how many times I've examined the execution properties and found these settings changed, yet I had never changed them. I definitely wouldn't turn on inlining unless there was a good reason to do it. What I've concluded from this is that DVR parallel read-only access is really buggy and shouldn't be used. It seemed innocuous enough that to turn it on for a read method shouldn't have caused any problems. After spending quite a bit of time developing a project in 2017, I agree with Neil Pate's sentiments expressed last week. The LV 2017 editor has some issues. I'm going to keep moving forward with this project in LV 2017, but if I had to start again from scratch, I'd pick LV 2015. The editor in 2015 seemed to remain responsive and snappy on big projects, unlike 2017 which will (at times) slow down to a crawl when all you're trying to do is move something across a block diagram. Additionally, I haven't mastered exactly when to press the 'W' key to turn of maintaining wire connections so that feature seems like more of a hindrance than it is helpful.
  7. I just posted this over on the NI forums. Can anyone else confirm. This seems really strange, but I still think I might be missing something. I've got a probe on a block diagram that doesn't agree with the data coming out of the VI that is the source. https://forums.ni.com/t5/LabVIEW/Parallel-Access-DVR-Bug-LV2017/m-p/3696695#M1039519
  8. You can easily instantiate a child class at runtime. You can launch your application with only the parent class in memory until you specify which child class should be instantiated. Each of your child classes can be placed in their own libraries (LLB or packed project library 'should' work). The path to the class in the library can be passed to the 'Get LV Class Default Value' function as shown in attached. However, without looking into it more, I'm not sure this really solves your problem since you are trying to load code that is specific to a LabVIEW version. It sounds like you want to create a parent class that can be opened with either LV2013 or LV2015 and then dynamically load a child class that could have been created with either LV2013 or LV2015. Is that correct? -Eric
  9. Do you observe the same behavior if instead of returning the 'AllObjs[]' property from the cluster and typcasting each to a control , you return the 'Controls[]' property instead?
  10. Well that all depends. If you've got TDMS files that you want to post process and or analyze, Python might be exactly what you want. That was the case for this particular project. It was considered advantageous to not require LabVIEW. Plotly was just used as the visualization tool after post processing the data. If the goal is to create some data in LabVIEW and display it in Plotly, then I agree that you shouldn't need to bring another language into the mix. I still think it's great that Adam Reeve put a tool out there that allows us to read TDMS without requiring LabVIEW!
  11. I've gone from TDMS to Plotly using Python. There's a guy who maintains a Python module for importing TDMS data to Python on GitHub. I've used it successfully on one project so far. https://github.com/adamreeve/npTDMS
  12. I guess I'm waiting for the day where I see a case study of a medium to large size LabVIEW app with the UI completely developed with a JavaScript framework. (Angular, React, Vue, etc). If pressed for time, I can't think of a good reason to do this assuming a standard LabVIEW UI can meet all the requirements.
  13. Shaun, would you be willing to elaborate on your process for doing this? Has this already been discussed and do I just need to be pointed to those discussions? I find this interesting, but it also seems like it would pose its own challenges. To do this it makes you a LabVIEW/front end web developer, right? Do you have a preferred JavaScript framework? Do you run into issues where browser updates break your UI? It seems like it would slow down development time so it might be a hindrance on customer projects that have aggressive delivery timelines. I probably shouldn't hijack this thread. If you'd be willing to discuss your methodology, I could start a new discussion. Eric
  14. I guess I'd need to see your code. Are your modules simply VIs that you call? If that's the case, you don't need to user events at all. Just stick each module in a different case of your case structure then send the correct string: module1, module2, module3. There's less work involved in doing that than there is in sticking each of those modules in an event structure. I wish ShaunR would chime in and try to dissuade you from going down the path of trying to call into the EXE using references since I doubt he would try to solve the problem that way. He was just providing you with an explicit answer to your exact question. I doubt he would suggest doing that if he were considering the bigger picture of what you are trying to accomplish. Eric
  15. Steven, I think this would be a useful feature. Don't we do this all the time on inputs by checking their values? Sometimes we are checking the values of inputs on VIs because we are actually concerned with the incoming value and sometimes we are checking because we want to know if the user of the function set the value (wired the input). Unless we actually comment our code well, it might not be immediately obvious what our intent was for checking the incoming values. The feature you describe would enable us to be more explicit about our intentions without actually adding code comments. Self documenting!! I remember sitting with Mike (VI Shots) once and he was wishing this feature existed. It was a couple of years ago so I'd be curious to see if he remembers saying that. Eric
  • Create New...

Important Information

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