Götz Becker

QUOTE (ohiofudu @ Oct 7 2008, 09:36 PM)

Dear all German LabVIEW Developers,

Any LAVA members coming to this years VIP?? it will be very nice to Meet at the get together party.

Grüß.

I´ll be there, but only Thursday morning to the R&D Keynote.

Grüße

Götz

QUOTE (Neville D @ Oct 7 2008, 06:07 PM)

Just as a test. That way you can narrow down the problem to Perforce or NI.

I guess it´s a mixures of both. When I disable SCC in the project loading of the main.vi is fast, but building is still slow while processing the vi.lib stuff. Network sniffing shows that as soon I start the build traffic to the Perforce server/proxy begins. When I disable SCC in the LV options building is fast and no traffic to Perforce.

I guess I´ll have to test with seperate LabVIEW.exes.

Thanks for all your suggestions

Greetings

Götz

QUOTE (Neville D @ Oct 6 2008, 06:27 PM)

I use Source Safe. I just check out the VI's, work on them and check them back in. No llb's.

Have you tried a project without the conditional disable's to see if thats causing the slowdown? Might be worth investigating. 10-20mins seems like a lot of time wasted for a build.

Maybe you can investigate Tortoise SVN. Lots of people on LAVA have good things to say about it; also its free.

Perforce is currently set for all our projects and I fear that mixing SCCs would do more harm than good. Currently we are testing a Perforce Proxy installation to speed up things... it "feels" a little faster (but processing of the NI_AALBase.lvlib alone takes about 1-2 minutes). Since we code on the same project with 4 people sitting in 2 different places, I can´t just check out everything (something I normally do when working alone on a software).

To get rid of the conditional disable structures would mean a major rewrite and reorganization of the codebase, another thing we can´t risk at the moment.

I guess I´ll try to talk to NI about that at the VIP 2008 this week in Germany. 

Thx for your suggestions.

my current guess is that the SCC (Perforce) checks in the background are taking very long (sometimes it looks like that some filestate caching is present). Also removal of unused library members takes time (vi.lib contents and the project has about 30 lvlibs).

NevilleD: Are you using SCC? If so which? 

Your questions:

1: no FPGA code

2: compiling for one PXI target only, but many VIs having conditional disable symbols inside shared VIs between Windows HostApp and RT

3: enough memory present (2 GB), but most of the time LV is below 10%. Only at the end one CPU core is completely used by LV.

QUOTE (KarstenDallmeyer @ Oct 1 2008, 09:40 AM)

Waiting for ideas ... with best regards

Hi,

one idea I have is, that this is a http://en.wikipedia.org/wiki/Network_Time_Protocol' rel='nofollow' target="_blank">NTP like server for FieldPoint devices. But I don´t really know for sure  :question:

Götz

Hi,

I just filed a feature request for background compilation for LV RT:

---

Compilation of a rtexe can take of large applications can take very long (especially with configured SCC) and is modal. This causes about 5-10 minute waits between start of a compilation and deployment of the startup exe. It would be _very_ helpful if that could be done in the background.

Maybe this could be done like FPGA compiling. Copy the VI hierarchy to a temp directory and start background compiling from there, ignore SCC for this directory as well.

---

How do you handle long compile times?

I suppose that our times come from all those background SCC checks and analysis of unused lvlib members, but since we can´t change that we are stuck with very high downtime during program/build/test cycles.

Greetings

Götz

Hi,

I recently learned that with an installed LV RealTime it is possible to use the RT-FIFO primitives in VIs running with Windows as target system.

Are there any pitfalls when using the RT-FIFOs in a Windows application? A quick exe-build of a VI with some RT-FIFO functions ran without problems on WinXP / LV 8.6.

My usecase is that we have a current project developed for RT in which the FIFOs are extensivly used (mostly for lowlvl communication in various HW driver modules). We now have a new requirement for this software to be run as stripped down version  (e.g. without closed loop control) on Windows targets. It would be nice if we could keep most of the code including these with RT-FIFO. My first thought was to replace all RT-FIFOs in conditional disable structures with the queue counterparts ( :thumbup: for the new lossy enqueue element!) but then all references would have to be replaced too, a road I don´t want to go down if I have a chance to avoid it.

Has anyone tried something like that?

greetings from a warm and sunny Munich

Götz

QUOTE (normandinf @ Aug 25 2008, 02:54 AM)

I simply monitored it in the Task Manager. It's not perfect because it monitors everything else along with LabView ...

This is one of my common usecases for the Process Explorer it shows the CPU and memory consumption of single processes (along with many other nice info).

QUOTE (Neville D @ Aug 14 2008, 08:06 PM)

Do you want to run RT code or develop RT code?

Neville.

Run code in the sense of trying concepts with RT only functions and doing tests with RT apps (no timing related tests) like file load/save or communication to a host app.

Hi,

