On Monday, February 14, 2011 09:08:03 pm Igor Chudov wrote: > Gene, thanks. I use only named variables. Is there some way to make them > globally scoped? > > #<width> and such are examples of named variables. > > i > > On Mon, Feb 14, 2011 at 9:03 PM, Gene Heskett <[email protected]> wrote: > > On Monday, February 14, 2011 08:26:02 pm Igor Chudov wrote: > > > Guys, I would like to know if I can define a variable in the main > > > body of code, that would be visible inside subroutines? > > > > > > How can that be done?
Good question Igor. I would expect that the #<width> in the subroutine description would still be passed in the order of the call. Going to named vars took place after I started using subroutines to simplify my code, so I never got into the habit of using them, something I intend to rectify this summer. Perhaps the answer is in the .pdf and I skipped over it? So, at this poiint I'll bow out and let the real experts answer as I only play one on tv engineering matters. ;-) > > > Thanks > > > > Its in the rs274 stuff you can dl from the wiki, but basically, > > assuming your program uses say 10 variables: > > var#11 = value > > var#12 = value > > etc etc > > > > o100 sub > > define the subroutine, using vars numbered upwards from #1. > > o100 endsub (this must be above the call to it in the code) > > > > then: > > setup the machines initial modes > > set spindle speed > > start spindle (must be on separate line) > > call o100 [#11] [#12] [#13] etc etc > > > > more code to adjust #11 (#12 etc) as required > > call o100 [same list of vars] > > park machine at end > > M2 stop everything. > > > > Now, what happens is that the order of the vars used in the o100 call, > > become var1, var2 etc etc in the subroutine. So one can write the > > call with the vars out of numerical order, but in the subroutine they > > are referenced in ascending order according to their order in the > > 'call o100' line. > > > > I hope thats clear, if not then grab and print the current version > > from the wiki, you want the rs-274.pdf package. IIRC its approaching > > 400 pages, but printing it is not a waste of paper to my way of > > thinking. I 3 hole punch them and put then in a 1.25" ring binder. > > My working copies always have a goodly amount of greasy fingerprints > > on them before they are very seriously out of date. I print them > > duplex of course. > > > > I have written some heavily looped stuff that took about 40 hours to > > run, in > > less than 60 lines of code. The efficient thing about doing it that > > way is that if you find one of your vars is off, you only have one > > place to fix it, > > not 20,000 times in 90,000 lines of code. That alone, makes it very > > worthwhile to use the subroutines. IMO of course. :) -- Cheers, Gene. From my laptop in Iron Mountain MI. Proof of my failing memory, the last time I was here in February, I said never again. But here I am, after a 900+ mile drive, 300 of it in a howling blizzard. Since I can't be trusted, I think I'll advertise for a guardian when I get home again... ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
