Rod,

Am 02.04.2014 um 10:57 schrieb Rod Fitzsimmons Frey <rodf...@gmail.com>:

> Thanks Michael, I really appreciate the help.  For clarity, could you tell
> me why calling G64/G65 to set a pin results in recursion?  In the example
> code you sent on line 49 that is done:
> 
> self.execute("G64 P0.001",lineno())

the control flow is this:

- the interpreter executes a code, which might be a remapped code
- interp executes the related python code as a subroutine (technically all 
Python methods called from a remap - prolog, epilog, body - are interpreter 
methods, they happen just to be defined in Python instead of C++, which it's 
runtime extensible)
- now your code calls self.execute(string)

what happens here: Python calls back into the interpreter C++ code to parse and 
execute this line. Since <string> is basically a new block, it must save the 
current block context, do the job, restore the current block context, return. 
That's where the design restrictions kick in: recursion wasnt on the feature 
list.


> Also, while I have your attention. :)  Would this job [1] be better done in
> C++, and would that be a better target for my energy?

no, because you are going to hit the exactly same restrictions, just with more 
effort, and less portability

remapping was designed to fix exactly this very issue: folks come up with some 
ideas, patch the interpreter in C++, support issues happen. With remapping, and 
staying in the Python context, you can do all this without changing the 
interpreter binary proper - it is just impossible to integrate every 
special-purpose solution at the C++ level.


>  If so, what's a
> trailhead to get started on that path?

what about this:

- do a prototype for your toolchanger with NGC/oword along the lines of 
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=tree;f=configs/sim/axis/remap/rack-toolchange;h=7d5c0d5565eba0b3565facc36ea035d0a347d32c;hb=1848b4c60c2ba3c544baee590c4ded329440180b
- a touchoff demo is in: 
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=tree;f=configs/sim/axis/remap/manual-toolchange-with-tool-length-switch;h=07587d5cc91ed661e0face3b73aa4eadc7ef055b;hb=1848b4c60c2ba3c544baee590c4ded329440180b
- once this works, we'll look into any Python fragments needed to transliterate 
the result into pure Python 

the only thing I could think of right now are the M66 equivalents (reading and 
waiting for pins); this is described in the remapping manual in sect 9.4.5 (see 
the Python 'read_pin' fragment)

- Michael 

ps: to decode the mystery 'wtf is the interpreter doing', it's sometimes 
helpful to play with the 'standalone interpreter' program, rs274; it will tell 
you the canon calls and arguments it's generating

example (you need to fetch and build master - I just fixed a bug in the rs274 
code to display the M6x related canon calls):

mah@wheezy:~/linuxcnc-master/configs/sim/axis/remap/getting-started$ rs274 -i 
demo.ini 
enter a number:
1 = start interpreting
2 = choose parameter file ...
3 = read tool file ...
4 = turn block delete switch ON
5 = adjust error handling...
enter choice => 1
executing
demo.ini:90: executing 'import sys
sys.path.insert(0,"python")'
PythonPlugin: Python  '2.7.6 (default, Mar 22 2014, 17:44:41) 
[GCC 4.8.2]'
is_callable(remap.g886) = TRUE
is_callable(remap.involute) = TRUE
is_callable(remap.m462) = TRUE
is_callable(remap.m465) = TRUE
    1 N..... USE_LENGTH_UNITS(CANON_UNITS_MM)
    2 N..... SET_G5X_OFFSET(1, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000)
    3 N..... SET_G92_OFFSET(0.0000, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000)
    4 N..... SET_XY_ROTATION(0.0000)
    5 N..... SET_FEED_REFERENCE(CANON_XYZ)
is_callable(__init__) = FALSE
READ => m62p1
    6 N..... SET_MOTION_OUTPUT_BIT(1)
READ => m62p0
    7 N..... SET_MOTION_OUTPUT_BIT(0)
READ => M462 P1 Q0
is_callable(oword.m462) = FALSE
    8 N..... CLEAR_MOTION_OUTPUT_BIT(1)
READ => m63p0
    9 N..... CLEAR_MOTION_OUTPUT_BIT(0)
READ => m63p1
   10 N..... CLEAR_MOTION_OUTPUT_BIT(1)
READ => 



