Neil Pate

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.

5 hours ago, smithd said:

Oh...no. I mean NI System Configuration API, for managing software etc. on RT targets and in theory doing other stuff with hardware but people who really use it for this totally get 100 pts extra credit. Very creative name obviously, and the shortened form is nisyscfg: http://zone.ni.com/reference/en-XX/help/373107E-01/nisyscfg/software_subpalette/

Basically everything is synchronous and everything totally ignores its timeout. To quote the help:

connect timeout in ms specifies the time in milliseconds that the VI waits before the operation times out. The default is 4000 ms (4 s). In some cases, this operation may take longer to complete.

*by 'some cases' they mean 'pretty much all cases' and by 'longer' they mean 'go fetch a snack'.

 

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

23 minutes ago, hooovahh said:

You can still perform a Find All Instances of a particular VI, which is probably more useful because you will only find the VI for a particular method call of a FGV, instead of finding every instance.  I believe what you are asking is if you can search for the polymorphic VI, to which I believe the answer is no, you can only search for members of the polymorphic VI, which in this case would be a particular method.

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.

33 minutes ago, hooovahh said:

Yeah I like this idea and made a (half complete) tool for generating these polymorphic VIs from FGV, posted over here.

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?

3 hours ago, drjdpowell said:

Variants don’t “flatten”.  Putting something in a variant doesn’t involve altering or copying the data.  They have overhead but I don’t think the size of the data matters.

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". :-)

Just now, ShaunR said:

Then I would suggest staying away from any of the class based messaging systems that have proliferated. You have to create a class (and all the overrides etc) for every damned message which is comical. This is why I use simple strings for messaging.

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).

5 minutes ago, drjdpowell said:

Single writer is good.  Why “global” then?   I generally have data flowing around by messages and locally stored by anyone who needs to store it.

The other issue is constantly polling a DVR for changes, versus receiving notification messages only when things change, but for “slow” apps that doesn’t matter much (but it affects your ability to reuse your solution in “fast” apps).  

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.

49 minutes ago, smithd said:

syntax seems to have been designed by someone who really doesn't want people to use DVRs

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.

1 minute ago, ShaunR said:

However. This is where I usually bring up the Suspend When Called 

You know nobody uses that... ;-)

1 hour ago, ShaunR said:

I think the main point Smithd was making is that the current thinking about replacing AEs is to use DVRs but with messaging architectures, global storage is handled differently requiring neither. You have, however, restricted your options by insisting that you  don't want to use by-ref solutions (although I think you and a few others , maybe misunderstand what that exactly is since AEs are not by-ref) 

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.

1 minute ago, smithd said:

I wasn't criticizing, just saying that with what I know now, today, I find it hard to even think about how you would use an FGV for this type of application. My thought process immediately goes a different direction.

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

5 hours ago, smithd said:

In that first example I'm honestly not sure what you'd use an fgv for, it seems like a much better fit for messages. HW loop broadcasts temp. Calculation loop subscribes to temp and broadcasts deformation. UI subscribes to both and broadcasts control parameters. I know your description is high level but based on your description I'd immediately jump to that implementation. Could use classes too but I'd keep that inside each process (variable calculation methods, or hardware abstraction).

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.