Neil Pate

 

I don;t see anything in there about loading block diagrams in different versions, though.

Whoooosh....

In the seven or so years I have been dabbling with LVOOP not once have I said, "gee I am so glad that a class maintains its mutation history". Maybe it's just the kind of applications I develop, dunno. I never serialise my classes directly to disk.

Also have seen some terrible editor bugs that can be traced down to stale mutation history in a class.

Sorry, sounds like you know more than I do about shared variables. Can you see the variables using the Distributed System Manager?

Have you taken a look at Network Streams? I find them much easier to setup and debug when things don't work. Think of them as TCP/IP with all the re-connection and other management stuff taken care of. 

It may be down to the fact that the hostname portion of your variable URL (i.e. RT CompactRIO Target) does not make sense when running the code in the context of the cRIO.

Try something along the lines of ni.var.psp://localhost/ etc etc

I am not a big fan of shared variables, and try and avoid them whenever possible.

I kinda like manually adding in the Action Engine wrappers (which I do religiously for FGVs and Action Engines). I create them one at a time and test them out as I flesh out the test harness.

Sure, takes a little bit longer (than scripting for example, or using GDS), but it gives my brain time to think about the names chosen for the enum values and the names of the wrapper VIs. Often holes in the API become obvious just when thinking about how the accessors will be used.

I believe this is by design. Occurrences are slightly different to other kinds of reference (like notifiers etc) and the actual occurrence reference is determined at compile time or something like that.

I remember reading something about this on ni.com years ago. Will try and dig it up.

It's been a while since I did mine, so my memory is a bit rusty, sorry.

