Neil Pate

I have a variant, for some reason it does not seem to have it's type information inside, the variant thinks it contains a variant (which I don't believe it does). I cannot do anything about this, this is how it is being handed to me. Does anybody know how I can retrieve the original data type? (do not really need to know specifics of SGL or DBL etc, just want to know it is an array). In the example attached I know this particular variant is an SGL array, so the Variant-->Data works fine as I have manually put in the type. However I am expecting various different array types. Variant Trouble.vi

Just for anybody interested. Courtesy of our friends at GPower (4th link on google, impressive!) http://www.gpower.as/downloads/bsd-license-explained

I would be pretty hesitant at trying to run mathscript nodes at anywhere near this rate. Not that I have tried to do it, just gut feeling tells me it would end badly. Marc, that thread you linked to regarding cRIO performance is very interesting, pity there was no real answer from NI other than buy the new controller :-( TimA I like your avatar :-)

Ditto to what the others have said. I have not yet tried building my application but just dropping the XControl down on the FP works almost as expected. One minor thing which I have not investigated the reason for yet is that you cannot resize the tree column widths. I am probably going to modify it a bit as I want to actually use it as a GUI component and I don't want it displaying the text "Attributes" and a few other things.

Thanks, I am now experimenting with using a variant to store quite all of my global system data, and this tree is a really neat way to show everything (for debug/dev purposes). I would have had exactly the same bug, so I have updated my package with your fix.

I thought it might be (I do have it installed), but it behaves much nicer than any XControl I have come across (no usual edit time strangeness I am used to with XControls), and is that not a Probe? OK, done some digging, seems like it definitely this. Thanks James (and Ton and Brian)

OK, so this seems to be native behaviour of variants with attributes, but how did you create the Variant Tree control?

What magic is this that allows a variant to be displayed as a tree? Or am I just being really dense after a long week?

I also used LabSQL when I did not have access to the NI toolkit, this was many years ago.

You mean the same System Configuration API where changing the time could cause a hard-crash of the cRIO. Yes lovely stuff that.

No, I am asking for the first scenario. Good to know it can be done. I have never really found the necessity to create polymorphic VIs, individual wrapped API VIs was sufficient for me in the past.

If you have something going wrong with your code, and you know it is one of the particular methods of the AE then (that have wrapped been wrapped so as to not expose the enum and all controls), you can easily just search for that particular VI in your code. I was under the impression you could not do this with a polymorphic VI?

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.