MartinP

I got my new quotation today, trying to sell me the subscription idea. I replied that I'll stick with my LabVIEW 2021 until further notice, and do not accept the new license model. I recomend all other LabVIEW programmers to do the same.

Martin

Danny

Well, regarding the f2 patch; installed on some but not all.

I'll make sure to install it all over, and see if that helps. Thanks.

Martin

John

Sorry, this has been the case all the way, so that's not it this time.

Martin

Well well weel, I'm back where I started, it seems.

I have now exactly the same problem under LabVIEW 2010, and the abovementioned workaround doesn't work any more.

Under LV 2010, I mean. Anybody else seen this ?

Anybody else that makes it work, having a FieldPoint IO Point control under LV 2010 front panel,

and making it work when running the executable ?

The problem appears when selecting the control, and a window pops up saying "Cannot load the Browse Dialog,

Some nessecary components are missing. To correct the problem, reinstall driver software that is assiciated with this control"

Another new issues under LV 2010 is that when operating the FieldPoint IO Point control under source code, this is working, BUT

LabVIEW uses 45-90 seconds before the Browse dialog comes up, every time, not only the first.

Seems to me NI has some serious debugging and fixing to do here......

Martin

I have seen the same phenonomen on several different projects now, on different computers, so I guess I can't pretend its not there any more.

My programs sometimes seems to be using extremely amounts of memory in LabVIEW (run as source code, not executables).

It does not seem to be connected to memory leaks, cause monitoring the memory does not reveal any slow expansion or anything like that.

It is as if there are some special events in LabVIEW 2010 that triggers heavily expansion of the memory usage.

For example, I have a project that normally runs in LabVIEW using a total of approx 325 MB.

But at occations I have seen that LabVIEW and this program uses 1.2 GB (!!) of memory.

Unfortunately I am now not able to see what events that causes this massive expansion in memory.

Anybody seen something similar under LV 2010 ?

Martin

Pick an XY-graph on your front panel. In source code, right-click and select

"Export simplified image". Works Ok. Compile into an executable, and run, richt-click

and select "Export simplified image". Your program wil crash. Confirmed by NI locally.

(Haven't tested the other charts and graphs, but I suspect you'll see the same thing.)

Martin

When using a FieldPoint IO Point as a front-panel object, it works fine in the source code.

When compiling into an executabel, the object doesn't work, however, cause it cannot

find all the resources it needs to operate. This has been confirmed by NI, which also has

set up a work-around;

1) in the folder for the executable, create a folder vi.lib

2) in this vi.lib, place a copy of the file event_ctls.llb

3) also in this vi.lib, insert in these subfolder the file \FieldPoint\SubVIs\FPLVMgr.dll

Martin

I'm using "Peak Detector.VI" to detect the peaks in data coming from a MassSpectrometer in the lab.

The raw data contains some noise that makes the subroutine detect not real peaks, and miss some real peaks.

To minimize this problem I thought I should smoothen out the raw data, and tried the "Savitzky-Golay filter.VI".

The data (curve) looks much better afterwards.

The only problem is that "Peak Detector.VI" is not able to find a single peak on the data, after

they have been filtered by the Savitzky-Golay routine.

I cannnot understand why that happpens. Anybody got any idea ?

The problem is well illustrated in the attached VI (LabVIEW 8.21).

Martin

When I set up a cluster of Strict Type Def, and the cluster contains a FieldPoint IO Point, it is not possible

to select a new FieldPoint channel. The new channel is not accepted.

If I switch the cluster over to only Type Def, it works Ok, and I can select a new FieldPoint channel.

This looks like a bug in LV 8.20 to me.

Martin