jgcode

Hi Kirsten Continuous updates is the default behavior of a slider (the VI is not even running): <object id="scPlayer" class="embeddedObject" width="302" height="249" type="application/x-shockwave-flash" data="http://content.screencast.com/users/jgcode/folders/LabVIEW/media/a4c9d65b-cb53-4c97-9179-4e4f37f1acd7/jingswfplayer.swf"> <param name="movie" value="http://content.screencast.com/users/jgcode/folders/LabVIEW/media/a4c9d65b-cb53-4c97-9179-4e4f37f1acd7/jingswfplayer.swf"> <param name="quality" value="high"> <param name="bgcolor" value="#FFFFFF"> <param name="flashVars" value="thumb=http://content.screencast.com/users/jgcode/folders/LabVIEW/media/a4c9d65b-cb53-4c97-9179-4e4f37f1acd7/FirstFrame.jpg&containerwidth=302&containerheight=249&content=http://content.screencast.com/users/jgcode/folders/LabVIEW/media/a4c9d65b-cb53-4c97-9179-4e4f37f1acd7/Update%20Slider.swf&blurover=false"> <param name="allowFullScreen" value="true"> <param name="scale" value="showall"> <param name="allowScriptAccess" value="always"> <param name="base" value="http://content.screencast.com/users/jgcode/folders/LabVIEW/media/a4c9d65b-cb53-4c97-9179-4e4f37f1acd7/"> Unable to display content. Adobe Flash is required. </object> What are you seeing?

Hi Felix This is the use case for the VIPC file. Each time you start work on a project you configure the workspace by applying the VIPC file. This sets the correct version of the packages ensuring that your first point does not happen. As for point two, VIPM allows you to scan the project for dependencies. This captures any new additions and updates the VIPC file. The VIPC files should be under SCC so you always have a snapshot of the current state of the project. It really is a beautiful thing.

As a followup to that topic - I have lodged this with NI Support and am still waiting to hear back.

I prefer using the IO Servers for connecting to Modbus (although have successfully used the above API in the past). NI Serial 3.7 (should be out now or real soon) now allows connection to e.g. RS-485 C-series module through the Scan Engine - which is great!

Cool, no probs.

Hi germ Some more info that would help - Have you tried re-installing the package? What version of the Variant Config package are you installing? What version of VIPM are you using Are they any VIs installed on disk? I.e. check <user.lib>\_OpenG.lib\variantconfig\variantconfig.llb - where variantconfig.llb is a folder not an actual llb. A screenshot of what you see is always handy. Is worth mentioning that JKI have a dedicated forum for VIPM too. Cheers -JG

Hi Jonathan There is a property node to check the current VI: Might be worth mentioning this OpenG VI too?: Cheers -JG

Cool vid!

Cool. Bummer! My library is in 8.2 and I am reviewing pulling it up to 2009 soon. I have programmed in 7.1 (by force) and don't really like it. Of course that doesn't help you - it's just me rambling again. One of the coolest things about VIPB is obviously the palettes - there just so much more work involved in doing it manually. But you still with a have the benefits as outlined in my first post wrt installation and management of reuse code using VIPM.

Anyone else would call it fence sitting.

Hey Felix - I don't know if I have understood all of your post correctly (so please forgive me if I didn't) but I thought I chime in anyway, to see if I can offer anything from what I do. I recommend handling reusable code using a workflow that includes a dedicated tool for reuse, and IMHO, by far the best one is VIPM 2010. OGPB is great, I use both together, but after sorting out some (of my) internal issues I am trying to move to VIPM 2010 predominately (this is a process I am just starting). Because most of the time VIPM is way better - meaning less work for me (namespacing, palettes etc...). If I was going to start a reuse library right now I would look at VIPM 2010 over OGPB as a standard. In the Community Edition (which is free) you can now build your own packages, so I can't see any reason not too. In terms of disk hierarchy I just have an internal project folder (like any other company >> project folder under SCC) that contains the source - broken down by packages - pretty simple. Packages get uploaded onto a server (share). And using packages make managing code across multiple versions of LabVIEW really simple. In order to support Client installs of development code, again IHMO, its far easy to install VIPM to do it, and then install the required packages (see below on this). Taking a step back in this discussion - one of the more traditional approaches is to copy reuse files from project to project. I know all too well the feeling of warm, fuzziness that comes with it as your project now contains all the files it needs to run - it feels safe but is terrible for reuse! But VIPM has a solution - I recommend checking out .vipc files. This is a file that contains multiple packages. This feature is available in the Professional version (but is well worth it), and what it allows you to do is to take a snapshot of your reuse code for a project. With the .vipc file you can then do several clever things. You can check it into SCC - along with your application source code. Now you have everything required to run your project, all under SCC - meaning you can manage project dependencies and changes that occur in reuse using SCC. You get all the security (that warm, fuzziness), with none of the managing multiple copies issues - because its not really the reuse source, its just a copy. As all the updates/bugfixing etc... is done under you internal project (a single location), then redistributed, so its all good! A fellow developer can get a working copy of the .vipc file and apply the configuration to their version of LabVIEW, now ensuring all package versions are correct in their LabVIEW palettes - super fast. So its great in a multiple developer environment. This applies in the office or on a client machine.

