Neil Pate

James, as I said I have been down that path before, exactly as you described. Now I am trying something different, "just because". :-)

I have a class based messaging system already, but the data payload is just a variant (for the exact reasons you have just mentioned). In retrospect there is not much beneft my message being a class, I just designed it that way originally in case I wanted different message types (which I have never actually used).

I used to do things like this, where the data was in a message itself. However I found maintenance of the user events became too much of a pain. Now I just have simple "data changed" events, and then the thing listening polls the data it care about from the global data store. My actors themselves are all 100% ByVal, I just use the data store as the mechanism for access the data across processes

The way the architecture is designed there will only ever be a single writer of each data item, but these scattered across multiple actors (different hardware components and software interfaces). The data in my application "runs slowly". Most new data comes in around about once per second so I do not really need to worry about extracting every last clock tick of performance out of my PC. Computers are crazy fast anyway these days, the bottleneck is certainly my skills.

I am experimenting with a DVR based variant repository for my "global" data storage needs. Each actor in my system (everything is an actor) is able to reference this DVR and thus get at *any* data. Perhaps a bit dangerous, but as I said, this is an experiment. The application I am working is based on an older project, but is different enough, and needs enough work done to it that a complete architecture overhaul is sensible. So for now I have refactored my Action Engine to be a pure ByVal class that lives in my main controller, and I am just storing the result of the processing in the DVR.

Totally agree. This behaviour is expected (only since I got burned by it), but very strange indeed.

burn! I also really dislike exposing the IPE anywhere on a top-level-ish block diagram, but it is painful to have the DVR as the input to a sub-VI... and don't get me started about the error handling gymnastics required.

You know nobody uses that... ;-)

I suppose I must think about this differently to you. Wires are ByVal, everything else is not. FGVs/AEs are close enough to ByRef for me to lump them in the ByRef category. Let me approach this from another angle: my actual goal. If I abort the entire project while a piece of code while it is running, and run that single VI (and of course whatever sub-VIs it calls etc) again, can I expect to get sensible values based purely on the current values of the input controls? This is the crux of what I am after. If I have to run many other "things" in the background just to get sensible results then, for me at least, this is undesirable. If I want to test a particular portion of my code, say the algorithm that determines my calculated deformation (referring to my OP), then in 2016 I really want to code it in such a way that I can have a nice simple test harness and an entirely ByVal implementation (almost certainly a pure ByVal class implementation). Sure, in the bigger picture it may turn into ByRef somewhere else, but I am not too bothered by this.

Yes, this is exactly what I am thinking. That is why I put the question out there to other devs :-)

The FGV (Action Engine actually) was used as the global storage of the temperatures and a mechanism for calculating the mean. The temperatures were needed all over the application (mainly for display purposes). Please try and remember this was six years ago, and was done way before I had started to seriously use an sensible messaging framework. I am not suggesting this is how I would do it now-a-days.

yeah but its twenty bucks and I won't learn anything ;-) (like how to write a recursive algorithm in LabVIEW without having a nervous breakdown)

I have a zipped file I need to get inside. For those curious I kept a diary of daily activities about 13 years ago, and now I want to read it. Luckily I have managed to get inside most of it, but the last file is proving stubborn (or rather my memory is just not what it used to be). So... I need to brute force it. I have no idea the possible key length, all I know is I used a 12 character password on my main archive (but luckily I remember that one), I suspect the most recent entries have something less. Does anybody have any nifty routines that can test a password against a file in an archive? The OpenG ZIP routines do not expose this, and inside them is just a DLL written by Rolf I think. I am not really in a rush to get this done, so it will become another "academic exercise" that I will just keep chipping away in my spare time. I am aware of the rather large set of character combinations that could be possible :-) Edit: actually it seems the OpenG ZIP library (DLL) does implement something like this, there is a function lvzip_unzOpenCurrentFilePassword. Now I just need to figure out the function call parameters. Edit2: seems I am being daft. Password protection is implemented in the OpenG toolkit, I just needed to look for it!

DVRs of an object are really handy, but I am hesitant to rely on them for core features. As I see it there are two options, design the class purely as ByVal and turn it into a DVR, then everywhere on the block diagram you have to use an IPE (which does not feel nice and is messy). The alternative is the class private data is just a DVR. This is the convention adopted by G# and the other toolkit (GDS). Of the two I prefer the second option, but it still means all data is ByRef, and this is the very thing I am trying to avoid. Certainly though if I knew about GDS or G# when I was initially using Action Engines I would probably have used those toolkits instead as the method creation wizards can certainly save a lot of time. As others have said, an Action Engine is very similar to a ByRef singleton class.

James, for me Action Engines came quite early in my LabVIEW education. Certainly more than 5 years before I came across actors, classes, DVRs etc. So now I am trying to standardise my habits, but even that is tough as new ideas come along all the time and I want to try and stay current with my best-practices/education. My gut feeling tells me that any new code I develop should probably not have any Action Engines in it as I now have other ways of dealing with the same problem. I suppose one of my big problems with Action Engines (and really any ByRef type architecture) is that it is so much harder to debug and generally grok what is going on that a purely ByVal system. Wires, (essentiallly pure ByVal operation) are to me one of LabVIEW's greatest strengths.

I did say "almost" :-) This is the VI I knocked up just to test things out.. Thanks for the info, I will digest slowly tomorrow evening.

I have done pretty much all of these kinds of things in the past, including a rather ropey check-in/check-out procedure of a class before DVRs came along. I just am trying to get a feeling from other devs what they currently consider to be their "normal".

