Neil Pate

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

I gave quite serious thought to whether I should post or not as I did not really want to derail the thread. However, that joke is perhaps in my top two of tech jokes I know, it is too good to not share. The other one is.. “Whenever faced with a problem, some people say `Lets use AWK.' Now, they have two problems.”

The best thing about UDP jokes is that I don't care if you get them or not.

I regularly use the "Explore" option from a build spec, it normally works as expected. Just yesterday LV2015 SP1 would take me to a different build spec folder when I did this. Very strange indeed.

Sorry, I will check out the community page and keep my comments there. (sometimes I get my tone wrong after being handed two babies at 6 AM)

Thread hijack! DCAF, (de-caf, right?). Looks interesting, but am a bit put off by the code smells in this screenshot...

Last year I tinkered with one of the Linux based cDAQ systems, and yes it supported a GUI. I did not try any kind of events, just wanted to show the FP of the RT code for info purposes. Some strange things happened though, some of the indicators just would not update even though they were being fed data in the same loop as others which were working. I had no real use-case for the GUI, it was more out of curiosity, so I left it there.

Sure I know about the CTRL-drag trick, I use it all the time. The problem is I use locals seldom, so most of the time there isn't another one to clone nearby on the BD.

I use locals sparingly, but in my typical use case where I really just need to use a value in more than one place (lazy yes, but not worth the effort to do it any other way) I need to read from a local rather than write to it. The default condition is to write though, so I need to change my virtually every time I need to use one. Am I the odd one out here? Don't suppose there is some SuperSpecialIniKeyForDefaultLocalVariableDirection?

Did not know about this workaround. Thanks!