Neil Pate

That I think is the root of my problem, I was *not* using 1588 (which I presume you set up in the RT system ini file?), rather manually getting time updates over UDP and manually adjusting the system clock (i.e. in code). Doing this too quickly (i.e. more than a couple of times a minute) seemed to cause my RT code to crash horribly (some bits were still running, but not most of it). This happened on a bunch of new cRIO-9024s

Thanks Lewis, I definitely should have spent more time getting things actually working 100% rather than documenting and making things tidy (which, unfortunately for this scenario is, is just a habit of mine).

I recently had some nasty issues with doing something very similar. I have reasonably solid evidence that setting the system clock too often could case the cRIO to crash. I was trying to sync the cRIO clock from a master PC. Something I wanted to try (but never got around to doing it) was to use a time sync protocol rather than "manually" doing it in the RT code.

Thanks James, congrats on yours too.

Got the result of my CLED exam today, passed

I have several legacy applications that all use the web server to display snapshots of their FPs. The existing application was written in LV8.5 and I am in the process of porting it to LV2013. I have noticed that every time I build my application the niwebserver.conf file in the build directory gets overwritten by the one from the <LabVIEW> directory. Does anybody know of a simple way to stop this from happening? I have tweaked my niwebserver.conf file for the specific application, so I would rather not replace the one in <LabVIEW> with this new one. I am thinking about doing a post-build step to copy over the desired .conf file. Any other ideas? Edit: doing the post-build step was pretty trivial. Problem solved!

Ok thanks Michael, just glad to know I am not going crazy

Hi Admins, I have recently started to see adverts in this forum, is this expected? I am a premium member so I figured these would stay hidden (and I am reasonably sure they used to).

Bingo! It just took me a bit of time to realise it :-) For a long time I resisted putting everything in a single loop as having the Event Structure in a separate loop kinda fools you into thinking you can respond quickly to events, but you cannot really as you say because the lower loop is tied up doing something else.

Pretty much all of my existing code used this two loop structure per module as well, but I have recently seen the light (drunk the kool-aid?) and swapped over to a single loop with the Event Structure just as one "step" of the module (now I like to call them Actors ;-) .. Takes a bit of thinking about as any long running processes (i.e. stuff happening in another diagram) can really scupper things, so now you need to do things like spawn off workers etc.

Every time I resized the screen or dragged my browser (chrome) window from one physical screen to another the hangout restarted for me from the beginning of the recording, but it was quite easy to just click the progress bar to catch up to the live broadcast.

This is what I used to do (using SVN) as I was scared that moving files using the LV project would break my VCS. Actually it turned out to be a far bigger pain constantly re-finding VIs in the LV Project. Now I perform all file operations using the Project window and I just rely on the VCS tool (I use Hg now) to figure out what has gone wrong. Sure you may lose some of the file "history", but at least most of the time the LV Project does not get confused.

How big are the images you are writing to disk? I would have thought that the bottleneck in most systems would be the speed of physically writing to disk, not the passing around of the data in the software. Modern CPUs/RAM can shovel ridiculous quantities of data around if the software is architectured properly.

Dequeue with -1 timeout should use virtually zero of your CPU resources. You can rely on this mechanism on RT the same as your do on the PC. RT-FIFOs do have the option where read and writes are polling (using CPU) or blocking (CPU sleeping), but as you state you are using queues and not RT-FIFOs then this does not apply to your application. Is it possible that perhaps something else is going on that periodically causes a big CPU spike? If it is a quick event you may not notice it in your CPU profiling code, but some other bit of code may be affected. The other culprit could be timed loops. Are you using any?

This is good to know about. I use Ultramon so am surprised I have never seen this issue. As you said in the other thread hooovahh, I do not know how people manage to develop large applications in LabVIEW without tremendous quantities of display pixels. The more the merrier for me these days. I have a 19" vertically oriented monitor on the left dedicated to any open .lvproj windows, a 27" to the right of that (so in the middle), and another 19" to the right of that and still wish I had more space at times!

Totally agree with you, but... Very very small probably if you set the CWD immediately before calling the DLL function. I suppose deciding whether to use this function or not depends an awful lot on the risk of something going wrong combined with the likelihood of it happening.

To follow on from what Rolf said, you can programatically set the current directory using the Win32 API. This is often convenient if you know your DLL is in a certain place. I did use this technique many years ago, but have not needed it since. To get an idea on how to do this look at the attached VI (obtained here). Set Current Directory.vi

Bingo! 9 months later...

Hi Rolf. I have cherry picked some of the good bits out of your library and put together a very simple application that uses the TCP prims (rather than the NI HTTP library) to do my Web Service query. It works fine from my PC (no proxy server), so now I need to wait and see if it works for my client. Thanks!

Cool! I will take a look at this a bit later today. Thanks for your help

Thanks for the insight Shaun. I do recall seeing Rolf's HTTP VIs, and this is what in fact lead me to believe I could just prepend the proxy, but probably I just misunderstood. I don't really know enough about this stuff so I guess it is time to learn something!

Hi All, I have an application which uses a Web Service to talk to a LabVIEW based server, somewhere on the internet. The application works very well under normal circumstances, but I am having some trouble getting any comms through for one particular customer. The difference for this customer is that I know they use a proxy server for all web traffic. I have not had much exposure to proxy servers, but my understanding is that if I just prepend the proxy server IP address (or name) to the "address" of any http type requests everything should work fine. So in other words, if I normally call http://mywebservice/testmethod then to get this to work with a proxy server I would just need to re-direct my request to http://myproxyserver/mywebservice/testmethod Is this correct? If so there must be something else going on as I have tried this and still cannot get any comms going. The IT guy I am working with says none of the requests even get to the proxy server. Has anybody done any work with Web Services and proxy servers?

Definitely have to disagree with you here. depends... do they want something quick and dirty that will help them right now, or something with more thought (and probably neater) that will probably serve them better in the long run. Different clients have different requirements. Anyway. I am not really moaning or anything. If I fail it due to missing functionality then next time I just better not take the five pee breaks I needed this time around

You can get the Inno setup to execute another application as part of the setup, in the example pasted below I execute the RTE setup exe. Note I have manually extracted the RTE so that it consists of its bits and pieces. You also have to tell Inno to include the files in the setup (that is the [Files] section) [Files] Source: "C:YOURPROJECTNAMEResourcesInstallerLVRTE_Extracted*"; DestDir: "{tmp}LVRTE_Extracted"; Flags: recursesubdirs createallsubdirs [Run] Filename: "{tmp}LVRTE_Extractedsetup.exe"; Parameters: "/q /AcceptLicenses yes /r /disableNotificationCheck"; WorkingDir: "{tmp}LVRTE_extracted"; Flags: waituntilterminated; StatusMsg: "Installing LabVIEW Run-Time Engine"

I think perhaps the design, style and documentation should be worth more. I have a pretty high level of coding standard (i.e. block diagram neatness, comments etc) that I always try and aim for. This is ingrained in me after more than 15000 hours of doing LabVIEW. As such, it is very difficult to override this instinct and code "messily" just to try and get all the functionality in.