Jump to content

MikaelH

Members
  • Posts

    815
  • Joined

  • Last visited

  • Days Won

    44

Everything posted by MikaelH

  1. Hmm, you are probably right, we only had this issue on all out W7 PCs.
  2. Have you tried appling patch: KB2999226-x64.msu ? That fixed our problem. https://support.microsoft.com/en-au/help/2999226/update-for-universal-c-runtime-in-windows
  3. Just an update, NI has found and fixed my issue, it's just a matter of time when we'll get a patch for this, maybe I have to wait for the Service pack before I can migrate to 2018.
  4. I've done lots of small mass compiling to see if that solves the issue. But no luck yet, but I'm getting closer it looks like it freezes when it load projects using the Vision module. We need to use 64 bit on quite a few test system when we use lots of vision stuff and/or testing multiple units at the same time (capturing heaps of data, maybe more than we need) And some larger project can't even build an exe, LV runs out of memory during the build process.
  5. I've now done a source distribution of all the code and the code open in LV2016, but not LV2018. I'll zip this up and send it to NI for investigations. (I'll just remove all sensitive IP stuff, even with missing VIs LV2018 should freeze but it does) I'll keep you posted about the progress.
  6. I tried running as Admin, no changes, it still freezes In some instances it really freezes, but after mass compiling sub components I could get the project window to open up, but it still doesn’t become responsive, but I can see that the CPU usages goes from 0% to 0.1% from time to time. So I left it over this long weekend(3-days) but still frozen when I got back to work. My next step could be to re-compile/save everything in LV2017, and then try 2018. But it shouldn’t make too much of a difference since we have all compiled code saved outside the VIs. I could also try to add the compiled code into the VIs and see if that does the trick before opening the code in 2018.
  7. I've reported it to my local NI office, but they have not found any records in the database about other people having this issue. And I can't send them the code to test it themselves due to IP. I guess I just have to slowly open small parts of the code to see what VIs are freezing LV.
  8. Sure that is annoying that it takes 2 hours to build an exe file of my larger OO based projects. But I just make sure I have a few copies of the LabVEW.exe file so I can start another LV instance while the other copy of LabVIEW.exe is building. For me to handle >100s of IOs/Motors/Sensors/Benchtop instruments without OO feels impossible.
  9. I’m happy it works for you. Some projects I’ve tested works, but one of the very large ones just refuses to re-compile everything. It’s frustrating since I’m the one pushing all LV developers to get ready to migrate to 2018
  10. The first project I’m trying to open and convert to LV2018 just hangs LabVIEW 2018-64bit. It looks like it gets stuck when it tries to re-compile all VIs. I have all compiled code stored outside the VIs. It’s a very large project, I’ve tried using the mass compile feature of the folders I use before I open the project, but still no luck in opening the project. Has anybody else seen this?
  11. Mark has already uploaded them to: frc.tecnova.com
  12. What toolkit are you using? I have this installed and it's not password protected. But we use the ADO tool kit
  13. I love the Picture Control, it's very fast if you use it correctly. I developmed the whole GDS UML modeller (http://opengds.github.io/) based on that. One performance issue is if you draw lot of text with a none default font size, then it becomes very slow. Make sure you use Smooth updates, and I always use Erase first. What does the shft register make it poorly? Do you have an exmaple where it's slow we can look at?
  14. How about 64 bit support :-)
  15. If you've installed NI-GDS or OpenGDS, you can see how I did the Rename Class function: LabVIEW 20XXresource\Framework\Providers\Open_GDS\ClassProviders\Provider_LvNativeClass\ClassWriterNative_class\RenameClass.vi http://opengds.github.io/ But basically you have to do this: 1) Open the library/class 2) Get All Descendents (and get the Path for all items, if ite you find is a class or libraray, you need to iterate through those as well) 3) Save found items to new location. 4) Save all items again
  16. Yes, I mean when the VI finish, and it goes back to edit mode. I do stop all the VIs in a clean way, and ask them to be remove from the sub panels before the Vi finish. I will try to create a small application that shows the issue to NI.
  17. I have an issue with a Sub Panel in a generic GUI VI we use as part of our company's OO based application framework. Most often the SubPanel behaves like it should. But sometimes after the application has stopped, the VI that was last inserted into the SubPanel, is still inserted according to LV. When this happens (and I start the application again) I can't insert that VI into the SubPanel again, I can insert other VIs, but if I try to insert the last Inserted VI, LV says: Error 1145: Cannot open VI because it is already in a subpanel control. If I try to open the VI's FP, LV opens the FP of the GUI VI that has the SubPanel (just like it should if it was inserted), but the SubPanel is Empty. And LV behaves the same, even after the SW stopped?!?! When LV stops all SubPanels should be emptied (i.e.all inserted VIs should be thrown out.) Has anybody else experienced this strange behavior? Our framework is doing something that LV doesn't like of, but I haven't figured it out yet. We do see one strange behavior as well. We start up the framework with a VI that kicks off some processes (just like you do in Actor Framework), and when the framework starts up and starts inserting stuff in the SubPanels, the Top VI becomes broken, but it's still running. Have you guys seen this as well?
  18. I would just create a simple DVR reference class that handles the INI file. You can just use the IPE-Node structure as your semaphore.
  19. I would guess the extra time penalty for using a Path input to the CLN, is the first call LV does to the dll, when it need to load it into memory. After that it already has it in memory so it will be as quick as the normal option. I prefer to have the dll inside the node so I know it gets loaded in memory when the application starts and also that I know that the right dll will be included in my exe-build. We use the conditional structure node for this. It’s lots of extra work to put a conditional structure around every DLL call, but we have a scripting VI that helps us with that task.
  20. Sure for our RT/FPGA project we don't have a choice. For DB, we don't use NI's tool, we use LabSQL ADO
  21. The most annoying thing we've had with going 64 bit, was with NI's Motion drivers that only has a 32 bit dll, so we made a LV-32 bit wrapper exe file acts as a server for that, so we can have all our code in LV-64bit. There are some vendor's drivers that only have a 32 bit version for those we do the same thing, we have a small LV-32 bit server that handle that driver. We have a few projects that can't build if we stay in 32 bit, (I guess the amount of classes we use makes the build require much more memory that a traditional LV application). Also some of our projects requires more than 4G of ram when running.
  22. Do you have a compiled 64 bit dll? I thought everybody had migrated to LV-64 bit nowadays?!?
  23. Here is just a snapshot how much the DGagent is doing in the background. These are the task it does during a 5ms time period, it makes your faster computer start crawling.
×
×
  • Create New...

Important Information

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