Neil Pate

Really? I did not know this, always suspected there was something special about variants. Now I am even more glad I use variants as my message data

Getting there slowly.. :-) I have the 16-bit x 16-bit multiplication working using the 8-bit hardware multiplier. Also I have fleshed out my LabVIEW demo to show how to solve the rest of my problem. Convert (+,16,4) Fixed Point Number To String.vi Convert First Decimal Place Of (+,16,4) Fixed Point Number To String.vi Fixed Point Maths.vi

Guys you are killing my thread :-) An Action Engine is not a process (actor, whatever we want to call it). Nobody actually said it was either! I just wanted to know if people still have a use for Action Engines (enough so to actually make one) these days.

Can you interact with Word (using ActiveX) and save as a text file? Then you can read the text file as pure bytes and interpret as UTF-8. I have done something similar whereby I allow a GUI to be translated "on-the-fly" into different languages, stored as UTF-8 text files.

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.