Jump to content

ConawayNY

Members
  • Content Count

    10
  • Joined

  • Last visited

Everything posted by ConawayNY

  1. 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.
  2. 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.
  3. 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
  4. 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
  5. 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 th
  6. 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.
  7. :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 a
  8. 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 glo
  9. 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
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.