Dan DeFriese

Make sure to include the NI-VISA runtime when building your installer. (Check the NI-VISA Runtime x.x box on the Addtional Installers.)

I agree. In fact I'd suggest that CLD recert should a practical exam instead of a multiple guess trivia game. I think this would be better for both NI and myself. For me because I'd always have to keep my coding habits sharp. For NI because they can review the submission to which "new" features and techniques are actually being used successfully by developers. ~Dan

Did you come up with this yourself? Before looking at the example? I only ask since this looks almost identical to the example (with some of the wire labels misplaced).

715...Yuck. Fortunately, GE Fanuc (Condor) did most of the work for you with the Interface.dll... their instrument driver handles the abstraction already (assuming you paid the $300 bucks and aren't building the VI-DLL calls from scratch). Unfortunately, the CEI-715 (PCMCIA) doesn't support many of the "Intelligent" features that the CEI-620 (cPCI) does (e.g. hardware sceduled transfers). If you have the option I recommend the RAR-EC (Express Card) version of the test card instead of the CEI-715 for your laptop. The RAR-EC would be "nearly" transparent as it supports almost all the calls that the CEI-620 does. Obviously, you still need to do some hardware abstraction, for channels assignments and such, but using the RAR-EC will have you a lot of time. HTH ~Dan

Can you be a little more specific... what doesn't work? There's a few tips: If you can't open the application reference: -make sure the port number you select is available. and that your firewall (if enabled) is not blocking it. If you can't open the vi reference: -make sure your using the correct path/name. If you can't access the control reference: -make sure your using the label name (if the control is located -if the control you're after is inside a cluster or on a tab you'll have dig through chain. I'm not aware of any specific guidance on this outside of LV help. If you post your sample app , INI, and test VI I'll step you through it. Unfortunately the example I posted is gone and I can't upload from work. (If I find it, I'll post it again this evening.) ~Dan

Try reading this thread: http://lavag.org/topic/9007-vi-server-with-built-applications/page__p__53908__hl__defriese__fromsearch__1#entry53908

Here's the example code for setting the CCSymbols programmatically. CCExample.zip

I can't upload my example. But on option is to execute the build spec(s) programmatically using a pre-processing VI. Using the Project API you can obtain the project root refnum using the Project::Root property node which feeds the Project::SetTag invoke node. For Project::SetTag invoke node inputs: TagName = "CCSymbols" Value = A semicolon separated string in the form "SYMBOL_1,VALUE;SYMBOL_2,VALUE;SYMBOL_n,VALUE" (e.g. "DEBUG,F;SIMULATE_A429,T") Hope this helps... I'll try to post an example after work. ~Dan

Thanks... Now, where is that Foot-In-Mouth icon. I guess this one will have to do . I should have paid more attention to the title of the thread. Now I see that he was in fact discussing the Rendezvous API and suggesting changes to it and NOT the Queue and Notifier primatives. Obviously, it was changes to the latter which had me concerned. Again, thanks Daklu for clarifying point of the discussion! ~Dan

Exactly... that's why #1 is not a bug. Thanks, I'm using 8.6. Our team will be moving to LV2010 when available. However, I don't want to find that I have to rework everything I did for the last 2.5 years b/c the implementation of the queue primatives have changed.

I guess I don't see how #1 and #2 could be considered bugs. The "...runs normally only if no error occurred before the VI or function runs..." is right there in the manual. P.S. Has anybody considered implementing SEQ with Preview Queue Element and Lossy Enqueue Element instead of dequeue and enqueue?

Here's my approach to #1 - Basically my rational is that if the subVI returns an error its output can't be trusted and I don't want it do anymore damage (e.g. stop the bleeding). Since I dequeue outside the error bypass I know that the queue reference is valid so just re-enqueue the existing element. Thanks for the tip in #2 Of course, now that I've re-read your post over there I realize that your describing a real bug in #3. Good luck! ~Dan

I ran into this dead-lock condition the first time a use SEQs. My approach is to use the error cluster and Select primitive to determine if I will enqueue the original state (which comes directly from the dequeue) or new state information. However, the Enqueue VIs error in terminal is left unwired to ensure that something is always in the queue in either case. ~Dan Sorry the image didn't upload from work.

Its what I do as well. For the comment* I'll generally say "Recompile Only: some reason ". Where the some reason would describe why the recompile was necessary (e.g. modified a typedef control, etc...) ~Dan * My SCC tool is configured to require comments for all check-ins/commits.

No. If the file is not locked, then nobody's local copy should be writable (changeable). That's kinda the point of the lock/unlock or checkout/checkin paradigm. (Obviously, you can circumvent this but then your're not really under version control anymore.) ~Dan

My $0.02... FGs / AEs / LCODs have proven themseleves as excellent constructs for many years (config file library comes to mind). Yes, they can be abused (I can abuse anything). Yes, they can get out of hand with quick fixes (the quick fix is to blame not the AE construct). Just because we have another tool (e.g. LVOOP) in our bag doesn't mean we need to throw out the old ones... maybe we just need to protect them better as suggested above. BTW... aren't you the one who said "...[don't] throw the baby out with the bath water" awhile back? ~Dan

I don't think that would work out well anywhere... People gettin paid (more that gas money) to sit on a jury. How could someone be impartial if their own livelihood may be on the line. I think closest thing would be the concept of the Grand Jury. They are generally seated for 12-36 months and are used to determine if there sufficiant evidence in a given case to proceed with a trial, but doesn't hear the trial itself.

You said before that you calculated this value... now you say its just a theory. I think your full of bologna. What else are you lying about... I bet your're from Steeleville, Missouri and have never set foot Romania.

And what theory is that?

I'm bored waiting for an ESS test to finish so I looked it up on Digikey. They have 50 in stock. http://search.digikey.com/scripts/DkSearch/dksus.dll?Cat=2621773&k=spartan%203e%20starter%20kit ~Dan

Actually, what you describe is perfectly reasonable to me. Your saying that your creating a "structure of pointers", but your're wanting to make this structure a constant. The problem is that pointers (or LabVIEW's rough equivalent of references) have no meaning at edit time. That is, they have to point to or reference some location in memory at runtime and that location may be different each time the program is run. Anyway, I might suggest using a typedef'd cluster control and use that to pass the references around for you GUI subVIs. Let me know if you don't understand what I mean and someone may post an example. ~Dan

To create a case for every value you can: 1) remove empty cases (you now have one case) 2) use the (size of the enum strings - 1) to determine how many new frame to add. Note: I changed the example to create a new VI instead of open an existing one since I don't know the context of your use case. hope this helps case_enum.vi

Great! I'm glad it worked... If I get motivated this weekend I might try to make a RCF plugin based on this so you could right click an enum on the block diagram and update it from the *.rtm file directly.

Hmm... The separator line throws off the parser in 8.6 as well. I don't remember ever using a separator line. Oops... After messing around the "APP_SEPARATOR" tag was being cut off to "APP_SEPARA". It looks like the Read From Text File primative had the 'Convert EOL' option enabled which changed the string length from 0Dh (13) to 0Ah (10). Try it again. rtm to enum 81.5.zip