MikaelH

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

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

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?

Mark has already uploaded them to: frc.tecnova.com

 

Excellent challenge, good luck.

What toolkit are you using?
I have this installed and it's not password protected.

But we use the ADO tool kit

 

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?

 

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

FYI

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 

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

 

How about 64 bit support :-)

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

 

 

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.

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?

 

 

Something like this?
(LV2016)

XY_Graph.vi

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.

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.

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

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.

 

Do you have a compiled 64 bit dll?

I thought everybody had migrated to LV-64 bit nowadays?!?

 

On 16/06/2017 at 11:10 PM, hooovahh said:

That DgAgent sounds nasty.

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.

 

 

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 ;-)

The bug is in 2016-64 as well.
Also if you remove one event it also defaults back to default view.

You seem to be safe if you never hide anything or if you hide all unwired terminals.

BTW I've not seen the old bug where the node got disconnected from the frame lately, maybe at least they fixed that one.

 

 

By using references objects you don't need to merge the data. It will solve lots of your problems, maybe create some new ones if you don't know what you are doing.

 

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.

One file looks a bit small/short only 1m 22sec

2017NIWEEK_403_Ching-Hwa Yu-Jianhua Liu_Automated Test of LabVIEW FPGA Code.mp4