Back
[00:00:28] <Aero-Tec> why would I need to change the gcode?
[00:00:49] <Valen> axis probably isnt going to be called B is it?
[00:00:54] <Valen> or am i smoking crack
[00:00:56] <Aero-Tec> the scale should eb the same and the axis name should be as well
[00:01:05] <Valen> its been a long time since I have dug around in the guts of it
[00:01:49] <Aero-Tec> if it is not B axis I have to redo HAL for a new axis name
[00:02:13] <Aero-Tec> B is wired to the motor for making springs
[00:02:16] <Valen> fair enough, file it under the i'm smoking crack heading lol
[00:02:24] <Valen> whats the machine anyway? got a video?
[00:03:04] <Aero-Tec> I know B is norm a rotary axis
[00:03:26] <Aero-Tec> but like you said, it should be able to be redone
[00:03:56] <Aero-Tec> will loose my 360 roll over
[00:04:23] <Valen> yeah, you can just keep going in the same direction though, only real issue is re-zeroing it
[00:04:24] <Aero-Tec> no vid
[00:04:40] <Valen> before they added that to EMC people used to have to "unwind" to do it
[00:05:14] <Aero-Tec> yea, do not want to unwind
[00:06:24] <Aero-Tec> the email list posting showed up for me
[00:06:38] <Aero-Tec> night, I am off to bed
[00:06:49] <Aero-Tec> hope to have a answer in the morn
[00:07:04] <Aero-Tec> thanks for your help
[00:07:48] <Valen> good luck
[00:07:52] <Valen> no worries
[02:08:31] <DJ9DJ> moin
[07:03:51] <mrsun> sweden the land that doesnt want to exist :P
[07:04:04] <mrsun> aparently the gingerbread man is rasist and is getting banned ...
[07:04:06] <mrsun> like wtf :/
[11:36:43] <Aero-Tec> mrsun: what are you going on about?
[11:37:27] <Aero-Tec> who got banned from what?
[11:38:26] <Aero-Tec> I am still dealing with no machine stopping when it should be going flat out
[11:38:43] <Aero-Tec> asking in the mailing list as well for help
[11:39:01] <Aero-Tec> so far nothing of help
[11:39:49] <r00t4rd3d> new arduino board:
[11:39:50] <r00t4rd3d> http://arduino.cc/en/Main/ArduinoBoardEsplora
[11:42:47] <jdh> google?
[11:43:21] <jdh> that's a funky looking board.
[11:43:24] <archivist> Aero-Tec, did you post the real gcode to the list
[11:44:01] <Aero-Tec> I did this morming
[11:44:16] <Aero-Tec> the non G93 version
[11:44:27] <Aero-Tec> can do the G93 version as well
[11:44:57] <archivist> it arrived on gmail 8 minutes ago
[11:45:18] <archivist> that is not like the one you posted in here yesterday, that had excess g91 I noticed
[11:46:59] <archivist> I would recommend you dont repeat g90 if already in the mode
[11:48:28] <archivist> G0G90X0 feels dirty in the extreme
[11:53:28] <archivist> also add exactly where you think you get stops
[11:58:30] <cradek> those extra words don't hurt anything, but like archivist I'd also appreciate more information like what you think is incorrect about the motion and where
[11:58:48] <cradek> (a minimized test case that shows the problem would also have been nice)
[12:00:11] <archivist> are you sure the parser wont finish the previous g0 when there is a g90 in between
[12:00:27] <cradek> that makes no difference
[12:02:50] <cradek> I wonder what the intent of F19000000 is
[12:02:51] <archivist> he is looking for best possible speed (blending)
[12:03:07] <archivist> get the rotary as fast as it can go
[12:04:55] <Aero-Tec> yes
[12:05:03] <Aero-Tec> that was exactly the idea
[12:07:01] <Aero-Tec> it should be able to do all this in one smooth move
[12:07:05] <Aero-Tec> F19000000
[12:07:07] <Aero-Tec> G1 X-0.03 B100
[12:07:08] <Aero-Tec> G1 X-0.01 B60
[12:07:10] <Aero-Tec> G1 X-.01 B500
[12:07:11] <Aero-Tec> G1 X-1 B3240
[12:07:45] <Aero-Tec> not stop at the end of each move
[12:08:18] <archivist> it may slow down but dies it really stop
[12:08:24] <archivist> does
[12:08:42] <Aero-Tec> sure looks like it does
[12:08:54] <cradek> I see slowing down but not stopping
[12:09:21] <Aero-Tec> with a open G64 it should not slow down at all
[12:09:47] <Aero-Tec> it should flat out boggy through the code
[12:10:44] <Aero-Tec> at least that is how I read the info about G64
[12:10:53] <IchGuckLive> hi all
[12:11:22] <IchGuckLive> Aero-Tec: ? how did you came up
[12:12:01] <cradek> Aero-Tec: between which lines are you seeing a stop that you think shouldn't be there?
[12:12:29] <IchGuckLive> cradek: did he post g-code
[12:12:42] <cradek> IchGuckLive: to the mailing list
[12:12:50] <IchGuckLive> ah ok
[12:12:57] <IchGuckLive> im off the list
[12:13:04] <Aero-Tec> I have posted a paste bin version here as well
[12:13:33] <Aero-Tec> IchGuckLive: I had to go back to the old setup
[12:13:42] <Aero-Tec> both INI and hal
[12:13:46] <archivist> we still dont know where you think it is stopping
[12:13:55] <Aero-Tec> your version did not work near as well
[12:15:01] <IchGuckLive> (ROTORY TABLE STEPPER MOUNT PROFILE.NC) is this the NC
[12:15:57] <cradek> unless you answer my question I will assume any problem is caused by the misspelling ROTORY
[12:16:02] <IchGuckLive> mach3 code is bad
[12:16:34] <Aero-Tec> yes that is it
[12:17:04] <Aero-Tec> and the title means nothing
[12:17:48] <Aero-Tec> it was code from before, I turned it into starter code for hand written code I did
[12:18:13] <Aero-Tec> missed a line in the code before
[12:18:21] <Aero-Tec> F19000000
[12:18:23] <Aero-Tec> G1 X-0.03 B100
[12:18:25] <Aero-Tec> G1 X-0.01 B60
[12:18:26] <Aero-Tec> G1 X-.01 B500
[12:18:28] <Aero-Tec> G1 X-1 B3240 ;4680
[12:18:30] <Aero-Tec> G1 X-0.02 B530
[12:18:49] <Aero-Tec> it is here where you notice it the most
[12:18:51] <Aero-Tec> G1 X-1 B3240 ;4680
[12:18:53] <Aero-Tec> G1 X-0.02 B530
[12:19:41] <Aero-Tec> the other short small moves are harder to see as they no sooner get going and then they are stopping, so they are slow to get to full speed
[12:20:14] <IchGuckLive> get this of ;4680 and the B axius need a stop bevor returning
[12:20:28] <cradek> between those two lines X is reversing, right?
[12:20:31] <Aero-Tec> then the big run and then it comes screaming to a halt, does one more short move then reverse
[12:21:32] <IchGuckLive> B is also reversing so it has to take a litel stop
[12:22:05] <archivist> it is in g91!
[12:22:10] <Aero-Tec> no, the mode is G91, relative, it is all the same dir
[12:22:38] <cradek> doh
[12:22:42] <cradek> right
[12:22:47] <IchGuckLive> B is a wrapped rotary in your ini
[12:22:50] <archivist> have you got the x per rotation degrees the same
[12:23:05] <Aero-Tec> yes, B is wrapped
[12:23:13] <archivist> else there is a corner
[12:24:26] <Aero-Tec> no it is not, that is why it is broken into segments, to close the ends of the spring
[12:24:40] <IchGuckLive> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?WrappedRotaryAxes
[12:24:46] <Aero-Tec> with G64 it sould not care much about the corner
[12:25:00] <IchGuckLive> Aero-Tec: did you read the behavier of a wrapped rotary on G91
[12:25:14] <archivist> you need to specify a larger tolerance I think
[12:25:15] <Aero-Tec> guess not
[12:25:28] <Aero-Tec> with G64 open like I did
[12:25:46] <Aero-Tec> it is unlimited, just go as fast as it can
[12:26:05] <Aero-Tec> I would put a limit on it if needed
[12:26:06] <cradek> I doubt tolerance mode affects these blends
[12:26:44] <Aero-Tec> there is not blend, I can see it stop, or so darn close it looks to be stopped
[12:26:53] <jthornton> I ran the file in the 9 axis sim and it seems to run smooth to me without any stopping
[12:27:04] <cradek> well I plotted the motion, and it doesn't stop
[12:27:26] <cradek> it does slow down
[12:30:26] <Aero-Tec> how slow?
[12:31:18] <cradek> between lines 20 and 21 it slows down about about 40%ish
[12:31:19] <Aero-Tec> I read the info about wrapped, one can command a move greater then 360, I have done it and it works fine
[12:31:43] <cradek> I don't have wrapped turned on, but it doesn't matter in this G91 program
[12:31:45] <Aero-Tec> in G90 you can not but G91 is no problem
[12:31:54] <cradek> right
[12:32:35] <Aero-Tec> could wrapped be a bug in the system?
[12:32:37] <cradek> is your spring winder just 2 axes, X and B?
[12:32:51] <Aero-Tec> could wrapped be making it stop when it should not?
[12:32:55] <gmouer> I have a M110 code setup and working for my collet closer BUT I really want it to be M10 to be more like the standards out there. If I rename the file from M110 to M10 it no longer works. The remap document says M100-M199 and the unassigned (M10) codes are available and it does not mention any different method of setting them up. What am I missing to be able to use this working bin/bash
[12:32:55] <gmouer> file as M10 ?
[12:32:59] <Aero-Tec> yes
[12:33:01] <cradek> unlikely
[12:33:12] <Aero-Tec> the machine has 4 axis
[12:33:16] <cradek> (I don't believe that it's stopping unless you show me a plot that shows it.)
[12:34:06] <Aero-Tec> it is slowing tons more then 40% or or even to 40%, it stops or oh so close to it
[12:34:16] <cradek> ok can you elaborate on how your machine has 2 axes and also has 4 axes
[12:34:21] <Aero-Tec> how do I plot?
[12:34:32] <cradek> with halscope
[12:34:46] <Aero-Tec> and one can save it to file?
[12:35:18] <Aero-Tec> it is a knee mill, started life with X,Y,Z,A
[12:35:37] <cradek> here is what I am seeing:
http://timeguy.com/cradek-files/emc/lines20-21-22.png
[12:35:48] <cradek> there are no stops, but the blends are poor
[12:35:51] <Aero-Tec> but mach liked to drive Z into table or anything else in the way so Z was removed
[12:36:11] <Aero-Tec> and turned into a portable B axis
[12:36:47] <Aero-Tec> A is a large rotary table with worn drive
[12:37:22] <cradek> ok, I was picturing a dedicated spring-winding machine with only two degrees of freedom
[12:37:38] <cradek> and I had a suggestion relevant to that
[12:37:51] <Aero-Tec> it is also somewhat portable, heavy. I use it in vertical and horizontal config as needed.
[12:39:31] <Aero-Tec> cool, how did you do that?
[12:39:57] <Aero-Tec> first how did you set it up and second how did you get that pix?
[12:40:30] <Aero-Tec> I can gen one for you so you can see for your self
[12:41:17] <cradek> you can see the three pins I plotted in the picture. I took the screenshot with the normal screenshot-taker.
[12:42:29] <Aero-Tec> new to linux so I did not know there was a screen shot taker
[12:43:06] <archivist> in applications, accessories
[12:43:10] <Aero-Tec> also do you have to time the screen shot? or can hal scope do freeze frame?
[12:43:30] <cradek> I think "corners" in XB (etc) are not as well blended as corners in XY, YZ, ZX, AB, BC, CA
[12:45:31] <gmouer> mhaberler: just the guy I need, I have a remap question
[12:45:45] <mhaberler> uh
[12:46:04] <mhaberler> go ahead
[12:46:21] <Aero-Tec> looks like X did not stop at all
[12:46:25] <gmouer> I have a m110 code setup and working for my collet closer BUT really want to use M10 If I rename the file to M10 it no longer runs
[12:46:44] <Aero-Tec> B came close but X looked to be non stop
[12:46:51] <Aero-Tec> if I read it right
[12:46:51] <gmouer> it is a bin/bash file the simply sets a pin state to true
[12:47:00] <mhaberler> I assume M10 is a non-remappable builtin
[12:47:04] <mhaberler> let me look
[12:47:19] <gmouer> M10 showed as unassigned
[12:47:58] <mhaberler> aja, just saw it
[12:48:36] <Aero-Tec> will see if I can do a hal scope for you guys
[12:48:50] <mhaberler> right. so what is 'no longer runs' - please pastebin log, config etc
[12:49:04] <gmouer> the M110 works with no ini file entries at all, would the M10 require entries in the ini file of some sort? (I tried but no go)
[12:49:27] <mhaberler> then that was not a remap
[12:49:47] <mhaberler> but you used the M100-m199 codes which are something different
[12:50:02] <gmouer> I am new, but think that is correct, I set up the M110 like the examples
[12:50:21] <gmouer> So, to use M10 would need a remap then?
[12:50:22] <mhaberler> you used this:
http://www.linuxcnc.org/docs/devel/html/gcode/m-code.html#_m100_to_m199_user_defined_commands_a_id_sec_m100_to_m199_a
[12:50:53] <mhaberler> do you absolutely need it to be M10?
[12:51:20] <mhaberler> yes it would, but you could call the m110 in the m10 remap procedure
[12:51:40] <gmouer> no, not absolutely, but M10/M11 is what most lathes use for collet closer and it would not require tweaking cadcam postprocessor
[12:52:31] <mhaberler> fine, so define a M10 remap as outlined here:
http://www.linuxcnc.org/docs/devel/html/remap/structure.html#_an_minimal_example_remapped_code
[12:52:32] <gmouer> tried calling m110 in the m10 remap BUT think I screwed up..... used uppercase for the m10 was thinking it was the same as the M110
[12:52:50] <mhaberler> and in the myprocedure.ngc you call your m110
[12:52:58] <gmouer> yes
[12:53:14] <mhaberler> well if you did no ini changes the m10 remap didnt exist
[12:53:34] <mhaberler> follow that example, and adapt it to call m110 in myprocedure
[12:53:38] <gmouer> I put the M10 into the ini rmap when I tried it that way
[12:53:51] <mhaberler> you just said you did no ini changes
[12:54:14] <gmouer> tried it both ways, first simply renamed M110 to M10, then tried a remap
[12:54:26] <mhaberler> how did you try a remap
[12:54:54] <gmouer> the M110 is uppercase M, I think that is my screwup, used uppercase M for the M10 also
[12:55:10] <mhaberler> please post config
[12:55:32] <mhaberler> http://pastebin.com/ them
[12:55:48] <gmouer> can't get at the machine right now to postbin the file
[12:55:56] <mhaberler> me neither
[12:56:09] <gmouer> should the m in m10 be lowercase?????
[12:56:32] <mhaberler> it does not matter except if explicitly noted in the manual; there is one such note
[12:57:23] <gmouer> I remember that M100-199 had to be uppercase, yet g code remaps had to be lowercase, no idea about M0-M99 case requrements
[12:57:45] <mhaberler> no, they dont
[12:58:09] <mhaberler> just copy and paste the manual example, and go from there - and take one step at a time
[12:59:09] <gmouer> I have other remaps up and running without problem, but they are G code remaps
[12:59:26] <mhaberler> well fine, then its no different with M
[12:59:35] <gmouer> and I did a couple of M code setups in the M100+ area without problem
[12:59:45] <IchGuckLive> REMAP=M10 modalgroup=10 ngc=m10
[12:59:59] <mhaberler> AHA
[13:00:16] <gmouer> does it have to be a ngc file or can it be a bin/bash file like my M110 code?
[13:00:46] <mhaberler> again, the manual is entirely clear saying: either an ngc file or a Python function
[13:00:53] <IchGuckLive> m10.ngc
[13:00:55] <IchGuckLive> #!/bin/bash
[13:00:56] <IchGuckLive> # file to turn on parport pin 14 to open the collet closer
[13:00:58] <IchGuckLive> halcmd setp parport.0.pin-14-out True
[13:01:00] <IchGuckLive> exit 0
[13:01:10] <IchGuckLive> this shoudt work
[13:01:32] <mhaberler> Mr IchGuckLive: I am sorry - shell code in an ngc procedure will _not_ work
[13:02:16] <gmouer> I am new so the docs are confusing sometimes, I didn't think a .ngc file could have a #!/bin/bash format in it
[13:02:16] <mhaberler> please thisregard this post, this is just extra confusion
[13:02:22] <IchGuckLive> it is working in userdifined mcodes
[13:02:34] <mhaberler> that is _not a remap_
[13:02:54] <IchGuckLive> agree
[13:03:39] <mhaberler> gmouer: what you want is:
[13:03:49] <gmouer> the doc says both unassigned codes and M100-M199 are available for remap, that is prob where i got confused, I tried the same methods for M110 as for M10 M110 has no ini file entry and it works
[13:04:03] <mhaberler> really?
[13:04:47] <gmouer> yea, the docs said to restart linuxcnc and it will find the new M110 code in its folder, which it did, no ini file entry at all
[13:05:15] <mhaberler> that is all fine but what you actually wanted to do is remap M10 to execute your M110, not remap M110
[13:05:59] <gmouer> yes, but the doc led me to believe that M10 and M110 could be handled in the same manner
[13:06:14] <gmouer> that is why I simply tried renaming the file at first
[13:06:15] <mhaberler> no, the M100- section doesnt say that
[13:07:23] <mhaberler> just follow the example link I gave you, and make it work. Then change M400 to M10. then add your M110 to the ngc procedure and it will work.
[13:07:24] <IchGuckLive> mhaberler: can i put self.execute("M110",lineno()) into the remap o<m10> sub
[13:08:09] <gmouer> .3. Currently unallocated M-codes: These codes are currently undefined in the current implementation of LinuxCNC and may be used to define new M-codes:
[13:08:09] <gmouer> M10
[13:08:09] <gmouer> M11 M12 M13 M14 M15 M16 M17 M18 M19 M20
[13:08:09] <gmouer> M21 M22 M23 M24 M25 M26 M27 M28 M29 M31 M32 M33 M34 M35 M36 M37 M38 M39 M40
[13:08:09] <gmouer> M41 M42 M43 M44 M45 M46 M47 M54 M55 M56 M57 M58 M59 M74 M75 M76 M77 M78 M79 M80
[13:08:10] <gmouer> M81 M82 M83 M84 M85 M86 M87 M88 M89 M90
[13:08:10] <gmouer> M91 M92 M93 M94 M95 M96 M97 M98 M99All codes between M199 and M999.
[13:08:12] <mhaberler> you can, but what is the point
[13:08:21] <gmouer> this is what led me to believe it would work
[13:08:27] <IchGuckLive> then it is simple
[13:08:45] <IchGuckLive> as we call the M110 witch holds the halcmd
[13:09:11] <gmouer> yes, I used a halcmd in my M110 file
[13:09:11] <mhaberler> the M codes manual is quite clare that this feature works in the M100-M199 range and not elsewhere
[13:09:38] <IchGuckLive> but the Remap M10 cals the M110
[13:09:46] <mhaberler> yes, fine
[13:10:08] <mhaberler> M100-M199 is an old way of remapping, and all you can do is shell commands
[13:10:10] <IchGuckLive> so with 3 lines it is done
[13:12:06] <gmouer> guess I will have to just experiment more. The other remaps I did all work fine. One uncovered a code bug but that was fixed and now works fine also.
[13:12:29] <mhaberler> do not waste time with experiments, use the manual example
[13:12:33] <IchGuckLive> mhaberler: im still confused can i do this i the sub of the ngc or do i need to put this into a python
[13:12:52] <IchGuckLive> self.execute("M110",lineno())
[13:13:08] <mhaberler> that is a Pyhton statement, what calls it?
[13:13:09] <gmouer> the manual examples didn't prove to be a lot of help, that is why I am here
[13:13:34] <IchGuckLive> so python=m10 not ngc=m10
[13:13:58] <mhaberler> ok, let us walk through the example
[13:14:15] <IchGuckLive> up tp you
[13:14:19] <mhaberler> you write in [RS274NGC]:
[13:14:30] <mhaberler> REMAP=m10 ngc=foo.ngc
[13:14:45] <mhaberler> you create foo.ngc on some path the interpreter will find
[13:14:49] <mhaberler> it shall read:
[13:14:54] <mhaberler> o<foo> sub
[13:14:56] <mhaberler> m100
[13:15:05] <mhaberler> o<foo> endsub
[13:15:06] <mhaberler> m2
[13:15:18] <mhaberler> sorry m110 not m100
[13:15:26] <mhaberler> save files, restart linuxcnc, done.
[13:15:49] <IchGuckLive> yes shorter then mine
[13:16:20] <gmouer> pretty sure I did exactly that, with the possible exception of using upper case M's, I will try it again
[13:16:24] <mhaberler> all I did change from the manual example is change M400 to M10 and myprocedure to foo
[13:16:56] <mhaberler> split the problem in two halves:
[13:17:09] <mhaberler> first write an ngc procedure which does what you want
[13:17:15] <mhaberler> for instance, your M100
[13:17:23] <mhaberler> the name of the proecure is irrelevant
[13:17:26] <IchGuckLive> 110
[13:17:34] <gmouer> if the ngc file was named M10.ngc using upper case, that would not present a problem then?
[13:17:42] <gmouer> I got a file not found type error
[13:17:56] <mhaberler> it could, use some other name, but I dont think so
[13:18:17] <IchGuckLive> i woudt use colletopen.ngc
[13:18:19] <mhaberler> just use foo and you avoid a name collision
[13:18:22] <gmouer> ahhhhhhh that was my suspect since we started was looking for clairification
[13:18:23] <mhaberler> excellent
[13:19:01] <mhaberler> you experiment with colletopen.ngc until it does exactly what you want
[13:19:16] <IchGuckLive> foo.ngc is an error
[13:19:20] <IchGuckLive> foo
[13:19:21] <mhaberler> executie it like 'o<colletopen> call
[13:19:26] <gmouer> I will play some more and if I hit a dead end I will save the files to pastebin next time
[13:19:43] <mhaberler> (can I take a single customer at a time please ;)
[13:19:53] <IchGuckLive> Do not specify an .ngc extension
[13:20:20] <mhaberler> gmouer: forget remap for now, get the ngc procure working
[13:20:54] <mhaberler> if you can call it with 'o<whatever> call' in MDI and it does what you want, then take the next step
[13:21:03] <IchGuckLive> REMAP=m10 ngc=foo.ngc this is wrong -> REMAP=m10 ngc=foo without the ngc
[13:22:06] <mhaberler> can I quote from the manual, which is clear on the issue:
[13:22:08] <mhaberler> ngc=<ngc_basename>
[13:22:09] <mhaberler> Basename of an O-word subroutine file name. Do not specify an .ngc extension.
[13:22:26] <IchGuckLive> you got it
[13:22:46] <mhaberler> it is all there, gents - I cannot read it for you, I can only write it for you
[13:22:59] <IchGuckLive> B)
[13:23:43] <IchGuckLive> i learned alot thanks mhaberler and by for today
[13:24:11] <gmouer> respectfully, the docs are clear to a highly experienced user, but can be quite confusing to someone new to linuxcnc, aka its all clear once you know it.
[13:25:40] <mhaberler> I know - it would really help if some non-programmer added a section here
[13:26:02] <mhaberler> by definition that cant be me though, but I am happy to add a contribution
[13:27:04] <gmouer> I will get it, I always do, its just that some battles are bloodier than others
[13:27:22] <mhaberler> have you probed around configs/sim/remap ?
[13:27:45] <gmouer> I have not played with sim's at all
[13:27:56] <mhaberler> it works in non-sim just alike
[13:28:21] <gmouer> I came from the mach3 world about a year ago, since have retrofitted 3 machine over to linuxcnc and love it
[13:28:34] <mhaberler> I totally agree on the 'bloody' part, retrofitting that feature onto the existing interpreter structure also qualifies as 'bloody'
[13:28:34] <mhaberler> unfortunately that shows in the configuration a bit
[13:29:02] <mhaberler> you should have seen my first attempt ;)
[13:29:10] <gmouer> I have done a few remaps successfully, so I am getting there, even HAL is now not nearly as much trouble as it once was
[13:29:51] <gmouer> I don't envy you working in the inner depths of the source code
[13:29:56] <mhaberler> the easyest approach is (and I'll add that) is: split problem - first get remap action going without REMAP=something
[13:30:04] <mhaberler> then wrap in a REMAP
[13:30:20] <mhaberler> it only occurred to me later when doing the demos
[13:30:43] <gmouer> yes, I did exactly that when I setup my g68 and g69 remaps (for a gang tooled lathe)
[13:31:21] <mhaberler> any surprises?
[13:31:49] <gmouer> a code bug which you fixed and pushed, then all worked swell
[13:31:55] <mhaberler> btw even if you have a REMAP=M10 ngc=foo
[13:32:16] <mhaberler> you still can do 'o<foo> call' to make sure the action is doing the right thing
[13:32:32] <mhaberler> a remap is a glorified way to call a NGC or Python subroutine
[13:32:41] <mhaberler> (_very_ glorified)
[13:32:42] <gmouer> yes, I have done that in the past
[13:32:48] <gmouer> good technique
[13:33:19] <mhaberler> ok, you are drafted to write the debugging section of the remapping manual ;)
[13:33:30] <gmouer> I have the M110 and M111 working and opening and closing the collet, so I am over half way there
[13:34:11] <gmouer> fortunately, I love this technical stuff so I enjoy it even when it does not go smooth
[13:34:20] <mhaberler> I probably should explain the relation of M1XX and remapping (i.e. none whatsoever)
[13:34:28] <gmouer> I think its the challenge
[13:35:10] <gmouer> yes, that relation of M1XX and remapping is probably what got me all confused
[13:35:23] <mhaberler> well I dont know who did this, but the M1XX was a cheap way to get some user-configurable code going, provided the 'code' is a shell script
[13:36:14] <mhaberler> the first implementation of remapping required C code as glue
[13:36:19] <gmouer> I thought unassigned M codes in the low number range would be handled the same as the M1XX range wrong!
[13:37:08] <mhaberler> well it's a tradeoff; I could have subsumed M1XX under remapping and would have attracted lots of flak
[13:37:17] <gmouer> remapping is a extremely powerfull tool, your work is much appreciated !
[13:37:23] <mhaberler> thanks
[13:37:50] <mhaberler> 'lots of rope' it seems; I really wish I could take some of that out
[13:38:10] <gmouer> I am spoiled with all these tools at my disposal after coming over from mach3, and they all actually work! LOL
[13:38:38] <mhaberler> geek pride and peer pressure go a long way
[13:39:09] <mhaberler> and the danger of looking like a real idiot;)
[13:40:03] <gmouer> a lathe retrofit is what finally sent me to linuxcnc, mach3 was just a lost cause, full of bugs and features that never have worked, like CSS
[13:41:05] <jdh> use Mach4!
[13:41:27] <mhaberler> Jymmm: is it you?
[13:41:34] <gmouer> oh lord! Mach4 LOL,, how many centurys will that take to get the bugs worked out, if ever
[13:41:48] <mhaberler> I wish some day people cook up more creative stuff than my examples, like profile definition and execution, roughing, finish
[13:42:20] <mhaberler> I fear these guys really bet the farm on the wrong vehicle.. very hard to make that dog hunt
[13:42:39] <gmouer> I think some more posted examples of peoples code they used would be very helpfull
[13:43:45] <mhaberler> I think some ideas I of Mach are worth considering; the better integration of interpreter and VBA (or Python in our case) for example, and easier extending of UI's but there's a lot happening here
[13:43:54] <gmouer> I have countless hours searching for sample code similar to what I want to do but rarely find much
[13:44:23] <mhaberler> I will give you some different example of 'code hunts', the one I'm currently on:
[13:44:49] <mhaberler> I have 4 (four) accounts of folks running Xenomai on the BeagleBone ARM card
[13:45:26] <mhaberler> I have one running after a hit-and-miss game, and play 'patch extortion' with the other three
[13:46:09] <mhaberler> it was the same with the LinuxCNC xenomai ports - 4 out there, usable code: very slim - no history, lots of copy & paste, yadayada
[13:46:33] <mhaberler> one would thing 'take and give' is the rule with open source
[13:46:55] <mhaberler> the 'and give' part needs patient..obnoxious reminding
[13:48:37] <gmouer> since coming to linuxcnc from mach, I have identified some real hero's here, that put in a lot of work, of which you are one of those hero's
[13:48:50] <gmouer> and I still get into deep trouble LOL
[13:48:58] <gmouer> but less every day
[13:50:06] <gmouer> thanks much for the help, and your work, I am off to whip my controller into submission
[13:50:24] <mhaberler> good luck, and let me know if you get stuck
[14:22:09] <gmouer> mhaberler: I changed all the uppercase M's to lower case in my ini file remap statements, the ngc m10 filename, and within those files and now the remaps for M10 and M11 work nicely. Wanted to report and say thank you again
[14:22:45] <mhaberler> please copy and paste that line here so I can see what broke it
[14:23:06] <gmouer> the remap line? or the ngc file?
[14:23:38] <Jymmm> mhaberler: ???
[14:23:53] <gmouer> I will get both, brb
[14:24:04] <mhaberler> somebody was touting Mach4, and I though it could be you under a different nick
[14:24:28] <Jymmm> mhaberler: Why? I've never ever used mach.
[14:24:48] <mhaberler> just a stab in the dark
[14:25:29] <Jymmm> mhaberler: Yeah, ok, but what made you think me? I've never promoted M$
[14:25:52] <mhaberler> well, you make all sorts of comments which make me laugh
[14:27:21] * Tom_itx thinks Jymmm just looks guilty
[14:27:33] <Jymmm> of?
[14:27:45] <archivist> anything
[14:28:07] <Jymmm> Nah, got to be more specific.
[14:28:27] <Tom_itx> it's kinda like that red headded freckle faced kid down the street that just has that look
[14:29:15] <Jymmm> Well,, it's those silent Atmel programmer types you gotta watch out for though.
[14:29:25] <Tom_itx> :)
[14:29:53] <gmouer> mhaberler: he is one to make you laugh , the remap lines from my ini file
[14:29:58] <gmouer> SUBROUTINE_PATH = /home/george/linuxcnc/nc_files/ngcgui_lib/
[14:29:58] <gmouer> REMAP=g68 modalgroup=1 ngc=g68
[14:29:58] <gmouer> REMAP=g69 modalgroup=1 ngc=g69
[14:29:58] <gmouer> REMAP=M10 modalgroup=10 ngc=m10
[14:29:58] <gmouer> REMAP=M11 modalgroup=10 ngc=m11
[14:30:40] <mhaberler> are these working or not?
[14:31:14] <mhaberler> if REMAP=m10 didnt work but REMAP=M10 worked, than I need to fix that
[14:31:18] <gmouer> yep, nicely, I switched the upper case M's to lowercase in the ini, the file names and within the files, that fixed it
[14:32:08] <mhaberler> could you verify that saying 'REMAP=m10 …' does not break it?
[14:32:16] <gmouer> ok, I will go back out and change the the m10 to M10 in the remap statement only and see what happens, I suspect it was the M10 in the ngc file name that caused the problem though
[14:32:40] <gmouer> brb
[14:32:41] <mhaberler> the filenames - well thats clear, linux filenames are case sensitive
[14:35:03] <Aero-Tec> cradek: you still around?
[14:35:28] <andypugh> If my milling machine has a 19mm leadscrew, would it make sense to up-size the ballscrew to 25mm? I have a feeling that ballscrews have a bit less stiffness than a leadscrew.
[14:35:34] <Aero-Tec> looks like he is gone
[14:36:16] <gmouer> mhaberler: that was easy, it crashed on startup, debug info says M10 file not found
[14:36:25] <Aero-Tec> I would think ball screws are more stiff then lead screws
[14:36:41] <andypugh> Hertzian stress is way higher, I think
[14:36:46] <Aero-Tec> case hardened should make then real stiff
[14:36:55] <mhaberler> well sure thats the ngc=M10/m10 case; I was referrring to 'REMAP=M10 versus REMAP=m10'
[14:37:13] <andypugh> (or, less pretentiously, there is a lot more metal-to-metal contact in an acme-nut.
[14:37:32] <mhaberler> since the rest behind ngc= is a basename of a file, case matters
[14:37:36] <andypugh> Aero-Tec: Hardening has absolutely zero effect on the stiffness of steel.
[14:37:47] <Aero-Tec> but the contact is not as tight
[14:37:52] <gmouer> that is what I changed, m10 to M10 in the remap statement ngc=M10
[14:38:33] <andypugh> I am not talking about backlash, which is clearly much greater with an acme thread, but the load/deflection curve.
[14:39:03] <Aero-Tec> try bending soft steel, then try hardened steel, I have and I know there is a huge difference
[14:39:28] <gmouer> mhaberler, so case does matter in the filename... I got confused with the uppercase M used in M1XX setups, my mistake
[14:39:56] <mhaberler> right, it should matter only in the non-rs274ngc syntax part
[14:40:12] <mhaberler> the M10 in REMAP=M10 is 'rs274ngc syntax' if you will
[14:40:36] <mhaberler> ngc=filename or python=functionname is according to linux filename or Python naming rules
[14:40:41] <gmouer> that is what threw me, file names for M110 and m11 play the rules different as far as case is concerned
[14:41:30] <Aero-Tec> I am trying to do a hal scope like cradek did
[14:41:32] <mhaberler> ah, maybe those arent case-normalized
[14:41:45] <Aero-Tec> it is not working out like his did
[14:41:53] <gmouer> my M110 file is upper case and no file extension
[14:41:59] <andypugh> Aero-Tec: Yes. But in the elastic region the stifness is identical. The yield stress is much lower, but the Young's Modulus is completely independent of hardness, and is almost exactly the same number for every grade of steel, and only a little different for cast iron.
[14:42:51] <gmouer> mhaberler: that one won't bite me again, another lesson learned
[14:43:01] <Aero-Tec> http://timeguy.com/cradek-files/emc/lines20-21-22.png
[14:43:23] <Aero-Tec> like this one
[14:43:36] <andypugh> So, for example, it doesn't really matter if you make your boring bar out of mild steel or hardened tool steel (assuming you don't bend the mild steel one, of course). If you want to make a boring bar stiffer then you need to give it a carbide core (which _is_ a lot stiffer than steel).
[14:43:39] <mhaberler> and it doesnt work if the filename is m110, not M110, right?
[14:44:25] <gmouer> didn't try the M110 with lower case, went by the example in the document and used upper case with no file extension and set to executable
[14:44:48] <Aero-Tec> so we should have carbide machines instead of cast iron ones?
[14:44:49] <mhaberler> right
[14:45:24] <andypugh> Aero-Tec: Possibly, in an ideal world. Though I am not sure how well damped they would be.
[14:45:57] <gmouer> mhaberler: comes down to confusion in the methods used for Mxx remaps and M1xx commands, different beasts which I now know
[14:46:07] <Aero-Tec> so back to my problem
[14:46:23] <mhaberler> sorry to see it bit you
[14:46:37] <Aero-Tec> there is nothing that can be done with my program stopping with each move?
[14:46:42] <andypugh> There is a "league table" of stiffness here:
http://en.wikipedia.org/wiki/Young%27s_modulus
[14:46:56] <toastyde1th> we don't really care about the machine stiffness per se, we care about the damping
[14:47:09] <andypugh> Beryllium looks marvellous, as it weighs nearly nothing too.
[14:47:13] <gmouer> mhaberler: I heal quickly lol, now to attach the toolchange setup on that ganglathe, thanks again
[14:47:29] <toastyde1th> as long as the machine flexes the same amount for each cut, the cut is repeatable and our process is deterministic
[14:47:45] <toastyde1th> vibration and chatter make it nondeterministic
[14:48:10] <Aero-Tec> how are the cement ones working out?
[14:48:13] <toastyde1th> which is why steel and carbide aren't used in cutting tool machine frames
[14:48:22] <andypugh> toastyde1th: Indeed, in the case of the machine frame you can just add metal. For boring bars and other space-constrained things like milling cutters then the fact that WC is twice as stiff as steel is big plus.
[14:48:23] <Aero-Tec> steel farms in cement
[14:48:40] <toastyde1th> cement/composite machine frames are in production at several very serious machine mfgs
[14:48:48] <toastyde1th> so i'd say they're working out great and damp better than cast iron
[14:48:56] <toastyde1th> andypugh, agree
[14:49:01] <Aero-Tec> steel frame
[14:49:13] <toastyde1th> the frame can still damp out any vibration coming down the carbide tool
[14:49:45] <andypugh> They built a huge triaxial compression testing machine where I used to work, out of reinforcd concrete. I wonder if I can find pictures ?
[14:50:00] <toastyde1th> also, Aero-Tec, you do not use steel anywhere in a machine tool if you can help it
[14:50:08] <toastyde1th> forging machines, yes
[14:50:42] <toastyde1th> there are some notable ultraprecision exceptions of using steels, but they have other methods of compensation
[14:50:43] <Aero-Tec> so what do they use in the concrete ones?
[14:50:50] <Aero-Tec> they need a frame
[14:50:53] <toastyde1th> it's not "concrete" in the Quikcrete sense
[14:51:05] <toastyde1th> they cast a mold and it's an epoxy/aggrigate mix
[14:51:26] <toastyde1th> has more in common with carbon fiber and fiberglass than it does concrete
[14:51:30] <fragalot> http://www.ebay.com/itm/effective-8mm-Japan-Micro-CNC-Stepper-Motor-Screw-Linear-Guide-/181030190554?pt=LH_DefaultDomain_0&hash=item2a263d7dda
[14:51:34] <fragalot> just what I always wanted!
[14:51:34] <fragalot> xD
[14:51:57] <Aero-Tec> they need machined ways and places to bolt things to and to bolt it together
[14:52:10] <toastyde1th> Aero-Tec, ever seen a surface table?
[14:52:13] <toastyde1th> they're granite
[14:52:42] <toastyde1th> there's no problem making flat sections of a composite or putting bushings into it for threads, etc
[14:52:57] <andypugh> fragalot: Those are so cute, I have to have them!
[14:53:05] <Aero-Tec> ok, so how does that help with bolting things together?
[14:53:20] <toastyde1th> you just drill a hole into it, slather epoxy into it, and then jam a bushing into the hole
[14:53:24] <toastyde1th> just like you would any surface plate
[14:53:26] <fragalot> andypugh: :D
[14:53:58] <fragalot> any1 know of cheap DC motor with a high torque leadscrew drive? (I don't care about positioning, it just needs to move something heavy back & forth)
[14:53:59] <Aero-Tec> some how that seems like it would be a week spot
[14:54:06] <toastyde1th> it isn't
[14:54:18] <toastyde1th> and if they're that worried, they just use a long ass threaded rod
[14:54:22] <andypugh> £12, free postage? What the heck...
[14:54:40] <Aero-Tec> cool
[14:54:42] <toastyde1th> you have to remember it's not concrete and isn't brittle like concrete is
[14:54:53] <toastyde1th> the epoxy has some serious tensile strength to it
[14:54:57] <Aero-Tec> so am I stuck with this stopping thing?
[14:55:11] <fragalot> currently considering a powered chute deflector screw motor
[14:56:01] <andypugh> Aero-Tec: The spring-maker?
[14:56:12] <Aero-Tec> yes
[14:57:04] <Aero-Tec> would be a pain to have spent all this time and end up with what I started with
[14:57:45] <Aero-Tec> it should just scream through the code, not stop like it does
[14:57:46] <andypugh> I am really puzzled by the problem.
[14:58:17] <Aero-Tec> was trying to do a plot to prove that it stops
[14:58:22] <andypugh> But I think that my suggestion of configuring the rotary to be the Y axis ought to circumvent the issue.
[14:59:05] <andypugh> (Whilst fully accepting that it _shouldn't_ stop)
[14:59:09] <Aero-Tec> cradek: said it did not stop for him when he did the virtual machine
[14:59:52] <andypugh> After my gorceries are delivered I can try it on my real machine.
[15:00:18] <Aero-Tec> would like to just convert the B to linear if that would work
[15:00:35] <Aero-Tec> no reprogramming the HAL
[15:00:58] <Aero-Tec> would have to redo Y and B to move it to Y
[15:01:12] <andypugh> You will need to change the HAL, but it is just a case of changing axis.4. to axis.1 all the way through.
[15:01:51] <andypugh> (You can just copy the whole config folder to make so you don't mess up the working system)
[15:02:26] <Aero-Tec> would just give it a new config name
[15:02:41] <Aero-Tec> treat it as a whole new machine
[15:03:32] <andypugh> Exactly, yes, just make a copy of the folder as a new name, change the name of the INI file, et voila! (A stringed instrument)
[15:04:03] <skunkworks__> logger[psha],
[15:04:03] <logger[psha]> skunkworks__: Log stored at
http://psha.org.ru/irc/%23linuxcnc/2012-12-10.html
[15:10:40] <skunkworks__> Aero-Tec, only paying partial attention... is the accelleration of you rotory axis really low?
[15:17:35] <Aero-Tec> no
[15:17:52] <Aero-Tec> 3000
[15:18:11] <toastyde1th> hey, question. what happens if the accel is too high?
[15:18:24] <Aero-Tec> I need to move it to 2000 if I have it going full speed
[15:18:37] <Aero-Tec> it shuts down
[15:18:52] <Aero-Tec> been there done that
[15:19:00] <toastyde1th> from a position error?
[15:19:22] <Aero-Tec> looks like
[15:19:31] <Aero-Tec> not sure why it would
[15:19:42] <toastyde1th> makes sense
[15:19:47] <toastyde1th> if it's expecting to be somewhere and it isn't
[15:19:53] <toastyde1th> because the drive isn't keeping up
[15:19:54] <Aero-Tec> I must have some thing not right
[15:20:10] <Aero-Tec> mine is step and dir
[15:20:20] <Aero-Tec> so EMC does not have any feed back
[15:20:35] <Aero-Tec> yet if ACC is to high EMC will error out
[15:21:04] <Aero-Tec> now that I think about that, it makes no sense at all
[15:21:18] <toastyde1th> oh, if you don't have feedback i have no idea why that would happen
[15:21:32] <toastyde1th> this is what I get for never ever playing with actual machine parameters or setting up a control
[15:22:15] <Aero-Tec> that's what got me scratchen my head now
[15:22:58] <Aero-Tec> why would EMC shut down if the ACC is to high and there is no feed back to EMC?
[15:23:44] <Aero-Tec> the motor should just lock and make a hell of a racket and EMC should keep going like nothing is wrong
[15:24:05] <PCW> There is always feedback
[15:24:22] <Aero-Tec> with step and dir?
[15:24:24] <Aero-Tec> how?
[15:24:27] <PCW> yes
[15:24:52] <Aero-Tec> I wired it up, I know there is no feed back
[15:24:53] <andypugh> The stepgen reports back how many steps it managed
[15:25:08] <toastyde1th> that's pretty cool
[15:25:25] <PCW> yes the feedback loop is internal to the stepgen component
[15:26:10] <Aero-Tec> so why would it error out with acc being to high?
[15:26:21] <Aero-Tec> yet it can be high if speed is lower
[15:26:34] <PCW> so if the stepgen maxaccel or maxvel or sum of steplen and stepspace limit the step generation you will get a following error
[15:26:40] <Aero-Tec> if I lower the speed I can up the acc
[15:27:00] <Aero-Tec> cool
[15:28:15] <PCW> so if you dont have enough headroom (stepgen max-accel > machine maxaccel) you may get an error
[15:28:19] <andypugh> Actually, the stepgen can acccellerate arbitrarily fast. But can't manage an infinite step rate.
[15:28:23] <Aero-Tec> skunkworks__: do you think you can help me on this?
[15:29:04] <andypugh> You will, howvwever, get an error if you axis max_accel is higher than stepgen_max_accel (you will typically find both parameters in the INI file)
[15:29:34] <Aero-Tec> I have a open G64 and have tried using G93 mode as well
[15:30:02] <Aero-Tec> on this axis I have them both the same
[15:30:04] <Aero-Tec> 3000
[15:31:05] <Aero-Tec> I should up the stengen max
[15:31:25] <PCW> yeah maybe 25% more for headroom
[15:32:25] <Aero-Tec> but that does not explain why it stops at each move
[15:33:21] <Aero-Tec> G61 and G64 seem to make no difference
[15:33:39] <Aero-Tec> I can recheck that theory
[15:34:07] <Aero-Tec> but I am sure it made no difference
[15:34:50] <Aero-Tec> will do some tweaking and get back to you guys
[15:42:00] <andypugh> Aero-Tec: F1000000 seems a very odd thing to see.
[15:42:25] <toastyde1th> he's trying to get the machine to go as fast as it can in inverse time
[15:42:36] <andypugh> Ah, OK.
[15:42:43] <skunkworks__> Aero-Tec, I am suprosed you have not gotten any folling errors with the two accellerations being the same
[15:42:51] <skunkworks__> suprised
[15:43:05] <skunkworks__> following
[15:43:23] <Aero-Tec> only when speed is high and acc is high
[15:43:38] <Aero-Tec> I can lower speed and it will not error
[15:45:53] <toastyde1th> have you done any accuracy tests from those accel numbers
[15:46:15] <toastyde1th> like, taking a gage block and an indicator and making sure it went the distance
[15:47:27] <PCW> Andy: freeby.mesanet.com/7i76x2_ss137.bit
[15:47:29] <PCW> 7i76x2 with V137 SSerial
[15:47:53] <andypugh> Thanks
[15:48:32] <PCW> well V 37 since I think the major version is ignored
[15:50:44] <Aero-Tec> I have for the other axis
[15:50:48] <Aero-Tec> not this one
[15:50:53] <Aero-Tec> ok
[15:51:02] <Aero-Tec> so I redid things
[15:51:10] <Aero-Tec> now have 3 versions
[15:51:18] <Aero-Tec> G94
[15:51:47] <Aero-Tec> oops
[15:51:54] <Aero-Tec> G64
[15:51:59] <Aero-Tec> G61
[15:52:08] <Aero-Tec> G61 and G93
[15:52:24] <Aero-Tec> I would say they all run the same speed
[15:52:55] <Aero-Tec> oops
[15:53:08] <Aero-Tec> dyslexic
[15:53:16] <Aero-Tec> G61
[15:53:23] <Aero-Tec> G64
[15:53:35] <Aero-Tec> G64 and G93
[15:53:47] <Aero-Tec> G61 seemed faster
[15:54:29] <Aero-Tec> G64 ramped down the speed and then ramped up at a much slower rate then G61 did
[15:54:43] <Aero-Tec> so it seemed and maybe way slower over all
[15:54:52] <Aero-Tec> was
[15:56:36] <Aero-Tec> the acc is now 3000 and step gen acc is 5000
[15:56:49] <Aero-Tec> have not done any full speed testing yet
[15:58:51] <Aero-Tec> with the G64 it is just G64, nothing after it so it should be flat out fast
[16:00:06] <Aero-Tec> do you think I found a bug in the system?
[16:00:39] <skunkworks__> not exactly... G64 will go as fast as it can while still touching every segment.. Px.xxx will combine segments that fall withing x.xxx so to keep the speed up...
[16:00:46] <Aero-Tec> would love for it to be something I am doing wrong
[16:01:42] <skunkworks__> so in effect the 'segments' are longer
[16:02:00] <Aero-Tec> so what axis is P referring to?
[16:02:14] <PCW> all
[16:02:30] <Aero-Tec> X-.01 B500
[16:02:46] <Aero-Tec> well 0.15 in X is large
[16:03:06] <Aero-Tec> 0.15 in B is so tiny it would not count
[16:03:33] <skunkworks__> that is above my pay grade :)
[16:03:40] <Aero-Tec> lol
[16:03:58] <Aero-Tec> so should I do P450?
[16:04:41] <Aero-Tec> when I read the G64 info it said something about unlimited P
[16:04:42] <PCW> did you try G64 P 0.010 or some such?
[16:04:48] <JT-Shop> skunkworks__: does G64 Pn work with rotary axes?
[16:05:05] <skunkworks__> It really comes down to - the faster the acelleration - the faster the blend..
[16:05:05] <JT-Shop> I thought it was just for XYZ axes
[16:05:09] <Aero-Tec> just a plain G64 I thought opened things to as fast as possible
[16:05:19] <andypugh> It is interesting to speculate what the units of P would be with a rotary axis.
[16:05:28] <Aero-Tec> I did try it
[16:05:36] <Aero-Tec> p0.015
[16:05:41] <Aero-Tec> P0.15
[16:05:50] <Aero-Tec> can try P450
[16:06:30] <skunkworks__> I think chris made a comment that blending between linear-> rotory isn't the best - but still works
[16:07:38] <skunkworks__> <cradek> I think "corners" in XB (etc) are not as well blended as corners in XY, YZ, ZX, AB, BC, CA
[16:08:12] <skunkworks__> He is the one that would know as he re-wrote most of it. I works 100 times better than it did before
[16:08:53] <Aero-Tec> so any hints as to how to speed up the code?
[16:09:09] <Aero-Tec> seeing as the way I was trying seems not to work
[16:09:29] <Aero-Tec> the code work, just the speed seems like it could be better
[16:09:34] <cradek> you can not fix the blending by changing the gcode
[16:10:08] <cradek> the XB blend certainly is incorrect
[16:10:47] <cradek> http://timeguy.com/cradek-files/emc/xb-misblend.png
[16:11:46] <Aero-Tec> P450 made no change
[16:12:17] <Aero-Tec> hello cradek
[16:12:19] <cradek> like I said at least once earlier, tolerance mode does not affect this blend
[16:12:32] <Aero-Tec> I did try to do one of them and I could not get it right
[16:12:45] <cradek> one of what?
[16:13:02] <Aero-Tec> cool hal charts
[16:13:42] <Aero-Tec> so to make this work
[16:13:55] <Aero-Tec> would making B linear help at all?
[16:14:01] <cradek> no
[16:14:20] <Aero-Tec> or do I have to rewire the axis so it is XY?
[16:14:26] <cradek> yes using X and Y would almost certainly work
[16:15:16] <Aero-Tec> would making Z and B the exact same work?
[16:15:24] <cradek> no
[16:15:27] <Aero-Tec> using the same pins and such
[16:15:41] <cradek> wait, I don't even understand your question
[16:16:04] <Aero-Tec> was hoping the motor would work as B axis and Z axis
[16:16:18] <Aero-Tec> so if I do a Z move it works
[16:16:26] <Aero-Tec> and if I do a B move it works
[16:16:32] <Aero-Tec> same motor
[16:16:35] <Aero-Tec> 2 axis
[16:16:46] <Aero-Tec> I have no Z right now
[16:17:08] <Aero-Tec> so I cold redo it to drive the motor on B
[16:17:14] <Aero-Tec> could
[16:17:42] <Aero-Tec> would save undoing B in HAL
[16:18:05] <Aero-Tec> hope I am not being a pain here
[16:18:10] <Aero-Tec> not trying to be
[16:18:25] <Aero-Tec> just had the thought
[16:19:30] <Aero-Tec> is that too outside the box?
[16:19:46] <DJ9DJ> gn8
[16:26:28] <andypugh> Aero-Tec: I just ran your code, and I think I might understand it.
[16:27:13] <andypugh> I think it is related to the X acceleration. And is a feature, not a bug.
[16:27:52] <cradek> explain?
[16:28:03] <cradek> (looks like a bug to me but maybe I'm missing something)
[16:28:37] <andypugh> The thing is that each move has a fixed ratio of B to X movement. when the speed of X changes the B first has to slow to that ratio for the current X speed, then they both accelerate together in lock-step
[16:29:48] <Aero-Tec> X speed should not be changing
[16:30:04] <andypugh> (And, with low acceleration and fixed tolerance, they both may need to stop before they can restart)
[16:30:05] <cradek> G1 X-0.01 B60
[16:30:05] <cradek> G1 X-.01 B100
[16:30:16] <Aero-Tec> in fact nether should B
[16:30:17] <cradek> I'm concentrating on the blend between these two moves
[16:30:48] <andypugh> Well, those should be B-only moves, so ought to blend seamlessly
[16:30:49] <cradek> andypugh is right that X or B positively must change speed during this transition, since the ratios differ
[16:31:02] <cradek> sorry, this is still G91
[16:31:08] <andypugh> Ah, OK.
[16:32:34] <Aero-Tec> would not G93 nullify that?
[16:33:45] <Aero-Tec> the acc is not so low BTW
[16:34:35] <Aero-Tec> when doing a G61 version it starts and stops fast, real fast
[16:34:48] <Aero-Tec> that is why G61 seams faster
[16:35:30] <Aero-Tec> it is flat out till it is hitting the end and stops, then is back moving again real quick
[16:35:50] <Aero-Tec> G64 ramps down slow and ramps up slow
[16:36:22] <Aero-Tec> even with G93 it still is slow starting and stopping
[16:36:51] <Aero-Tec> I could do a vid of it working so you can see for your self
[16:37:43] <Aero-Tec> run all 3 versions and you can see how fast G61 is and how slow G64 is
[16:38:28] <Aero-Tec> or with some coaching run the HAL scope
[16:39:00] <JT-Shop> do you have the cycle timer?
[16:39:03] <Aero-Tec> I was close, had it all setup, just could not get it to trigger right
[16:39:39] <Aero-Tec> seeing as I have no idea what it is, I would say no
[16:39:57] <Aero-Tec> I know what it could be
[16:40:00] <JT-Shop> it tells you the time for each run of a program
[16:40:10] <Aero-Tec> I have a stop watch
[16:40:15] <JT-Shop> http://linuxcnc.org/docs/devel/html/man/man9/time.9.html
[16:40:46] <JT-Shop> I like using time as I can never start and stop the stop watch all that well when I can find it
[16:40:57] <Aero-Tec> very cool
[16:41:44] <Aero-Tec> I can install it
[16:42:20] <Aero-Tec> I keep finding all sorts of cool things to add to EMC
[16:42:58] <Aero-Tec> seeing as it is in a sub loop
[16:43:23] <Aero-Tec> I am guessing it would not time a loop
[16:43:53] <Aero-Tec> would have to make the loop 1 time
[16:49:20] <Aero-Tec> I believe I can do the HAL part, but the Python part I am not sure what to do with that or even where to start with it
[16:49:35] <gmouer> a couple months ago there was talk about the fanuc style toolchanges for lathe patch being added to master, where can I check if this was ever done? I would love that patch but hate the idea of having to use git and compile a new copy of linuxcnc.
[16:50:36] <andypugh> It wasn't done.
[16:51:08] <gmouer> thanks Andy, any hope of it happening yet?
[16:51:48] <JT-Shop> there is a patch out there somewhere but it still has problems
[16:52:14] <gmouer> yes john, that is the patch I am speaking of, didn't read about any real problems though
[16:52:25] <andypugh> Not least being that it's a bit of a strange thing to do, to have such very different ways of handing loolchange.
[16:52:53] <JT-Shop> when you edit the tool table it adds a zillion lines with ; in each line IIRC
[16:53:38] <gmouer> ah yes John, I seen that but it was only if you edited with the tooltable editor I thought
[16:53:54] <JT-Shop> I think that is correct
[16:53:58] <gmouer> isn't there some issues with the tooltable editor beyond that anyways?
[16:54:11] <JT-Shop> not that I know of
[16:54:42] <gmouer> I am kicking around how I want to set up toolchanges etc on this gangtool lathe
[16:54:53] <gmouer> do you use wear offsets John?
[16:55:47] <andypugh> Aero-Tec: Do you feel interested in an experiment that probably won't help, but will satisfy my curiosity? You could try recalibrating B to work in revolutions (rather than degrees). (just multiply the scale by 360, and alter the G-code to suit). I am curious about the effect of relative magnitudes.
[16:56:26] <andypugh> The whole tool-handling thing is up for review anyway.
[16:57:19] <Aero-Tec> sure
[16:57:24] <Aero-Tec> sounds like fun
[16:57:49] <Aero-Tec> I can not see it working like you said
[16:58:04] <gmouer> I seen that mentioned too Andy, but I have a lathe retrofit finished and have to decide how I want to handle toolchanges/wear offsets and such for now until things get reworked
[16:58:58] <Aero-Tec> what theory are you using to think it may make a difference?
[16:58:59] <gmouer> that fanuc patch looked great, its different than the normal linuxcnc method but fanuc methods are pretty proven in the field
[16:59:20] <gmouer> Peter Schmid references fanuc methods a lot in his book
[16:59:34] <Aero-Tec> are you thinking that if the numbers are closer in range it may make a difference?
[17:00:06] <gmouer> right now, there are no provisions for wear offsets in the standard code, right?
[17:00:50] <andypugh> Aero-Tec: Yes.
[17:01:08] <andypugh> gmouer: Not separate from the geometry offsets, no.
[17:01:34] <Aero-Tec> will try it and get back to you
[17:01:45] <Aero-Tec> will you be around for awhile?
[17:01:54] <andypugh> Aye
[17:02:00] <icee> there's no way in g code to set a 'radius' for rotary moves is there? so you have to calculate ridiculously strange feedrates for combined inch-and-degree-moves
[17:02:17] <gmouer> ok, thanks Andy and John
[17:02:19] <Aero-Tec> did not hear back on the old setting up 2 axis on 1 motor
[17:03:17] <andypugh> icee: pretty much, yes. If you can think of a _definition_ for radius in such a move then perhaps that could change.
[17:04:02] <andypugh> Aero-Tec: My machine running your code:
http://www.youtube.com/watch?v=DQlGAGt_zcM (not processed yet)
[17:04:38] <icee> I have used this before
[17:04:41] <icee> http://www.cncsnw.com/4thFeed.png
[17:04:57] <icee> dX is really "linear distance"
[17:05:35] <andypugh> Do I risk axially-loading some 6909 bearings, or should I use a needle roller and two ball thrust bearings?
[17:05:57] <JT-Shop> how long do you need them to run?
[17:06:32] <andypugh> icee: But linear distance depends on the system knowing where the axes of rotation are. A CAM package can know that, but a G-code interpreter doesnt.
[17:06:50] <andypugh> JT-Shop: They are for my ballnut mount (rotating nut)
[17:07:20] <icee> andypugh: i'm just saying, it'd be nice for me to be able to say "Hey, now after that Z move I am 2" over the center of the rotary table"
[17:07:34] <icee> and then feedrates remain in linear units
[17:07:56] <JT-Shop> I'd use angular contact ball bearings at the least
[17:08:05] <icee> a fancier definition would be
[17:08:17] <icee> "FYI the coordinates for the center of rotation are ____"
[17:08:17] <andypugh> JT-Shop: So would I, if they would fit.
[17:08:26] <JT-Shop> I see
[17:08:27] <icee> i know with multiple angular axes this starts to break down
[17:08:41] <andypugh> icee: STEP_NC might allow that, G-code is not so clever.
[17:09:28] <icee> it seems like an extension g code for "be advised: tool is ____ inches from the center of rotation"
[17:09:31] <andypugh> JT-Shop: If you can find angular contacr bearings about 2" ID and about 2.5" OD then I would use them.
[17:09:33] <icee> would be nice
[17:09:46] <andypugh> Extending G-code is hard. It's full.
[17:10:04] <JT-Shop> wow that is only a 1/4" thick
[17:10:47] <andypugh> (Well, every letter has a use, I guess there are plenty of spare G and M codes). Coordinate system axis definition could be a special gase of G10 for example.
[17:10:48] <JT-Shop> do you have room to fit a thrust bearing in there as well as the 6909's?
[17:11:23] <andypugh> I would need two thrust bearings, and at that point a needle roller looks good.
[17:16:55] <icee> what's "G07 feedrate sine curve control"?
[17:17:28] <andypugh> Sounds like witchcraft to me :-)
[17:17:43] <icee> sounds like it could be what we're talking about
[17:20:04] <icee> nope
[17:20:51] <icee> i believe it lets you do a circular interpolation while not moving one of the involved axes
[17:21:00] <icee> e.g. sine wave speed of movement
[17:21:08] <icee> wonky
[17:23:07] <andypugh> I don't think we have it in LinuxCNC
[17:26:42] <JT-Shop> sure we have G7
[17:28:43] <icee> anyways, pretty pretty please to all developers-- saner feedrates for angular+linear moves would be nice <3
[17:28:54] <andypugh> As diameter mode, not "feedrate sine curve control"
[17:29:50] <andypugh> icee: Seroiusly, if you can define "sane" then it might happen. But I don't think it can be done in the context of what the G-code interpreter knows. It has to be a CAM thing.
[17:30:26] <icee> so, saying "angle for axis a becomes a feedrate as if scaled by this radius" isn't sane?
[17:31:53] <icee> i mean, a lot of the time i could just pick a worst case/outer radius and be happy and leave it at that
[17:35:04] <icee> so if you say the radius == 2 inches, eag degree is .034 inches, so if you do a single rotary axis move of 20IPM you're really saying 573 degrees/min
[17:37:47] <tjb1> JT-Shop: dinner is ready honey.
[17:39:59] <andypugh> The problem is, what is the radius?
[17:40:37] <icee> the radius is something you specify in a g code before the block.. "feedrate adjustment radius for axis A == ___"
[17:40:56] <icee> then if i know my part is 2inches in diam max, i always have a sane feedrate
[17:40:58] <JT-Shop> LOL
[17:41:24] <cpresser> icee: ecm2-gcode can do math. implement it yourself :)
[17:42:09] <andypugh> There is that, there are trig functions.
[17:42:25] <icee> it is just a very annoying expression for multiaxis linear+rotary moves
[17:42:56] <andypugh> I do know where you are comng from, and it is something I have thought about a bit.
[17:43:14] <icee> which, you know, doing it this way, the "dumb way"
[17:43:27] <icee> you'd get slightly wrong feedrates as you machine down the part
[17:43:37] <andypugh> G-code is very, very dumb.
[17:43:46] <icee> (or have to keep adding this "hey, now pretend like the axis radius is 1.5 inches!"
[17:45:27] <andypugh> G3 X100 A 180 I 20 J 30 L30 M40?
[17:45:46] <andypugh> Ah, no, we can't use M, can we?
[17:47:04] <icee> I'm thinking like. G666 A0 R2.0 G1 X3 A180 F10
[17:48:09] <icee> moves X 3 inches and rotates the table 180 degrees (assuming starting position of 0) at 10 inches per minute...
[17:48:57] <andypugh> At the moment the feed rate is such that the X move is at 10 units/min and the A move finishes at the same time.
[17:50:28] <icee> my total movement across the surface is sqrt((3 inches)^2 + (pi * 2 inches)^2)
[17:51:52] <cradek> since you know that (before you write the gcode) you can calculate the right feed and use inverse time mode
[17:52:01] <cradek> think of gcode as the low level language you generate
[17:52:20] <icee> sure, that's what i've been doing
[17:52:43] <icee> it's been 6 months since i've done this, but i'm about to acively start doing it again
[17:52:55] <icee> F is only for the linear axes on emc2 though in combined moves?
[17:53:03] <icee> because i remember doing "pythagorean between degrees and inches"
[17:53:19] <icee> but i don't remember what controller that was targeting
[17:53:43] <cradek> icee: read about inverse time mode in the manual
[17:53:57] <cradek> icee: heck also read about feed rate, is very carefully described
[17:54:42] <icee> i see
[17:54:48] <icee> well, that's a lot better than the other stuff i was doing
[17:55:13] <cradek> http://linuxcnc.org/docs/html/gcode/machining_center.html#sub:feed-rate
[17:55:20] <icee> yes
[17:55:21] <icee> jsut read that
[17:55:47] <icee> ok, cradek. i wrongly blamed emc2 for:
http://www.cncsnw.com/4thFeed.png
[17:56:14] <cradek> uh I have no idea what that means
[17:56:36] <tjb1> JT-Shop: Honey, are you coming in for dinner?
[17:56:46] <JT-Shop> too early
[17:56:48] <icee> cradek: some controllers, F on combined angle+linear moves.. treats the units like they are identical.. e.g. a move of 1 degree and 1 inch would be of length 1.414
[17:57:42] <cradek> in g94 you're doomed no matter what you do, because what is the unit?? the only sane thing to do is use g93 which requires you specify only time
[17:58:05] <cradek> in g94 you have to do something and you better damn well document it because it's going to bite someone no matter what
[17:59:13] <toastyde1th> programming in g94 by hand is for the brave and foolish
[17:59:26] <andypugh> http://www.youtube.com/watch?v=DQlGAGt_zcM (13 and 31 seconds)
[18:00:41] <toastyde1th> nice
[18:01:06] <andypugh> So I see a glitch, but it doesn't seem to be a full stop.
[18:01:52] <toastyde1th> http://www.youtube.com/watch?v=7ZuBZPop2NU
[18:01:55] <toastyde1th> related
[18:03:40] <andypugh> toastyde1th: LinuxCNC can do that..
http://www.youtube.com/watch?v=T4q8gCpeY1A
[18:04:36] <andypugh> How wierd, someone stole my video?
http://www.youtube.com/watch?v=vGgow60KKXM
[18:05:03] <toastyde1th> how accurate is that c axis
[18:05:07] <toastyde1th> just curious
[18:05:23] <toastyde1th> could you live tool it?
[18:07:20] <JT-Shop> andypugh: that bearing is for your lathe ball nut?
[18:07:34] <andypugh> Mill ball-nut
[18:07:47] <JT-Shop> doing a refit on it?
[18:08:09] <adb> andypugh, vietnamien stole
[18:08:32] <andypugh> JT-Shop: Yes. Have been for 2 years..
[18:08:58] <JT-Shop> I know how that is... I've been working on my plasma table going on 5 years now
[18:10:20] <andypugh> I am just not in a major rush.
[18:11:12] <toastyde1th> http://www.youtube.com/watch?v=vyT8UTkCc4k
[18:11:19] <toastyde1th> i got hit by a chip at that temp once
[18:11:24] <toastyde1th> it was unpleasant
[18:11:24] <JT-Shop> are you converting it from a manual to a CNC mill?
[18:15:39] <andypugh> JT-Shop: Haven't you seen it? It's the one with the pneumatic drawbar?
[18:15:58] <JT-Shop> ah yes I remember the drawbar now
[18:16:04] <andypugh> I have the Z moving now, so an update video is in order, I think.
[18:19:32] <JT-Shop> yes
[18:21:37] <Tom_itx> G7 is diameter mode on a lathe not feedrate sine curve control
[18:21:44] <JT-Shop> yep
[18:22:05] <Tom_itx> cad packages handle it just fine though
[18:22:59] <JT-Shop> yep they know what to do
[18:23:14] <Tom_itx> mine will wrap a tool path but it doesn't do angular axis movement that i know of or at least i don't have any templates that ouput code for it
[18:24:18] <Tom_itx> i may have a couple but i've never used them or know how they work
[18:24:55] <Tom_itx> since we didn't have any mills that did rotary movement
[18:25:06] <Tom_itx> at least not 'live'
[18:25:59] <Tom_itx> it would be kinda cool to see my sherline with a cradle and a rotary axis on it though :)
[18:27:00] <Tom_itx> i think feedrates on a rotary would act more like a lathe
[18:27:12] <JT-Shop> you could spend hours programming that :)
[18:27:26] <Tom_itx> as you approach the center it speeds up
[18:27:29] <toastyde1th> a lot of lathe rotary motion is programmed exactly like a milling machine
[18:27:56] <Tom_itx> i wish i'd have gotten into that but we never did
[18:28:20] <toastyde1th> you program an outer profile and the lathe automatically generates it by rotating that point set around 0,0
[18:28:34] <toastyde1th> it's very, very easy to program live tooling on most controls because of this
[18:29:57] <toastyde1th> this would make doing C-synchronized turning equally easy because all you're doing is programming the outer part profile and commanding a z depth
[18:30:01] <toastyde1th> machine does the rest
[18:30:11] <toastyde1th> or inner profile, for hexes and stuff
[18:35:36] <toastyde1th> sigh, i wish i had a beat up live tooling machine
[18:37:12] <JT-Shop> I wish my spindle on the BP was not so noisy
[18:37:48] <toastyde1th> air bearing conversion!
[18:38:15] <JT-Shop> I need to remove the variable speed belt drive and put a timing belt in there
[18:39:50] <toastyde1th> there was a video of a homebuilt tesla turbine
[18:39:55] <toastyde1th> that was running at like 10k rpm
[18:40:06] <toastyde1th> THAT would be a cool direct drive spindle
[18:41:48] <toastyde1th> http://www.youtube.com/watch?v=AsV9UUCJ5EI
[18:53:19] <tjb1> PCW: What are your hours?
[18:53:36] <PCW> never again
[18:53:59] <tjb1> Damn...
[18:54:36] <PCW> Oh Mesas Hours, normally 7:30 AM to 4:30 PM PST
[18:58:10] <tjb1> You need to be open 7:30 - 4:30 EST...
[19:00:00] <PCW> I'm often here later but I'm not reliable with orders
[19:01:20] <tjb1> You guys need to get into the 21st century
[19:04:25] <PCW> Rather not
[19:04:32] <PCW> bbl
[19:12:11] <tjb1> JT-Shop:
http://i.imgur.com/4jA3N.jpg?1 and
http://i.imgur.com/w0kPC.jpg?1
[19:12:35] <JT-Shop> how did you know I was back out in the shop?
[19:12:51] <tjb1> I watched you leave dinner...duh
[19:12:59] <JT-Shop> lol
[19:13:51] <tjb1> Thats after I cut 2.5" off Z
[19:14:16] <JT-Shop> can you get more acceleration out of the Z now?
[19:14:52] <tjb1> I guess…until it runs out of grease or gets colder I suppose
[19:15:28] <tjb1> I need to add a bolt to that plate still so the distance is smaller, also read that the prox sensors pick up steel at a longer distance than aluminum
[19:16:35] <JT-Shop> yea a little better to have a steel target
[19:17:45] <JT-Shop> one more slot to mill... damn noisy mill
[19:22:31] <tjb1> Im debating whether or not I can drill that hole on a drill press...
[19:22:54] <JT-Shop> what hole?
[19:23:18] <tjb1> The hole for the bolt
[19:23:42] <JT-Shop> ah
[19:24:52] <tjb1> Ive been too lazy/busy to bring it to school and do it
[19:25:04] <tjb1> Take me longer to sign out all the tools than it would to drill the damn hole
[19:26:18] <JT-Shop> I can drill a pretty accurate hole using a drill press and taking proper precautionary measures
[19:26:47] <toastyde1th> contrast that to my "fuck it we'll do it live" method
[19:26:48] <tjb1> Our is a tractor supply model…not very rigid
[19:27:34] <JT-Shop> don't have to be rigid
[19:28:35] <JT-Shop> center punch, spotting bit if you have one, pilot hole, real hole...
[19:29:14] <cradek> center punch and then file it flat
[19:30:11] <toastyde1th> sharpened spoon
[19:30:12] <cradek> and yep - pilot hole around the size of the web of the drill sized for the real hole, and that's it. don't step up 7 sizes of drill, you lose center a bit more each time.
[19:30:58] <cradek> some seem to think "I'll do this right and use every drill in my index, one step up at a time" - I don't know where people get that or why they think it works
[19:31:08] <toastyde1th> because science
[19:33:33] <Jymmm> 9mm
[19:33:36] <JT-Shop> yep, I do it the same way
[19:33:50] <Jymmm> or .33lr if thin gauge
[19:33:53] <Jymmm> .22lr
[19:35:25] <JT-Shop> I'm liking it
http://imagebin.org/238865
[19:35:55] <JT-Shop> no movement on the slats
[19:37:10] <JT-Shop> cradek: what does filing the center punch do?
[19:37:55] <cradek> it gives you just a dent, instead of a dent with random mountains around it to catch the drill and push it around
[19:38:17] <JT-Shop> ok, that makes sense
[19:38:26] <JT-Shop> http://www.youtube.com/watch?v=yhuMLpdnOjY
[19:39:06] <cradek> heh I've never actually seen the guy!
[19:39:41] <cradek> some of his rhymes are really great
[19:39:50] <JT-Shop> yea I like them
[19:40:28] <cradek> birdies all try and hide ... coated with cyanide
[19:40:42] <JT-Shop> classic
[19:40:54] <JT-Shop> well I'm done out here in the shop for the day
[19:40:58] <JT-Shop> goodnight
[19:53:42] <tjb1> Damn JT-Shop, you have like triple the supports I do
[20:21:11] <skunkworks> logger[psha]:
[20:21:11] <logger[psha]> skunkworks: Log stored at
http://psha.org.ru/irc/%23linuxcnc/2012-12-11.html
[22:42:22] <r00t4rd3d> http://arduino.cc/en/Main/ArduinoBoardEsplora
[22:43:39] <r00t4rd3d> im gonna make a pendant out of one of thems
[23:14:54] <r00t4rd3d> http://i.imgur.com/mG0PW.jpg
[23:31:20] <tjb1> You better be careful r0t
[23:31:22] <tjb1> r00t4rd3d:
