Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by MikaelH

  1. On 07/06/2018 at 7:38 PM, 0_o said:

    Just a thought... try running LV as admin after first upgrading to 2017. Check to see if there are no file permission issues or password protected vis.

    I tried running as Admin, no changes, it still freezes

    On 07/06/2018 at 5:03 PM, shoneill said:

    Does LV freeze or crash?

    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.

  2. 2 hours ago, ShaunR said:

    I think you are going to need NIs input on this one.

    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.

  3. 3 minutes ago, ShaunR said:

    Or do you want a compile time of 7 hours instead of 20 minutes ;)

    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.

  4. 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?

  5. 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?


  6. On 12/6/2017 at 5:37 AM, Porter said:


    LabVIEW's formula parsing VIs are located within "NI_Gmath.lvlib". This means that even if you just use formula parsing, you need to load the entire Gmath library. This is a very big library!

    This becomes particularly noticeable when building a stand-alone executable. Here are the results from my application:

    With NI_Gmath as dependency
    - Exe size: 40.6 Mb
    - Build time: 22 minutes :throwpc:

    With muParser instead of NI_Gmath:
    - Exe size: 29.4 Mb
    - Build time: 8 minutes :thumbup1:


    How about 64 bit support :-)

  7. 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


    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



  8. 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.

  9. 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?



  10. 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.


  11. 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.


  12. I think going by reference object shouldn’t be considered difficult or hard. Most other languages are using references so why shouldn’t a LabVIEW developer succeed in that task?

    We have around 20 LabVIEW developer at the office here, that are all using by reference objects without any problems. Half of the guys are just users of the By Reference instrument driver layer (200+ drivers). And since all NI hardware drivers (DaqMx, Vision, Visa, FileIO) already are by reference it makes sense to them.

    So if you can handle the Queue VIs you can handle a by reference lv-class.

    One of the current application I’m working on has 36 motor driver objects of different types, more than 50 digital input/output objects, vision cameras, a bunch of standard instruments of course and they are all by reference objects.

    In my case I wouldn’t dare to go by reference value objects here ;-)

  13. My employer have installed Digital Guardian Windows Agent on all our offices computers in most countries. It monitors all your file access and transfers to and from you PC. The idea is to prevent people to transfer files out from the company to any competitor (INTELLECTUAL PROPERTY PROTECTION).
    I guess it’s a good to try to prevent this, but it makes the PC much slower and also breaks LabVIEW from time to time.
    I heard that they are not allowed to install it in some countries in Europe, since the monitoring it performed of you breaks some countries laws of “Surveillance in the workplace”.

    The DgAgent.exe could have many different modules activated, e.g. monitoring all file movement, hard disk encryption, prevent saving files to any USB device
    Some of the problem it has caused us are:
    We couldn’t build executables anymore.
    The last step when LV zips all files up and adds it to the exe file was treated as a threat, so the exe file got deleted by the agent.
    File writing failed, because the folder that was created a millisecond before the file was written to that location, was not really created, it was delayed due to the hard disk encryption. So we had to use the magical delay fairy between create the folder and writing a file inside the folder.
    So if your IT department wants to install DGAgent, I’m sure you’re going to have some interesting problems in front of you.

  • Create New...

Important Information

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