Re: [Emc-users] Remapping M6 - change_epilog not called.
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()) 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? If so, what's a trailhead to get started on that path? 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
Re: [Emc-users] Remapping M6 - change_epilog not called.
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., 0., 0., 0., 0., 0.) 3 N. SET_G92_OFFSET(0., 0., 0., 0., 0., 0.) 4 N. SET_XY_ROTATION(0.) 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
Re: [Emc-users] Remapping M6 - change_epilog not called.
Michael, the control flow is this: 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. Ok, your explanation makes it much more clear what's happening. 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. That makes good sense, and fits with my initial intuition. I'll follow your suggestion to get the oword solution working. To test my understanding: is it legitimate for the python mapping code to call canon methods directly? Would that mess up state for the interpreter when it continued executing? Rod -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Remapping M6 - change_epilog not called.
Rod, Am 02.04.2014 um 12:41 schrieb Rod Fitzsimmons Frey rodf...@gmail.com: To test my understanding: is it legitimate for the python mapping code to call canon methods directly? yes, definitely - it's just what the interpreter itself does all the time the basic logic of the interpreter inner loop is: - parse and validate a block - execute a block - which usually generates canon calls; sometimes interpreter state is needed to determine parameters for those calls but basically all of the interpreter state is exposed in Python as well again this isnt terribly well documented, but basically all the interpreter state is visible to Python - access: fine; modify from Python: make sure you understand the implications by reading the interpreter C++ code the rather large setup_struct which is the primare 'state blob' here : http://goo.gl/OaOwcH has equivalent Python attributes exposed here: http://goo.gl/glRtyM or for instance, the internal representation of a block after parsing: http://goo.gl/d1q8nq is Python-exposed here: http://goo.gl/rDnYGS also, have a look at this testcase how interpreter state is accessed from Python: http://goo.gl/XtqKmB Would that mess up state for the interpreter when it continued executing? I dont quite understand 'when it continued executing?', can you give an example? - Michael Rod -- ___ 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
Re: [Emc-users] Remapping M6 - change_epilog not called.
Am 02.04.2014 um 12:41 schrieb Rod Fitzsimmons Frey rodf...@gmail.com: To test my understanding: is it legitimate for the python mapping code to call canon methods directly? Would that mess up state for the interpreter when it continued executing? to be more clear: canon is primarily a 'downwards' API - sending instructions from the interpreter to task and eventually motion, so safe to use from an interpreter state perspective the exceptions to this rule are those GET_* canon calls which retrieve machine state to synchronize the interpreter; for instance, after a probe, interp needs to query the machine (or indirectly motion really) where the probe stopped; otherwise it wouldnt know where the tooltip currently is. But AFAICT all of these calls are referenced in the interpreter init() and sync() methods: Interp::synch(): http://goo.gl/0kwDTf (eg line 1894 onwards) Interp::init(): http://goo.gl/tyPljj meaning: as long as you dont do anything which might break position prediction (probe, toolchange, read pin), you are good to use any number of canon calls in sequence - this chapter http://goo.gl/6AC8CF may help to understand what is going on if you use one of those 'queuebuster' operations, a synch() with the machine state is needed - that is exactly what happens in the read_pin example I gave, by using the 'yield INTERP_EXECUTE_FINISH' statement in terms of canon documentation, http://goo.gl/6gcbpY is the best overview sorry if this sounds pretty complex - it is, but let me put it this way: the control flow of task and interpreter is 'intricate', to put it politely; some might choose to call it 'botched beyond repair - rewrite from ground up required'; with remapping I tried to avoid that huge rewrite and the cost is complexity in dealing with it - Michael -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Remapping M6 - change_epilog not called.
Thanks, your explanations really help. I actually think there's a astonishing lack of entropy in the code, given its age and the inherent complexity of the problem. It's all coming together for me with your explanations. On Wed, Apr 2, 2014 at 7:29 AM, Michael Haberler mai...@mah.priv.at wrote: Am 02.04.2014 um 12:41 schrieb Rod Fitzsimmons Frey rodf...@gmail.com: To test my understanding: is it legitimate for the python mapping code to call canon methods directly? Would that mess up state for the interpreter when it continued executing? to be more clear: canon is primarily a 'downwards' API - sending instructions from the interpreter to task and eventually motion, so safe to use from an interpreter state perspective the exceptions to this rule are those GET_* canon calls which retrieve machine state to synchronize the interpreter; for instance, after a probe, interp needs to query the machine (or indirectly motion really) where the probe stopped; otherwise it wouldnt know where the tooltip currently is. But AFAICT all of these calls are referenced in the interpreter init() and sync() methods: Interp::synch(): http://goo.gl/0kwDTf (eg line 1894 onwards) Interp::init(): http://goo.gl/tyPljj meaning: as long as you dont do anything which might break position prediction (probe, toolchange, read pin), you are good to use any number of canon calls in sequence - this chapter http://goo.gl/6AC8CF may help to understand what is going on if you use one of those 'queuebuster' operations, a synch() with the machine state is needed - that is exactly what happens in the read_pin example I gave, by using the 'yield INTERP_EXECUTE_FINISH' statement in terms of canon documentation, http://goo.gl/6gcbpY is the best overview sorry if this sounds pretty complex - it is, but let me put it this way: the control flow of task and interpreter is 'intricate', to put it politely; some might choose to call it 'botched beyond repair - rewrite from ground up required'; with remapping I tried to avoid that huge rewrite and the cost is complexity in dealing with it - Michael -- ___ 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
Re: [Emc-users] Remapping M6 - change_epilog not called.
Am 02.04.2014 um 16:23 schrieb Rod Fitzsimmons Frey rodf...@gmail.com: Thanks, your explanations really help. I actually think there's a astonishing lack of entropy in the code, given its age and the inherent complexity of the problem. It's all coming together for me with your explanations. would you mind taking notes along your safari, and make that a document fragment which can be included in http://www.linuxcnc.org/docs/devel/html/remap/structure.html like as a case study? I think that would help lots of other folks downstream - I might just have tunnel vision, like 'all obvious to me' so I'm not a good author for that type of document 'lack of entropy - I like it ;) - Michael On Wed, Apr 2, 2014 at 7:29 AM, Michael Haberler mai...@mah.priv.at wrote: Am 02.04.2014 um 12:41 schrieb Rod Fitzsimmons Frey rodf...@gmail.com: To test my understanding: is it legitimate for the python mapping code to call canon methods directly? Would that mess up state for the interpreter when it continued executing? to be more clear: canon is primarily a 'downwards' API - sending instructions from the interpreter to task and eventually motion, so safe to use from an interpreter state perspective the exceptions to this rule are those GET_* canon calls which retrieve machine state to synchronize the interpreter; for instance, after a probe, interp needs to query the machine (or indirectly motion really) where the probe stopped; otherwise it wouldnt know where the tooltip currently is. But AFAICT all of these calls are referenced in the interpreter init() and sync() methods: Interp::synch(): http://goo.gl/0kwDTf (eg line 1894 onwards) Interp::init(): http://goo.gl/tyPljj meaning: as long as you dont do anything which might break position prediction (probe, toolchange, read pin), you are good to use any number of canon calls in sequence - this chapter http://goo.gl/6AC8CF may help to understand what is going on if you use one of those 'queuebuster' operations, a synch() with the machine state is needed - that is exactly what happens in the read_pin example I gave, by using the 'yield INTERP_EXECUTE_FINISH' statement in terms of canon documentation, http://goo.gl/6gcbpY is the best overview sorry if this sounds pretty complex - it is, but let me put it this way: the control flow of task and interpreter is 'intricate', to put it politely; some might choose to call it 'botched beyond repair - rewrite from ground up required'; with remapping I tried to avoid that huge rewrite and the cost is complexity in dealing with it - Michael -- ___ 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
Re: [Emc-users] Remapping M6 - change_epilog not called.
Wow, this is frustrating. :) I can create HAL pins just fine, and wire them up with signals just-so. I can watch them turn on and off at appropriate times with halscope, etc. BUT I can't access them anywhere from code! The remap code for M6 has the hal python component, but: 1. If I try to create the hal component (mine is called hal_racktoolchange) it fails, since the constructor hal.component(name) CREATES the component. The call fails in the remap because the component already exists 2. I can't simply ACCESS the component - only create it. 3. I can't access any pins without having a component - I've been through all the python and C++ code trying to find a way, but nadda. 4. I've tried bridging creation and access by using an intermediate python class that creates the pins and stores them as a global. But when I access that class from the remapping code, it's entirely uninitialized - must be in a completely separate python interpreter. Without having a Hal component class instance, I'm basically hamstrung, and there is no way I can find to get an already-existing component. I really have to give up and fall back on the O codes. But I'm left really not understanding why there is any Python interpreter available at all - you don't seem to be able to do anything with it, nothing that isn't trivial anyhow. Although I remain convinced there's a way - after all, the code that interprets the O code subroutines can do it with the #_hal[HalItem] syntax. I haven't been able to find the code that interprets those subroutines though. On Mon, Mar 31, 2014 at 5:40 PM, andy pugh bodge...@gmail.com wrote: On 31 March 2014 22:13, Rod Fitzsimmons Frey rodf...@gmail.com wrote: Everything's working great, I'm just getting hung up on communicating with them from the python remap code. Looks like the suggestion of mapping to M64 commands is the way to go, although it seems a bit unsatisfying. I was really trying to do things in the most general way and the python remapping seems like a wonderful avenue. You can import hal into your Python and create HAL pins from your code to connect to other HAL pins. It might even be possible to set hal pins from Python without exporting pins, I can see a set_p function in help(hal) However, I think that exporting pins to HAL is the right way, rather than hard-coding links in the software. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- ___ 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
Re: [Emc-users] Remapping M6 - change_epilog not called.
Rod, Again, I had the same experiance with trying to use Python for tool changer and went back to O code. I know have a complete tool change program for a carousel style tool changer that raises the Z axis. Still in simulator, will be testing on real machine soon, but, it keeps track of everything, and uses the safety interlocks and prox switches etc.. What type of tool changer are you doing? Thanks, Billy On 04/01/2014 11:18 AM, Rod Fitzsimmons Frey wrote: Wow, this is frustrating. :) I can create HAL pins just fine, and wire them up with signals just-so. I can watch them turn on and off at appropriate times with halscope, etc. BUT I can't access them anywhere from code! The remap code for M6 has the hal python component, but: 1. If I try to create the hal component (mine is called hal_racktoolchange) it fails, since the constructor hal.component(name) CREATES the component. The call fails in the remap because the component already exists 2. I can't simply ACCESS the component - only create it. 3. I can't access any pins without having a component - I've been through all the python and C++ code trying to find a way, but nadda. 4. I've tried bridging creation and access by using an intermediate python class that creates the pins and stores them as a global. But when I access that class from the remapping code, it's entirely uninitialized - must be in a completely separate python interpreter. Without having a Hal component class instance, I'm basically hamstrung, and there is no way I can find to get an already-existing component. I really have to give up and fall back on the O codes. But I'm left really not understanding why there is any Python interpreter available at all - you don't seem to be able to do anything with it, nothing that isn't trivial anyhow. Although I remain convinced there's a way - after all, the code that interprets the O code subroutines can do it with the #_hal[HalItem] syntax. I haven't been able to find the code that interprets those subroutines though. On Mon, Mar 31, 2014 at 5:40 PM, andy pugh bodge...@gmail.com wrote: On 31 March 2014 22:13, Rod Fitzsimmons Frey rodf...@gmail.com wrote: Everything's working great, I'm just getting hung up on communicating with them from the python remap code. Looks like the suggestion of mapping to M64 commands is the way to go, although it seems a bit unsatisfying. I was really trying to do things in the most general way and the python remapping seems like a wonderful avenue. You can import hal into your Python and create HAL pins from your code to connect to other HAL pins. It might even be possible to set hal pins from Python without exporting pins, I can see a set_p function in help(hal) However, I think that exporting pins to HAL is the right way, rather than hard-coding links in the software. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- ___ 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 -- Billy Huddleston Inner Vision *William Huddleston Inner Vision Development Corp* Office: 865.560.2752 Fax: 865.560.2703 http://www.ivdc.com *Development and Consulting... Simplified.* http://www.facebook.com/pages/Inner-Vision-Development/120023721424 http://twitter.com/ivdc http://www.linkedin.com/in/ivdccorp -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Remapping M6 - change_epilog not called.
On 1 April 2014 16:18, Rod Fitzsimmons Frey rodf...@gmail.com wrote: Wow, this is frustrating. :) I can create HAL pins just fine, and wire them up with signals just-so. I can watch them turn on and off at appropriate times with halscope, etc. BUT I can't access them anywhere from code! The remap code for M6 has the hal python component, but: I am starting to worry that I have sent you down the wrong path. I think I was thinking in terms of a userspace HAL component rather than a remapped tool change. And I don't know how much commonality there is. A HAL component is loaded at startup, creates HAL pins and remains live for the duration of the run. I suspect that remap code runs then exits. Looking at the docs, perhaps the approach in section 9.4.5 is what you need? http://linuxcnc.org/docs/devel/html/remap/structure.html#_calling_conventions_ngc_to_python -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Remapping M6 - change_epilog not called.
Billy: Thanks, I think I'm giving up too, and moving to the O-word subroutine call. I'll probably be asking for help soon. :) Andy: Don't worry, I don't think there were any false paths. I needed a userspace HAL component regardless to integrate the signal lines from my spindle. The python component remap code (using the py=mycode approach that you linked to) is what I've been struggling with - that code needs to access the signals, for example so the code can wait until the tool-released signal goes high. That's what I can't figure out - it can't communicate with my userspace component that's defining the pins and signals. The documentation suggests otherwise: it says the python code in the remap component has full raw access to almost everything that C++ code has. It also says things like if you can't stand NGC or it gets in your way, do everything in Python (paraphrased). But, I have to move forward, so O-word subroutine it is. :) On Tue, Apr 1, 2014 at 12:02 PM, andy pugh bodge...@gmail.com wrote: On 1 April 2014 16:18, Rod Fitzsimmons Frey rodf...@gmail.com wrote: Wow, this is frustrating. :) I can create HAL pins just fine, and wire them up with signals just-so. I can watch them turn on and off at appropriate times with halscope, etc. BUT I can't access them anywhere from code! The remap code for M6 has the hal python component, but: I am starting to worry that I have sent you down the wrong path. I think I was thinking in terms of a userspace HAL component rather than a remapped tool change. And I don't know how much commonality there is. A HAL component is loaded at startup, creates HAL pins and remains live for the duration of the run. I suspect that remap code runs then exits. Looking at the docs, perhaps the approach in section 9.4.5 is what you need? http://linuxcnc.org/docs/devel/html/remap/structure.html#_calling_conventions_ngc_to_python -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- ___ 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
Re: [Emc-users] Remapping M6 - change_epilog not called.
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
Re: [Emc-users] Remapping M6 - change_epilog not called.
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
Re: [Emc-users] Remapping M6 - change_epilog not called.
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. 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
Re: [Emc-users] Remapping M6 - change_epilog not called.
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
Re: [Emc-users] Remapping M6 - change_epilog not called.
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? On Wed, Mar 26, 2014 at 3:15 PM, Michael Haberler mai...@mah.priv.atwrote: 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
Re: [Emc-users] Remapping M6 - change_epilog not called.
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.atwrote: 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
Re: [Emc-users] Remapping M6 - change_epilog not called.
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 Console output: http://pastebin.com/jNHZbxAE On Mon, Mar 31, 2014 at 10:59 AM, Michael Haberler mai...@mah.priv.atwrote: 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
Re: [Emc-users] Remapping M6 - change_epilog not called.
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.atwrote: 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
Re: [Emc-users] Remapping M6 - change_epilog not called.
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.atwrote: 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
Re: [Emc-users] Remapping M6 - change_epilog not called.
Wait! There's probably confusion because of my crappy naming. interpreter.execute doesn't rely on from interpreter import * interpreter is just the argument passed to toolchange. I thought it was an instance of an emc interpreter so that's what I called it. On Mon, Mar 31, 2014 at 11:39 AM, Rod Fitzsimmons Frey rodf...@gmail.comwrote: 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.atwrote: 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
Re: [Emc-users] Remapping M6 - change_epilog not called.
I gave up trying to do remap via python and switched to O word. I have a complete simulate umbrella style tool changer working now. I would have rather done it in python, but, got it done with O word no problem. Thanks, Billy On 03/31/2014 11:41 AM, Rod Fitzsimmons Frey wrote: Wait! There's probably confusion because of my crappy naming. interpreter.execute doesn't rely on from interpreter import * interpreter is just the argument passed to toolchange. I thought it was an instance of an emc interpreter so that's what I called it. On Mon, Mar 31, 2014 at 11:39 AM, Rod Fitzsimmons Frey rodf...@gmail.comwrote: 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.atwrote: 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
Re: [Emc-users] Remapping M6 - change_epilog not called.
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.atwrote: 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
Re: [Emc-users] Remapping M6 - change_epilog not called.
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
Re: [Emc-users] Remapping M6 - change_epilog not called.
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
Re: [Emc-users] Remapping M6 - change_epilog not called.
Thank you, sorry about mistaking your name. :) Fooled by the From field in the email envelope. 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
Re: [Emc-users] Remapping M6 - change_epilog not called.
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? How can I turn on my power drawbar valve, trigger the blow valve, etc? 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
Re: [Emc-users] Remapping M6 - change_epilog not called.
Rod, that is easy, just use Gcode ;-) See : http://linuxcnc.org/docs/html/gcode/m-code.html#sec:M62-M65 Norbert Am 31.03.2014 21:22, schrieb Rod Fitzsimmons Frey: 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? How can I turn on my power drawbar valve, trigger the blow valve, etc? 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
Re: [Emc-users] Remapping M6 - change_epilog not called.
On Monday 31 March 2014 15:40:56 Rod Fitzsimmons Frey did opine: 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? How can I turn on my power drawbar valve, trigger the blow valve, etc? I feel like I'm missing some obvious insight... this feeling of incompetence is very uncomfortable. [huge snip] You will likely need to hand (gedit) edit your *.hal file to add some logic modules with a loadrt, assign them to an execution loop base-thread or servo-thread via the addf command (and this stuff would all be good in the relatively slow servo-thread), doing that in the order you want them to be executed, then locate spare output pins in your I/O breakout scheme, and then tie it all together with net commands. You might even need a 2nd parport for additional I/O, and despite its near vertical learning curve, I think the dual port FPGA on a card, Mesa 5i25 Anything I/O would be the cats meow for all that. For breakout boards, mesa makes quite a few, none of which I have tried yet, having started out with CNC4PC C1G's here, (but thats my fault) which have very heavy duty drivers (24 ma source or sink) and a tally led on every line. So the first thing I would do is make a list of what parport pins are currently in use by grep parport my.hal and put that down on paper so you know whats now in use. That will give you a quick overview of whether or not you'll need an additional port card like the 5i25. For a reference to the I/O available on a normal computer parport, see this link and scroll down to the left hand graphic: http://www.linuxcnc.org/docs/2.5/html/hal/parallel_port.html Anything not in use now, can be added to your .hal file and used. Just be sure and add its use to the list you just made of what is used too, else you might try reuse it again a year hence. I can predict that linuxcnc will refuse to start, quoting the logic clashes in the failure report on screen. :) You then need to physically wire that parport pin to the stuff that will do your job, probably by booster relays to get enough power to bang the solenoid valves that will actually do the work. I would also incorporate a final tally signal, needing an input pin, to determine if the drawbar has responded, and do any error handling in case it doesn't reclose properly because of swarf in the works or whatever. One could also tally the air pressure from a pressure switch as being sufficient to run the drawbar. You could sit and wait till it comes up, then do the tool change while the operator is refilling his coffee cup. You could even put a small air pressure button driven by that signal in the right panel of axis that turns red when the pressure is too low. IOW, let you imagination out to play, but observe and keep notes. :) In the back of those ring binders I mention below is a good place so you know where they are. At hookup time in the hal file: net name_of_signal source_of_signal where_to_send [where_to_send] [etc] and one can expend the output tree later in the hal file like this: net name_of_signal where_to_send [where_to_send] [etc] which will send the previously named source_of_signal to several more places. At this stage, I would also recommend the integrators manual and the users manual be converted to double sided dead tree format mounted in 3 ring binders, there is tons of useful info in them. At my age poor short term memory, I still do that about every 2 years to keep up with the detail changes. Trying to clear away some of the fog, I hope this helps. Cheers, Gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Remapping M6 - change_epilog not called.
Gene, I really appreciate the brain dump, and will go through it in detail. That said, I do have the 5i25 hooked to a 7i76. I moved from pncconf to vim about a week ago. I have all the pins mapped in my hal file and can turn things on and off on my machine (and see the spindle status pins) with halstatus. Everything's working great, I'm just getting hung up on communicating with them from the python remap code. Looks like the suggestion of mapping to M64 commands is the way to go, although it seems a bit unsatisfying. I was really trying to do things in the most general way and the python remapping seems like a wonderful avenue. I actually had the M64/65 commands going and operating from Axis but thought that was the wrong way to do it in a python remap file. On Mon, Mar 31, 2014 at 4:48 PM, Gene Heskett ghesk...@wdtv.com wrote: On Monday 31 March 2014 15:40:56 Rod Fitzsimmons Frey did opine: 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? How can I turn on my power drawbar valve, trigger the blow valve, etc? I feel like I'm missing some obvious insight... this feeling of incompetence is very uncomfortable. [huge snip] You will likely need to hand (gedit) edit your *.hal file to add some logic modules with a loadrt, assign them to an execution loop base-thread or servo-thread via the addf command (and this stuff would all be good in the relatively slow servo-thread), doing that in the order you want them to be executed, then locate spare output pins in your I/O breakout scheme, and then tie it all together with net commands. You might even need a 2nd parport for additional I/O, and despite its near vertical learning curve, I think the dual port FPGA on a card, Mesa 5i25 Anything I/O would be the cats meow for all that. For breakout boards, mesa makes quite a few, none of which I have tried yet, having started out with CNC4PC C1G's here, (but thats my fault) which have very heavy duty drivers (24 ma source or sink) and a tally led on every line. So the first thing I would do is make a list of what parport pins are currently in use by grep parport my.hal and put that down on paper so you know whats now in use. That will give you a quick overview of whether or not you'll need an additional port card like the 5i25. For a reference to the I/O available on a normal computer parport, see this link and scroll down to the left hand graphic: http://www.linuxcnc.org/docs/2.5/html/hal/parallel_port.html Anything not in use now, can be added to your .hal file and used. Just be sure and add its use to the list you just made of what is used too, else you might try reuse it again a year hence. I can predict that linuxcnc will refuse to start, quoting the logic clashes in the failure report on screen. :) You then need to physically wire that parport pin to the stuff that will do your job, probably by booster relays to get enough power to bang the solenoid valves that will actually do the work. I would also incorporate a final tally signal, needing an input pin, to determine if the drawbar has responded, and do any error handling in case it doesn't reclose properly because of swarf in the works or whatever. One could also tally the air pressure from a pressure switch as being sufficient to run the drawbar. You could sit and wait till it comes up, then do the tool change while the operator is refilling his coffee cup. You could even put a small air pressure button driven by that signal in the right panel of axis that turns red when the pressure is too low. IOW, let you imagination out to play, but observe and keep notes. :) In the back of those ring binders I mention below is a good place so you know where they are. At hookup time in the hal file: net name_of_signal source_of_signal where_to_send [where_to_send] [etc] and one can expend the output tree later in the hal file like this: net name_of_signal where_to_send [where_to_send] [etc] which will send the previously named source_of_signal to several more places. At this stage, I would also recommend the integrators manual and the users manual be converted to double sided dead tree format mounted in 3 ring binders, there is tons of useful info in them. At my age poor short term memory, I still do that about every 2 years to keep up with the detail changes. Trying to clear away some of the fog, I hope this helps. Cheers, Gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Remapping M6 - change_epilog not called.
On 31 March 2014 22:13, Rod Fitzsimmons Frey rodf...@gmail.com wrote: Everything's working great, I'm just getting hung up on communicating with them from the python remap code. Looks like the suggestion of mapping to M64 commands is the way to go, although it seems a bit unsatisfying. I was really trying to do things in the most general way and the python remapping seems like a wonderful avenue. You can import hal into your Python and create HAL pins from your code to connect to other HAL pins. It might even be possible to set hal pins from Python without exporting pins, I can see a set_p function in help(hal) However, I think that exporting pins to HAL is the right way, rather than hard-coding links in the software. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Remapping M6 - change_epilog not called.
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
Re: [Emc-users] Remapping M6 - change_epilog not called.
Thanks, I'll do that! On Wed, Mar 26, 2014 at 3:15 PM, Michael Haberler mai...@mah.priv.atwrote: 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 -- 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