I think I did not use a template as it would have required too much changing in the heat of the exam (I don't really like the templates shipping with LV), but I did borrow some elements from some of the templates though. The one thing I think I did re-use was the queue handling mechanism as this was neatly wrapped up and easily copied out a sample project.

Don't beat yourself up, the CLED was one of the toughest exams I have done. Three and a half hours in I honestly felt like getting up and going home (to sulk), and I am pretty sure ten years ago I would have done that. Instead I managed to knuckle down and passed.

In the exam I also had some weird connectivity issues with the RT target, and spent way too long trying to get my build to deploy properly. I probably wasted 30 mins doing this before saying screw it and just leaving it.

I remember someone having issues with DAQ threads at some point and fixed it in an exe. I believe all you have to do is copy the appropriate INI keys from labview.ini into your exe's ini file and the runtime will allocate the right number of threads on launch.

Thanks for this tip.

I have made the change and now I just have to wait for my application to fall over (or not fall over, hopefully!).

Searching `site:ni.com 313508` leads to: https://forums.ni.com/t5/LabVIEW/Process-freezes-for-a-few-seconds/td-p/2309090

 

Does your application have a similar number of parallel "actors"? (the original post in the thread above mentions 52 parallel "actors) What does CPU usage do during this pause?

 

If you have a lot of parallel loops, and if CPU drops to near-zero during these "pauses", you might be exhausting the thread pool per execution system in LabVIEW.

 

If this sounds like the case, try bumping the thread count higher than 20 (the default). To do this, use `threadconfig.vi` which will then create 25 or so entries in your `LabVIEW.ini` file, then manually edit those numbers using a text editor to be higher (e.g., 50).

<possible thread hijack>

Jack, I had tried to do something similar with the threads just yesterday.

Do you know how to achieve this in a built executable? Unfortunately threadconfig.vi is a GUI type VI, so not really able to be embedded into another application. I was able to get the contents of this VI and remove the GUI aspect and then inserted it into my code. However I am not really sure this will do what I want as I do not know if it is possible to modify the thread configuration from a running application?

Perhaps I need to modify the LV IDE settings before building?

</possible thread hijack>

And it sure it an interesting thread if you care about things like absolute timing on FPGA.

Thanks for the crosspost hooovahh I don't browse ni.com nearly as much as I used to.

Hmm, stuck with LV 2012 SP1 unfortunately.....

I wonder if they still work if I save for previous....?

Perhaps the VI Server/Scripting API for some of the stuff has changed, but I expect a lot of them would work. Annoyingly a lot of the other VIs  in LVClassLibrary are still password protected.

 

 

 Most are password protected

In LV2014 all the VIs in the NewAccessors directory are not protected.

 One of my pet peeves, though, is the read from file VIs They give an error 4 when you request more bytes than are left in the file.This has prompted a few of us to create a "filter" vi to reset error 4 which should be a warning at most, IMO.

Out of curiosity, why are you even trying to read more bytes than are in the file?

Create the background image you require (with pattern) and write it to Plot Image.Back (or middle, depending on the effects you require.

 

Then set the graph to fill to infinity with a white fill colour (or whatever colour your non-filled space should be).

That is about as cunning as a fox who's just been appointed Professor of Cunning at Oxford University.

Hi,

I am a UK based LabVIEW architect (also qualified as CLED and CPI) and am on the lookout for LabVIEW/systems engineering type work. My formal education consists of bachelors and masters in Electronic Engineering.

My professional experience includes significant exposure to virtually the entire LabVIEW stack (PC/RT/FPGA) and I have done work in a diverse range of industries including Formula 1, Telecommunications and Aerospace.

If you are in need of a skilled LabVIEW architect, for any size project, please do not hesitate to contact me via this forum.

My CV is available on request.

I know nothing about the internals of LabVIEW on this one, but would be a bit surprised if the parents knew about their children, it is more likely to be the other way around surely?

At runtime you can inject new child classes, so surely this means the parent must have zero knowledge of children?

I'm using git, and because of its decentralized nature, there is no one incrementing commit number that I could put into the "build number" field. What I decided to do instead is:

• Create a tag in the VCS (which is just a named pointer to a commit) which is following the semver notation
• If building a Windows application
  • Write the tag info into the major / minor / patch fields of the build spec
  • Write the build timestamp into the description field of the build spec
• If building a source distribution
  • Append tag label and build timestamp to each VI's description (so it shows up in context help)
• Automatically create a readme file that is distributed together with the built package (.zip in my case) that shows project name, version info, changelog (all commit messages since last tag) etc.

After playing around with pre-build VIs for some time, I decided that I wanted more of a continuous integration type of tool / process, so I started automating the whole build process (I wrote about that here, amongst other places).

 

Executing a build specification has always the purpose of releasing an application or source distribution. So I made the creation of the tag in the VCS the starting point of my build process (my gitlab repository will then trigger a Jenkins task on my local build server, but manually invoking the build tool does just the same).

 

The build tool will first check the working copy for changes (or rather, the absence of any), then run some VI analyzer tests, read the tag name associated to the latest commit, update the build spec fields and/or VI descriptions, create the readme file, execute the build spec, create the release package (.zip), and copy that package to a local directory which is synchronized with my web server.

 

I run Dokuwiki and created a plugin that uses the gitlab API to read all tag labels for a given repository, and then automatically displays all available files for that tag label as download links.

That sounds like a very thorough process, and miles ahead of most of what I come across. Is there a jealous HTML tag?

Quick show of hands, does anybody actually use the Build Number in executables? I use Major.Minor.Bugfix, but never build number.

Perhaps this would be useful when using some form of continuous integration type processes, but by far on the projects I have been involved in or seen all the builds are done manually by the developer (and thus the version components are manually bumped). In this instance a new build almost certainly correlates with either a bugfix or a new feature.

Thoughts? 

Try this

Could it be default data saved in the class "cluster"?

That or mutation history as James suggested are the only things I can think of that would make the .lvclass file so big.

1. NI_procmphier.lvlib:CMP compare two VIs.vi 

Where did you find this library? I do not seem to have it in my LabVIEW directory.

Indeed, the writeup on how they managed to get CGA to display 1024 colours is fantastic (and way way over my head).

http://trixter.oldskool.org/2015/04/07/8088-mph-we-break-all-your-emulators/

 Maybe its just the nestalgia.

Is that like home-sickness for birds? 

I have a Microsoft Surface Pro 2 and I find it a good fit for LabVIEW programming

This is quite interesting. I really hate doing any real programming on my laptop using the touchpad (on a flight for example). Sounds like the Surface solves this problem!