Almost totally unrelated to LabVIEW, and is not really just a question more of just a ramble. I have dusted off a PIC microcontroller that I have had lying around in my drawer for years, and am attempting to stop old-age brain rot my making it do stuff, but purposely limiting myself to assembler. So far I have the (12-bit) ADC working, and sending the upper 8 bits back to the PC over RS-232 as an ASCII character. Now all I want to do is display the analogue voltage on the PC. Should be simple. I am using the 5V supply as the reference, so a 12-bit ADC has a step size of 1.22 mV. Conversion from 12-bit hex value to human readable value should be reasonably straightforward: scale the ADC value by 1.22 mV, convert to say 5 digit BCD and chuck out over the serial port one character at a time. I figure the first step is to implement a fixed point multiplication, keeping things simple I can have the ADC reading as <+,16,0> and the scaling factor as <+16, 3>. This is the bit that is making my brain hurt... I have done some reasearch and it turns out that fixed point multiplication does not really care about the format of the number, only the bit-width. So you can use exactly the same algorithm to scale <+16,0> and <+16,3>. Anybody know if this is correct? Now, I know I can take all sorts of shortcuts to get the ADC value in human readable format, I have decided for the purpose of the exercise I really want to figure this out using fixed point maths (I have no actual application in mind other than curiosity).

Yes I suspect if I had discovered ByRef classes before I become familiar with Action Engines I would be the same. But..I do not really make much distinction between a singleton ByRef class and an Action Engine (except perhaps that the class is easier to manage using one of the ByRef OOP toolkits). I am a bit torn on this one... I want to use ByVal as I think it makes debugging and scope easier to understand, but that means the class has to live somewhere, ok fine I have a "main controller" actor/process, so it can go there. However any time I want to interact with it I then have to create messages that the main controller can process. And then there is the issue of getting data out of it and usable by the rest of the application. I suppose for your example I would have the ForceCalibration object as a ByVal class in the process that is actually going to use it.

Action Engines, aka LV2 style functional globals with a bit of embedded logic. These are great and I have definitely leveraged them pretty hard over the last decade or so of my programming. Today I am going through some old code, porting it to a newer framework I have developed. The old code had lots of Action Engines. Most of the inter-loop (process) data sharing was done using these, and there is nothing inherently wrong with it. The old application works well. It has been a while since I heavily relied on Action Engines, but I seem to recall them being a bit difficult to debug due to their global scope and data in other Action Engines going stale when the application was stopped (or aborted). However, as I drink more of the cool-aid I am moving more and more to a ByVal type approach to code, so that is having the data on a wire when I need it, rather than tucked away somewhere else in an action engine. Concrete example: a system has multiple temperature measurements. These are used to determine approximate deformation of a structure which can then be used to correct for something else. However not all the temperatures are always used, and in fact we only care about the mean temperature. The operator can select which temperature measurements are to be used. I had previously implemented this as an Action Engine and it works perfectly, but am thinking of re-implementing it as a class that lives on a wire somewhere in my main controller (or something like that). So my question is this, for those developers that use (or used to use) Action Engines, do they still retain that special place in your heart or have they now been tucked away in a drawer?

Dang, so simples :-) Thanks Shaun.

I have created some code that is supposed to store a VIs FP.PanelBounds to disk and them restore them later so that window positions are persisted between runs of the executable. Everything works perfectly in the IDE, but in an executable I get strange behaviour. The most common thing that goes wrong is that the window is vertically shifted down by some very noticeable number of pixels, approximately equal to my Windows taskbar (by eyeball measurement). Sometimes it does work though, and it seems to be only on the first load of the executable that the position is set incorrectly. While the exe is running I can close windows and restore them in the correct place (but perhaps then my VI is still in memory or something) I have probed around and the values being persisted to disk and read back are correct, the bug seems to be in the setting of the FP.PanelBounds property. I suspected it could something in Windows (like the restoring animation) interfering with LabVIEW as the window "appears" but I have disabled this and still no difference. Am I doing something silly here? There seem to be lots of different properties for setting window bounds and stuff like this (see https://decibel.ni.com/content/docs/DOC-22385) so perhaps I am doing this a dumb way? I am pretty sure I used this technique on Win XP and LabVIEW 8.6 and it worked perfectly. At the moment using Win 10 and LV2015SP1.

The only thing I can suggest is looking at the Error message which suggests the error arises in Set Lin Log. Looking at your sweep params on the FP, are you sure you have this set up right. You have a start level of 0 A, a finish level of 10 uA, a step of 100 nA and 11 steps. One of those parameters is not correct, as your step level needs to be more like 1 uA to get from 0 --> 10 uA in only 11 steps. Perhaps this is the source of the error? As I mentioned in my previous post, I have not actually used the sweep functions on the instrument. Your time delay seems quite long so would it not be possible to just do the timing manually in a loop?

If you are struggling to get something to work go back to basics and try and create the most simple example you can think of. Can you set a single nA current at all just using the Set Current Level VI that is in the driver? I have used the 6220, and although I cannot remember if I went down to nA (I think I did) I also do configure the range before setting the current level. I see the example does this (it sets the range to 2 nA), which is strange then that you are getting it to work in the uA and mA range. I did not use any of the sweep functions, all my outputs were static so perhaps this is just a limitation of the device (but I doubt it).

But without any kind of re-transmission in the case of errors which is where this whole exercise starts to become tricksy. Caveat emptor...