is it possible to install LV RT under VMware? My thought usecase would be programming on my notebook for RT (without carrying a PXI around). I wouldn´t expect to test any time critical stuff, but running some general code should be possible.

Any ideas?

Hi,

last week I had to hunt down a strange bug in a LV app.

The usecase looks about like this.

The user can create a table with setpoint values in a small editor. As fileformat for this we choose TDMS-files with a waveform in it.

A host application transfers the file to a RT system (since all documentation calls the tdms_index files optional, we do not copy them). The RT app reads the wfm and uses the values for a motion control task.

So far so good a simple mechanism for a simple problem... but... a strange behaviour happened. _Sometimes_ the wfm weren´t completely read out of the TDMS file.

What happened is the following:

The user made a file (e.g. named "file1.tdms") with a wfm-length of 100 points. Transfered it to the RT (only the tdms file get´s copied) and starts the control task. At this point the TDMS-file functions recreated the tdms_index when reading the file for the first time. Then the user decides to alter the wfm in his editor on the host, creating a new one with a wfm-length of 1000 points saved under the same filename (file1.tdms). This file gets again transfered and read in by the RT app. But now the TDMS-file read returns only a wfm with 100 points!

The problem is the tdms_index file from the first read operation. It only knows about a "file1.tdms" with a wfm with 100 points. It looks like the TDMS function only use the filename to decide if and which _index should be used. No other check seem to involved!?!

Our quick and dirty workaround now is to try deleting the _index files before every load.

The attached VI shows the same behaviour under LV 8.5.1 Windows.

Download File:post-1037-1218464169.vi

Greetings

Götz

crossposted in NI Forums: tdms_index pitfall

I just found the time downloading LV 8.6. My first impression is that I would directly start a new project with it (unfortunally I´ll have to continue my current project in 8.5.1). Running inside vmware on a Mac I couldn´t really try QD but it sounds promising. The XML-functions and Webservices look nice (I just can´t wait to play with them) but I wonder why the "httpRequestID" is a plain U32 and not a refnum?

Hi,

I recently had a similar problem when integrating a driver which used NI CAN. It always had problems reinitializing itself (it obviously wasn´t developed for my usecase).

The ncReset.vi NI CAN KB Article helped a lot in my case (I didn´t want to debug the driver, making sure it closes all it references itself). 

I guess I didn´t take enough time to write me question in the first place. First my in case I doesn´t use indicators inside structures, just a control.

I am just not sure if and why LV would optimize the lower solution better. It´s not that important just something I wondered about

I just had a usecase in which I needed to update a nested element of a large structure. This involved 4 inplace (unbundle, array index, variant, unbundle) structures to get to the point where I needed the data from the control. The placement "felt right" in there... I just was curious about how "good" this would be.

Hi all,

does the "No Controls/Indicators inside structures!"-rule also applies for the inplace structure?

Hi,

does anyone has encountered problems with the PXIe-8130 RT Controller especially with TCP/IP?

Thank you for reporting.

After playing a little with join numbers I came to another behavior I wouldn´t have (naively) expected:

(both results are the same)

The implicit type cast of the signed inputs made total sense to me after a second thought and reminded me to always think (at least) twice about the bits and bytes underneath when using the data manipulation primitives.

Hi again,

I recently found another data conversion I don´t understand. Why isn´t there a coercion dot at the second join numbers?

LV 8.5.1

I know that this isn´t a good style for lowlevel data manipulation, but a hint from LV about the implicit byte that is added would be nice.

Crashing LabVIEW by feeding the equal primitive with a valid Refnum, was the first thing a coworker did, after I showed him this (yeah... on my computer... of course).

Another interesting fact is the absence of a coercion dot. I guess that would point towards a deeply hidden form of typecast.

Hi all,

I am having another hard time understanding the reason behind things. Coming from 42 as major answer my brain won´t come to an easy answer why this works:

Anyone around who would enlighten me, why this works and why it won´t work for other things inside the cluster like e.g. I32?

VI is in 8.5.1

Download File:post-1037-1213351859.vi

Greetings

Götz

Thx for sharing your code. Looks nice and I think I´ll play with it when I got time.

Just one thing I noticed while browsing the code. The timeout "Read TCP Data.vi" is only wired to the first TCP-Read. Although in normal conditions it shouldn´t make a difference.

Hi again,

I am thinking about extending my current usage of variants in realtime (PharLab) with a variant map (variant encapsulated in a functional global). I don´t plan to use it inside the time critical parts, but in the surrounding application logic (config data etc.). Has anyone already tested this on RT?

Greetings

Götz

Hi,

I recently found a nice presentation about the myths of Mac OS X.

Entertaining and interesting:

http://events.ccc.de/congress/2007/Fahrpla...ts/2303.en.html

Hi,

I got similar emails today while configuring a PXI system on the NI-Site. Since I was interupted several times while working on it, I guess the system thought I stopped and sent me 3 emails in 1,5h about my current setup. Less "feedback" would have been nice.