> 
> Rod
> 
> [1] implementing a rack-toolchanger with input signal lines for
> tool-released, tool-clamped, and spindle-stopped, also perhaps touch-off of
> the tool with sensors on the rack to indicate if a tool has been removed
> out-of-turn (and therefore needs touchoff)
> 
> 
> On Tue, Apr 1, 2014 at 9:12 PM, Michael Haberler <mai...@mah.priv.at> wrote:
> 
>> 
>> Am 02.04.2014 um 02:26 schrieb Rod Fitzsimmons Frey <rodf...@gmail.com>:
>> 
>>> Thanks, Michael!  I had read much of the C++ code but not that bit... I
>> got
>>> to SET_DIGITAL_OUTPUT_BIT and thought that was as good as it got.  It
>>> seemed at that point I might as well just execute("G64 P01") etc.
>> 
>> I suggest to avoid recursive interpreter invocations from remaps if you can
>> 
>> it works but, but the interpreter C++ code positively was not designed
>> with this in mind
>> 
>> meaning: pretty easy to get to border cases where strange things happen
>> (hi Norbert ;)
>> 
>> the canon route is robust - recommended
>> 
>> - Michael
>> 
>> 
>> 
>>> 
>>> 
>>> 
>>> 
>>> On Tue, Apr 1, 2014 at 6:53 PM, Michael Haberler <mai...@mah.priv.at>
>> wrote:
>>> 
>>>> here is an example for what I described below:
>>>> 
>>>> 
>>>> 
>> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commit;h=d426cc90b5e1338f1a2b8ad403ea11e0a24f3b50
>>>> 
>>>> try 'M465 P0Q1' and 'M465 P0Q0' and watch motion.digital-out-00
>>>> 
>>>> - Michael
>>>> 
>>>> Am 01.04.2014 um 22:10 schrieb Michael Haberler <mai...@mah.priv.at>:
>>>> 
>>>>> Rod,
>>>>> 
>>>>> Am 31.03.2014 um 21:22 schrieb Rod Fitzsimmons Frey <rodf...@gmail.com
>>> :
>>>>> 
>>>>>> I've looked at this and see where the bitmask, but it seems I can only
>>>> read
>>>>>> pins with the hal component, not set them?
>>>>> 
>>>>> that is correct
>>>>> 
>>>>>> How can I turn on my power drawbar valve, trigger the blow valve, etc?
>>>>> 
>>>>> you can do pretty much everything in embedded Python what the NGC
>>>> interpreter 'above' can do.
>>>>> 
>>>>> So in the context of setting pins, what you can do is the same thing
>> the
>>>> interpreter does with M62-M65 pin operations.
>>>>> 
>>>>> The way you do that is: you read up on the C++ code what the
>> interpreter
>>>> does, and do the same thing in Python
>>>>> 
>>>>> in the context of setting pins, this means reading
>>>> src/emc/rs274ng/interp_convert.cc Interp_convert_m() and what the canon
>>>> calls do which result from there, for example M62 does this:
>>>>> 
>>>>>  SET_MOTION_OUTPUT_BIT(round_to_int(block->p_number));
>>>>> 
>>>>> now for each C++ canon all like this one there is an equivalent Python
>>>> method emccanon.SET_MOTION_OUTPUT_BIT(p) with the same signature - see
>>>> src/emc/rs274ng/canonmodule.cc
>>>>> 
>>>>> 
>>>>> sorry - there is just no way to document all this - you are extending
>> an
>>>> interpreter written in C++, so you are expected to read the C++
>> internals
>>>> and understand them before you go about it
>>>>> 
>>>>> The embedded python code is primarily there as glue for remapped codes
>>>> as document - with Oword subs; that is documented and works.
>>>>> 
>>>>> If you go beyond that, you are on your own - it is possible but not
>>>> necessarily easy.
>>>>> 
>>>>> If you find a method which is useful, please contribute examples and
>>>> documentation.
>>>>> 
>>>>> - Michael
>>>>> 
>>>>> 
>>>>>> I feel like I'm missing some obvious insight... this feeling of
>>>>>> incompetence is very uncomfortable.
>>>>>> 
>>>>>> 
>>>>>> On Mon, Mar 31, 2014 at 2:12 PM, Niemand Sonst <nie...@web.de> wrote:
>>>>>> 
>>>>>>> Hallo Rod,
>>>>>>> 
>>>>>>> my name is Norbert ;-)
>>>>>>> 
>>>>>>> Have you taken a look to
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>> 
>> http://www.linuxcnc.org/docs/devel/html/remap/structure.html#_optional_interpreter_features_ini_file_configuration_a_id_sub_ini_features_a
>>>>>>> 
>>>>>>> Special section 18.
>>>>>>> 
>>>>>>> Norbert
>>>>>>> 
>>>>>>> Am 31.03.2014 19:42, schrieb Rod Fitzsimmons Frey:
>>>>>>>> Thanks, Niemand!  I'll try that. Where should I look for
>> documentation
>>>>>>> that
>>>>>>>> would tell me features available in rs274ngc?  I've looked through
>> the
>>>>>>>> source as best I can but don't know how you found that features=12
>>>>>>>> parameter.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Mon, Mar 31, 2014 at 11:50 AM, Niemand Sonst <nie...@web.de>
>>>> wrote:
>>>>>>>> 
>>>>>>>>> Rod,
>>>>>>>>> 
>>>>>>>>> it is easy to access hal pin from ngc code, if you enable features
>> in
>>>>>>>>> your INI [RS274NGC] with FEATURES = 12 (enables INI and Hal
>> reading)
>>>>>>>>> And the needed pins can be created in a python handler file. You
>>>> might
>>>>>>>>> want to check gmoccapy and gmoccapy_tool_sensor.ini for an example,
>>>>>>>>> please see also /macros(change.ngc for INI and Hal checking.
>>>>>>>>> 
>>>>>>>>> Norbert
>>>>>>>>> 
>>>>>>>>> Am 31.03.2014 17:39, schrieb Rod Fitzsimmons Frey:
>>>>>>>>>> Oh!  But it works now!  I can move the spindle where I want it, I
>>>> can
>>>>>>>>> setp
>>>>>>>>>> on the pins to release the tool, etc. M6T1 does exactly that with
>>>> this
>>>>>>>>>> code.  I just can't signal to EMC that the tool has been changed,
>>>> so on
>>>>>>>>> the
>>>>>>>>>> *next* call to M6 it reports that the current tool is -1.
>>>>>>>>>> 
>>>>>>>>>> But I readily accept that even if it is moving, I *shouldn't* do
>> it
>>>>>>> this
>>>>>>>>>> way.  I can use the ngc code if necessary, but I couldn't find a
>>>> way to
>>>>>>>>>> access the signals from my spindle... i went this way so I could
>>>> create
>>>>>>>>> the
>>>>>>>>>> pins I needed to detect if the tool was secure, etc.
>>>>>>>>>> 
>>>>>>>>>> The documentation seemed to suggest a full toolchanger could be
>> done
>>>>>>> with
>>>>>>>>>> only python, I'm just not grokking how to structure that.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Mon, Mar 31, 2014 at 11:30 AM, Michael Haberler <
>>>> mai...@mah.priv.at
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Am 31.03.2014 um 17:15 schrieb Rod Fitzsimmons Frey <
>>>>>>> rodf...@gmail.com
>>>>>>>>>> :
>>>>>>>>>>>> Thanks!
>>>>>>>>>>>> 
>>>>>>>>>>>> .ini file:   http://pastebin.com/VsnQFuzt
>>>>>>>>>>>> .hal file: http://pastebin.com/RHEJYqJB
>>>>>>>>>>>> hal file hook (hal_racktoolchange):
>> http://pastebin.com/njTUZAqS
>>>>>>>>>>>> tool change python code: http://pastebin.com/1EZy0Pur
>>>>>>>>>>> this is a normal userland HAL comp, not embedded in the
>> interpreter
>>>>>>>>>>> you write:
>>>>>>>>>>> 
>>>>>>>>>>>       * # These libraries not found - copied from stdglue.py
>>>>>>>>>>>       * import emccanon
>>>>>>>>>>>       * from interpreter import *
>>>>>>>>>>> 
>>>>>>>>>>> those are available only _within_ the interpreter, you cannot use
>>>> them
>>>>>>>>> in
>>>>>>>>>>> a normal userland HALcomp
>>>>>>>>>>> 
>>>>>>>>>>> oh I see what you are trying to do: interpreter.execute("G53 G1
>> X%i
>>>>>>> Y%i
>>>>>>>>>>> F%i" % (x_pos, y_pos, rack_params["Z_RETRACT_SPEED"]))
>>>>>>>>>>> 
>>>>>>>>>>> well this will not work (unfortunately), this is the reason:
>>>>>>>>>>> 
>>>>>>>>>>> task and motion can handle one running interpreter at a time
>> only;
>>>> you
>>>>>>>>> try
>>>>>>>>>>> to use a second one from outside - even if it were possible to do
>>>>>>> that,
>>>>>>>>> the
>>>>>>>>>>> commands it generated would be ignored because task wouldnt
>> listen
>>>> to
>>>>>>>>> them,
>>>>>>>>>>> it listens only to the interpreter built into milltask
>>>>>>>>>>> 
>>>>>>>>>>> so any sequenced move operations involving the interpreter must
>>>> come
>>>>>>>>> from
>>>>>>>>>>> the running program - that was one of the reasons why remapping
>>>>>>> enables
>>>>>>>>>>> calling on NGC subroutines to do just that
>>>>>>>>>>> 
>>>>>>>>>>> sorry, you need to remain with the setup as outlined in the
>>>>>>>>>>> manualtoolchange example; you can replace some ngc by python, but
>>>> you
>>>>>>>>> cant
>>>>>>>>>>> move that code outside the interp into another halcomp
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> - Michael
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> Console output: http://pastebin.com/jNHZbxAE
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Mon, Mar 31, 2014 at 10:59 AM, Michael Haberler <
>>>>>>> mai...@mah.priv.at
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Am 31.03.2014 um 16:03 schrieb Rod Fitzsimmons Frey <
>>>>>>>>> rodf...@gmail.com
>>>>>>>>>>>> :
>>>>>>>>>>>>>> Hey!  After a couple days away I'm back at this.  And
>>>> immediately
>>>>>>>>>>>>> stalled!
>>>>>>>>>>>>>> :)
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> stdglue.py returns INTERP_ERROR and other constants that I
>> just
>>>>>>> can't
>>>>>>>>>>>>> seem
>>>>>>>>>>>>>> to locate!  When I try to
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> import emccanon
>>>>>>>>>>>>>> from interpreter import *
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> in my own handler code linuxcnc complains that neither of
>> those
>>>>>>>>> modules
>>>>>>>>>>>>> can
>>>>>>>>>>>>>> be found.  I've gone through the source looking for the
>>>> constants
>>>>>>> but
>>>>>>>>>>> no
>>>>>>>>>>>>>> luck.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Any advice?
>>>>>>>>>>>>> yes: please upload your complete configuration, all related
>> files
>>>>>>> and
>>>>>>>>>>>>> pastebin any error messages
>>>>>>>>>>>>> 
>>>>>>>>>>>>> - Michael
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Wed, Mar 26, 2014 at 3:15 PM, Michael Haberler <
>>>>>>>>> mai...@mah.priv.at
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Am 26.03.2014 um 16:53 schrieb Rod Fitzsimmons Frey <
>>>>>>>>>>> rodf...@gmail.com
>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>> Hi!  I'm merrily trying to remap M6 using the guidelines at
>>>>>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>> 
>> http://linuxcnc.org/docs/devel/html/remap/structure.html#_configuring_iocontrol_with_a_remapped_m6
>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>> I'm trying to use all-python to implement my rack
>> toolchanger.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I have some stuff working - change_epilog in stdglue.py is
>>>>>>> called,
>>>>>>>>> my
>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>> executes and moves the spindle to the correct location for
>> the
>>>>>>> new
>>>>>>>>>>>>> tool,
>>>>>>>>>>>>>>>> etc. But change_epilog isn't called.  I put a print
>> statement
>>>> as
>>>>>>>>> the
>>>>>>>>>>>>>>> first
>>>>>>>>>>>>>>>> line in both change_prolog and change_epilog - the former is
>>>>>>>>> executed
>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>> the latter is not.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Perhaps as a result of change_epilog not getting called, my
>>>>>>> current
>>>>>>>>>>>>> tool
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>> never changed from -1.  (Although that could be something
>>>> else if
>>>>>>>>>>>>>>> there's a
>>>>>>>>>>>>>>>> step I'm missing in my toolchange code.)
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> My ini file line is
>>>>>>>>>>>>>>>> REMAP=M6 modalgroup=6 prolog=change_prolog
>>>> epilog=change_epilog
>>>>>>>>>>>>>>>> py=toolchange
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> and the epilog signature (unchanged from src) is
>>>>>>>>>>>>>>>> def change_epilog(self, **words):
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Any advice?
>>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> what you are doing is an all-python remapped code
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> now the prolog and epilog Python handlers are there to
>> extract
>>>>>>>>>>>>> parameters,
>>>>>>>>>>>>>>> and set the environment for a _ngc_ remap function
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> if you are doing all-python you can collapse all code into a
>>>>>>> single
>>>>>>>>>>>>> python
>>>>>>>>>>>>>>> remap body (all code will go into py=toolchange)
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> so just drop the prolog and epilog handlers, do it all in
>>>>>>>>> toolchange()
>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> you should be fine
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> there was a problem with three python handlers in sequence;
>> not
>>>>>>> sure
>>>>>>>>>>> if
>>>>>>>>>>>>> it
>>>>>>>>>>>>>>> is mentioned in the docs or just the code; since the separate
>>>> pre-
>>>>>>>>> and
>>>>>>>>>>>>> post
>>>>>>>>>>>>>>> handlers dont make sense anyway I avoided the issue by not
>>>> calling
>>>>>>>>>>> them
>>>>>>>>>>>>>>> let me know if you get stuck - just push your config and coce
>>>>>>>>>>> beforehand
>>>>>>>>>>>>>>> so I can have a look
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> - Michael
>>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>> Rod
>>>>>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>> 
>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>>>>>>>>>>>>>> "Graph Databases" is the definitive new guide to graph
>>>> databases
>>>>>>>>> and
>>>>>>>>>>>>>>> their
>>>>>>>>>>>>>>>> applications. Written by three acclaimed leaders in the
>> field,
>>>>>>>>>>>>>>>> this first edition is now available. Download your free book
>>>>>>> today!
>>>>>>>>>>>>>>>> http://p.sf.net/sfu/13534_NeoTech
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> Emc-users mailing list
>>>>>>>>>>>>>>>> Emc-users@lists.sourceforge.net
>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>>>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>> 
>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>>>>>>>>>>>>> "Graph Databases" is the definitive new guide to graph
>>>> databases
>>>>>>> and
>>>>>>>>>>>>> their
>>>>>>>>>>>>>>> applications. Written by three acclaimed leaders in the
>> field,
>>>>>>>>>>>>>>> this first edition is now available. Download your free book
>>>>>>> today!
>>>>>>>>>>>>>>> http://p.sf.net/sfu/13534_NeoTech
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> Emc-users mailing list
>>>>>>>>>>>>>>> Emc-users@lists.sourceforge.net
>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>>>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>> 
>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> Emc-users mailing list
>>>>>>>>>>>>>> Emc-users@lists.sourceforge.net
>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>> 
>> ------------------------------------------------------------------------------
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Emc-users mailing list
>>>>>>>>>>>>> Emc-users@lists.sourceforge.net
>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>> 
>> ------------------------------------------------------------------------------
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Emc-users mailing list
>>>>>>>>>>>> Emc-users@lists.sourceforge.net
>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>> 
>> ------------------------------------------------------------------------------
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Emc-users mailing list
>>>>>>>>>>> Emc-users@lists.sourceforge.net
>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>> 
>> ------------------------------------------------------------------------------
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Emc-users mailing list
>>>>>>>>>> Emc-users@lists.sourceforge.net
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>> 
>> ------------------------------------------------------------------------------
>>>>>>>>> _______________________________________________
>>>>>>>>> Emc-users mailing list
>>>>>>>>> Emc-users@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>> 
>> ------------------------------------------------------------------------------
>>>>>>>> _______________________________________________
>>>>>>>> Emc-users mailing list
>>>>>>>> Emc-users@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>> 
>> ------------------------------------------------------------------------------
>>>>>>> _______________________________________________
>>>>>>> Emc-users mailing list
>>>>>>> Emc-users@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>>>>>> 
>>>>>> 
>>>> 
>> ------------------------------------------------------------------------------
>>>>>> _______________________________________________
>>>>>> Emc-users mailing list
>>>>>> Emc-users@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>>>> 
>>>>> 
>>>>> 
>>>> 
>> ------------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> Emc-users mailing list
>>>>> Emc-users@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>>> 
>>>> 
>>>> 
>>>> 
>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Emc-users mailing list
>>>> Emc-users@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>>> 
>>> 
>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Emc-users mailing list
>>> Emc-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


------------------------------------------------------------------------------
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to