I thought the terminology was different - i.e. a tag being a bookmark of code (revisions), and branch being actually code? But like I said I don't use SVN (only dabled with it wrt SF). In Perforce bookmarks are called labels, branches are branches.

So tying back to Dave's question, are you saying that you prefer to jump versions of releases to clients e.g. 5.0.0 (rtm), 5.0.1 (internal test), 5.0.2 (internal test), 5.0.3 (internal test), 5.0.4 (rtm) etc.... ? I agree with what you are saying (I think), but if you need to e.g. perform regular (e.g. nightly) builds, but still release then "next version" e.g. 5.0.1 to 5.0.2, then build numbers seem logical? (I don't use SVN) But wouldn't using a label (tag) be a good idea?

Like most LabVIEWer's I started the out in the world using Traditional LabVIEW techniques and design patterns e.g. as taught in NI Courses etc... Of course, I implemented these rather poorly, and had a limited understanding at the time (hey - I was learning after-all!). After a while I discovered LVOOP, and above all, encapsulation saved my apps (I cannot overstate this enough). I then threw myself into the challenge of using LVOOP exclusively, without fail, on every project - for every implementation. This was great in terms of a short learning curve, but what I discovered was that I was creating very complex interactions for every program. (Whilst I quickly admit I am not full bottle on OOP design patterns) I found these implementations were very time consuming. I also saw colleagues put together projects much faster than I could Traditionally, and they were achieving similar results (although IMHO using LVOOP is much easier to make simple changes and test), but I wanted to weigh up the time involved and answer the question ...could I do it better? Pre-8.2 (aside from RT where we could only start using Classes in 2009), people (some very smart ones at that - who have been around for ages in the LabVIEW community) have been solving problems without LVOOP, successfully. This lead me to recently undergo a reassessment of my approach. My aim was to look at the Traditional techniques, now having a better understanding of them (and LabVIEW in general), and reintegrate them with what I was doing in LVOOP etc... - and I am having success (and more importantly fun!). Damn, I have even started to find I like globals . Anyways, at the end of the day I find using what works and not trying to make something fit is the best and the most flexible approach. With the aim of becoming a better programmer, I hope I continue this iterative approach to my learning (and of course these means I want to keep learning about LVOOP and OOP too as part of this too). JG says enjoy the best of both worlds!

I guess that is why the build number can be important. E.g Test App: 5.0.0.123; RTM App: 5.0.0.234. Your new App is of the 5.0.0 version and the build number can either be transparent to your clients or included (whatever is preferred). But your comparison logic will not fail.

Hi Oliver I ran your code in LabVIEW 2009.SP1 and can confirm the behaviour (it beeps). Interesting! - It seems either Event is fine, but if both are (statically) registered then the issue occurs. Cheers -JG

It means to give someone a hug

I would lean towards build scripts to update the version numbers of exe and installers and synch with SCC. Unfortunately (as of LabVIEW 2009 anyways) Real Time targets do not have a version field (and I think they should) in their exe's. I would only do this if the release was monolithic, i.e. you had to do a build of everything at the same time. Sometimes its not practical to e.g. update RT code just to synch the version (if the client has the target out in the field), when you only have to provide an update to a HMI etc.

Hi Fifa Is this a homework assignment?

Here you go:

Hi Martin I am sure there are more elaborate ways, but one way I have dealt with this before, and may be work here? is the following: Create a Channel Parent Class that has a property Type (Pressure, Accelerometer) and another property Data (waveform in this case) Create a Channel Manager Class which contains (and manages) an array of Channels (essentially a Map) Channel Manager has a method by which it can return an array of Channels that match a Type input i.e. return all Pressure Channels Then you can just pass this into your analysis module knowing that the Channels are only of one Type Cheers -JG

You do have a cool snippet tho, I am leaning towards yours is better