ConawayNY

I've been using LVSpeak version 1 for some while now. I like it and have added a function or two. I have not (yet) upgraded to LV 2009. So I wonder if you could prepare a retro version that works in LV8.6 for us taildraggers. Thanks.

Paul Conaway Lockheed Martin Special Test Equipment Radar Systems Syracuse NY 18 years or more experience with LabView. (I first saw it in Black and White) I really should go for CLA as well as similar for TestStand but the company doesn't want to pay for it. Nor for a trip to NI Week. Ex Kodak where I got a patent for an image processing algorithm done in IMAQ.

Franz, I opened your examples, converted them to Version 7.1 and ran them. Main1 and Main2 exhibit the behaviors I would expect. Main3 does not seem to act any better. For the time while Main 3 is executing, Resident USR is in memory and functioning. USR Hook however does not seem to have been called. It does not show up on the Profile VI table as being in memory at any rate. I only see Main3.vi and Resident USR.vi. Hence as soon as Main3 stops execution, Resident USR.vi goes away. Well, now I take that back. I put a breakpoint inside the part that launches USR Hook. That hit as expected. I took the breakpoint out and tried it all again from a clean launch of LV. Now it works as advertised. Both Resident USR.vi and USR Hook.vi are loaded and appear in the VI Profile list. They stay around even if I stop Main3 or abort Main3 or even close Main3. This is the action I was looking for. (I wonder why it didn't work on my first try?) Thanks Paul

Sparc, Yes, I played around with several architectures before I came to the realization that VI server puts its stuff in a different place than the regular load and run VIs. The "action engine" design pattern served a useful purpose for the problem for which it was made to solve. When I took it and tried to extend it to Dynamic loading, that is where it all fell apart. Like you say it can't be done. But all this mental exercise is fun none the less. I know I could do something like it using Forth, but my boss would just choke if I suggested we put in a Commodore 64 or a CoCo into a new test fixture. Thanks for the conversations, Paul

Sparc, Well I'll be durned! It does work just as you suggest. But I see that the TSR part never does the T. It keeps running continuously. As soon as it quits executing, it is unloaded from the allocation heap and every shift register it contained is silently flushed down the bit bucket. Furthermore the response time of your TSR is of course linked to the loop cycle time. To be a good well behaved action engine, or a LV2 style functional global, I think it might be nice to just let it stay resident (the SR) in memory and only execute it when needed. [the original problem] Another clue is that queues (or notifiers etc.) have no life outside of some executing vi. One cannot put something into a queue then stop execution, and expect that something to be there later on. Some VI containing the queue must be executing continuously to keep it alive. The queue does not need to be accessed, just present in an executing VI. There is one obvious way to get around all this, and it may have some usefulness. That is to go ahead and build the action engine, but don't use a "run once" while loop with uninitialized shift registers. Simply use normal (LV6) style globals for any data retention across time. Then the VI can be dynamically called when needed, and unloaded when finished. The only requirement for this is that the global VI, the VI defining all the global variables, must be statically loaded. For example one of the global variables must be accessed in a top level VI. The memory cost for keeping a handful of variables around is only a small fraction of what would be needed for the dynamically loaded VI. And neither the caller nor the called VI need to stay running. Paul

Ravi, Look under Analyze >> Mathematics >> Formula >> MATLAB script It works like a formula node but sends it to MATLAB which must be installed on the same machine.

:headbang: dear mesmith. I tried making a reference to the called vi from within the called vi. LV complains about doing recursive calls. I don't think making the VI reentrant will work as a LV2 style global. I tried passing in the reference from the calling vi and stashing that in an unitialized shift register, but that doesn't work either. :headbang: dear cb, I tried that too but when the calling VI stops its execution (stops running), the called VI is dynamically, immediately and most decidedly unloaded. The uninitialized shift registers in it instantly forget that they ever had anything in them. Any other suggestions? Anybody want me to post a simple example of what doesn't work? ConawayNY

I have a VI which is an "action engine", i.e., it contains LV2 style global variables in uninitialized shift registers. The VI works fine unless I decide to load it dynamically using the VI server. Unfortunately it also dynamically unloads the VI when it finishes. Thus its memory is destroyed. Is there any way to load a vi with the VI server and keep it in memory when it is done? To make LV treat it as if it had been placed on a diagram as a regular sub-vi (called or not)? I do notice that the VI server will call execute and return from my vi with everything working fine and retaining the global memory, if I also have the vi loaded statically as a sub vi somewhere.

I was looking for CRC stuff myself recently. Go to NI, developer section and do a search for CRC. I found between 5 and 8 algorithms / implementations (some may be repeats) as well as a RTF file that explains the whole bit shifting process and (possibly) how it is simplified in SW using a byte wide lookup table. search read enjoy