00:05:44 yes 00:05:54 just got back 00:07:11 did you see my mail to the board list about "board business"? 00:07:20 yes 00:07:24 (been having mail probs, it hasn't appeared here yet) 00:07:29 it's not you 00:07:36 sf mails were taking over an hour earlier today 00:07:53 well, I guess it could also be you :-) 00:08:00 I sent that one a lunchtime I think, and its still not here 00:08:30 switch to the board chan? 00:08:33 yes 00:09:36 SWP_Away is now known as SWPadnos_ 00:09:50 hi there 00:10:02 hi steve 00:10:34 did you see the change I committed to core_servo.hal? 00:10:45 I think so 00:11:10 pid.n.maxoutput = [AXIS_n]MAX_VELOCITY 00:11:18 fixed the following errors I was getting 00:11:28 damn... my att mail is slow, I saw it on my yahoo acct, but don't have that window open right now 00:11:36 sounds good 00:12:04 it was a real pisser to search for 6 hours to find a configuration change "bug" ;) 00:33:04 jmkasunich: still around? 00:33:10 yeah 00:33:19 two questions for you 00:33:53 first, I was thinking about the PID parameter problem (default output limit of 1, but max_velocity default to 1.2), and thought about overshoot 00:34:34 does it make sense to allow the pid block to overshoot the axis max_velocity, to give it a chance to "catch up" to a requested step change in velocity? 00:34:50 that whole topic is a mess 00:35:05 I thought the people with problems were running steppers anyway? 00:35:48 well - you still need PID with steppers (and the USC), becuase the actual step rate (quantized) won't necessarily match the (float) requested rate 00:36:07 the usc isn't steppers ;-) 00:36:22 neither is stepgen 00:36:35 stepgen uses core-stepper.hal 00:36:42 no PID loop 00:37:00 but there should still be some ability to dither between the two closest attainable rates, to get the requested rate as an average 00:37:02 so it is distinct from USC steppers and all others that use core-servo.hal 00:37:11 yes 00:37:30 with core-servo, the pid loop does the dithering as it constantly corrects for errors 00:38:06 stepgen just does it internally, since it already knows how many steps it has output 00:38:17 with core-stepper, there is an internal loop that is part of stepgen, and it does whatever dithering is needed 00:38:19 (using a non-pid method, I know) 00:38:20 yes ;-) 00:38:28 right ;) 00:38:41 kind of an artifact of DDS, actually 00:38:51 I was assuming the problems people were reporting were with stepgen 00:39:00 and assumed some problem with that internal loop 00:39:16 right - I was thinking the same thing with the PPMC stepgen 00:39:20 it's non-trivial, basically a little trapezoidal TP of its own 00:39:33 that's why it took so long to find where the (damned) limit of 1 IPS came from 00:39:47 skunkworks over on the other channel is talking about one of those bugs 00:39:56 I want to go over there and see if I can replicate it 00:40:15 ok 00:40:30 it may well be related to this conversation 00:48:05 sorry - was afk for a mo - I'll read back 01:08:29 petev has joined #emc-devel 01:55:04 hey petev - trying to not pollute that channel 01:55:29 they aren't called that, but the construction of a stepper is basically what you would have with a 2-phase AC motor 01:56:23 microsteppers try to approximate a sinewave (or triangle / trapezoid) into the two phases, 90 degrees apart (instead of 120, like 3-phase AC) 01:57:48 hey cradek - got a sec, or are you fixing a dead computer? :) 01:59:07 swp: I don't realy understand what a 2 phase system is. 2 wires is one phase, 3 wires is 3 phases 01:59:30 2-phase is two sets of 2 wires (each pair gets one phase) 02:00:08 actually, you could do two phase with 3 wires 02:00:10 you can do 3-phase that way as well - 3 separate coils, each with 2 wires (rather than the delta or wye connections usually used) 02:00:21 sure - common, phase A, phase B 02:00:38 the real difference is the phase relationships 02:00:45 2 phase has 90 degrees between phases 02:00:51 3-phase has 120 02:01:08 right, and you get the other two 90-degree "corners" by reversing current direction 02:01:18 which is unnecessary once you have 3 or more phases 02:01:33 3 phase systems almost always reverse current too 02:02:04 yes 02:03:12 so you really have more phases with 4 wire, but some are just 0 volts so you are ignoring them? 02:03:22 4wire? 02:03:40 yes, swp says two separete coils 02:03:42 you mean 3phase with neutral distribution, or 4 wire steppers? 02:03:46 that's 4 wires 02:04:17 steppers have two coils, 90 degrees apart 02:04:18 a 4 wire stepper has two windings oriented 90 degrees to each other (90 electrical degrees) 02:04:43 each winding at some point in the cycle has positive and negative current 02:04:54 hence H bridges in the drive 02:04:59 however, if you don 02:05:02 to me, the phase we are talking about is the potentials between each pair of wires 02:05:14 and is essentially the same construction (brushless, "manual" commutation, sequenced activation) as a BLDC servo 02:05:24 don't want H bridges, then you can center tap each winding, and power one half at a time 02:05:48 so with 4 wires, you get 6 phase relationships, correct? 02:06:04 the number of wires is irrlevant 02:06:10 its the number and orientation of the coils 02:06:35 so when you say phase, you are talking about the coils in the motor then? 02:06:38 yes 02:06:40 ok 02:06:45 sorry - this is a big tangent to my (mostly accurate, but not absolute) statement that people use fake encoders with steppers all the time ;) 02:06:52 you can have a two phase motor with 3, 4, 6, or 8 leads 02:06:59 got it 02:07:56 jmkasunich: can I ask you my halcmd wuestion now? (there seems to be a lull in #emc) 02:08:04 shoot 02:08:27 ok - remember that I was going to add filtering and/ or owner name printing in show? 02:08:35 yeah 02:08:40 but you said that you were going to makesome changes, so I should hold off 02:08:45 yeah 02:09:02 I'm assuming that you haven't made those changes (the multiple long mights with a hot USC getting in the way) 02:09:09 yeah 02:09:12 ;-) 02:09:24 what are you planning, in a nutshell? 02:09:47 long term (weeks, maybe months, but hopefully in an incremental way....) 02:09:56 move metadata out of shmem 02:10:21 ah right - and make userspace calls that can ask for the data using a library 02:10:23 extend the api to support listing, without halcmd actually knowing about and traversing the lists 03:09:14 jmk: did you try out that ngc parser I emailed? 03:09:22 no 03:09:27 me either - sorry 03:09:36 what do you think about the expressions it allows? 03:09:48 sorry, but I can't even keep up with the motion control parts of emc 03:09:49 should we limit their use? 03:10:03 I'm really out of my depth talking about the interp in any but the most general terms 03:10:05 yeah, there's a lot to be done 03:10:20 this is pretty general 03:10:26 like skunkworks following errors.... :-( 03:10:28 it's about what's valid in the g-code 03:10:46 cradek: you still listening? 03:10:52 yes 03:10:53 the grammar kramer gives seems a bit crazy 03:11:21 I recognize his grammar to the best of my understanding of it right now 03:11:34 but I'm not sure its the best 03:11:53 it supports logical OR, XOR, and AND 03:12:02 but there is not logical invert 03:12:11 also there are no relational ops 03:12:21 I thought all the variables are floating point 03:12:27 how can you do logical operations on them? 03:12:34 and it allows the use of expressions just about anywhere you would expect a number 03:12:47 you can do logical on floating point 03:12:52 true is non-zero 03:13:13 oh, they're logical, not bitwise 03:13:16 yes 03:13:19 gotcha 03:14:02 so what do we all think about the g-code that should be accepted? 03:14:21 are we going to include all the ngc grammar plus lermman stuff? 03:14:25 anything that may be in the field today must be accepted 03:14:27 I'm dead serious pete, I'm not qualified to discuss it 03:14:30 or should we keep it simple? 03:14:54 I ran 3D_chips no prob, but it's basic 03:15:13 I think some of the stuff in Kramer's grammar is not even implemented 03:15:16 what do you get out of the program? 03:15:25 then there is the M100 stuff 03:15:33 wo where does that leave it? 03:15:41 if there are errors, it reports them 03:15:48 ok 03:15:48 it doesn't do anything else yet 03:15:53 otherwise nothing- got it 03:15:58 can I see the source? 03:16:09 sure, you guys all want a copy? 03:16:45 heh - deafening silence ;) 03:16:58 yeah, I guess that means no 03:18:43 ok, just sent you a tarball, including my slickEdit project file ;-) 03:18:58 ooooohh - slickedit 03:19:05 too bad I don't have that ;) 03:19:07 yeah, I like it in vi mode 03:19:27 ok - it didn't spit out any errors on a 1.6M NC file I have 03:19:32 if you want to build the source, you will need to apt-get antlr and libantlr-dev 03:19:45 you can also use it command line to test stuff 03:19:47 (though it is significantly slower on the 500 MHz celeron than on the 1.4GHz Opteron 03:19:52 1.6GHz, that is 03:20:04 It's compiled with debug for testing 03:20:17 maybe optimization will make a difference 03:20:29 how does the current EMC compare between the two machines? 03:20:52 unknown - I only have it in VMWare on the big machine 03:21:00 it's a top down LL(1) parser and top down LL(2) scanner 03:21:16 and it uses bit sets for lexing and parsing 03:21:23 should be pretty decent 03:21:23 pardon me while I go get all my textbooks ;) 03:21:38 and the code really follows the grammar since it's top down 03:21:42 I haven't used any of this stuff in ages 03:21:49 you can pretty much jump in at any rule 03:22:01 yeah, I had to brush up a bit too 03:22:17 did you get the source? 03:23:16 I did 03:23:39 ok - so the version of rs274ngc with the source is a debug compile, and the other isn't? 03:23:45 if you install the antlr packages and run make, you will see the cpp code 03:24:02 no, the one I sent you was debug too 03:24:17 I added the ngc to indicate which flavor of 274 it was 03:24:22 hm - they're different sizes, by over 1M 03:24:22 that's what NIST called it 03:24:30 hmm 03:24:40 the first was 879K, the second is 2M 03:24:43 maybe the one didn't have symbols 03:25:05 ok 03:25:06 neither were optimized 03:25:52 hm - why is the Makefile executable? 03:26:00 among others... 03:26:06 oh, it's a samba/windows thing 03:26:15 ah - OK 03:26:19 any time I write a file from doze, it's +x 03:26:24 I need to fix that 03:26:44 ok - I didn't realize that you had done it on a windows machine 03:26:59 my IDE (slickEdit) is doze based 03:27:05 cooties 03:27:13 I thought they had a Linux version 03:27:16 I'm compiling on the linux box 03:27:24 ;-) 03:27:24 they might, but I don't have it 03:27:35 I should try eclipse 03:27:44 just too used to slickEdit 03:27:46 I talked to them at Embedded Systems in SF 03:27:55 was it good? 03:28:26 SWPadnos has joined #emc-devel 03:28:43 maybe, but their website java just crashed my other machine 03:28:52 yuk 03:29:02 can't ecen ping it 03:29:04 even 03:30:10 OK - it was them - they have versions for win, lin, irix, aix, solaris, mac, and HP-UX 03:31:21 dang, I changed the samba umask and sent HUP to daemons, but still setting +x 03:32:07 oh well, maybe it will work after a reboot 03:36:41 SWPadnos_ has quit 03:36:57 SWPadnos_ has joined #emc-devel 03:37:16 well - that was exciting 03:37:26 what happened? 03:37:46 I clicked on a menu item onthe slickedit website, and the machine locked up hard 03:37:54 didn't even respond to pings 03:38:00 ooh, that's not good 03:38:13 that shouldn't happen from just the browser 03:38:30 maybe you need to do a clean install of 4.30 as well 03:38:39 starting to sound like my old install 03:38:40 nope - I think there's a problem with the Java installation on this machine - possibly a 32/64 bit interaction 03:38:47 hmm 03:38:49 this isn't a BDI at all 03:38:51 I hate java 03:38:58 it's a dual-processor opteron 03:39:02 too many non-compatible options for linux 03:39:06 the problem is with the website - too much crap 03:39:21 that too, but I agree that the crap shouldn't crash the OS 03:39:56 so, did you look at the grammar? 03:40:18 no - the machine crashed ;) 03:40:22 ahh 03:40:43 so I rebooted, and decided to take a shit :) 03:40:47 what is the goal for lines/sec on what speed machine? 03:40:51 nice 03:40:55 thanks 03:40:58 I feel better 03:41:27 well - there are some pathological cases that I think would be good to use for setting goals 03:41:45 on my 1GHz C3 (which is about a 600MHz celeron), I get about 4700/sec with debug code 03:43:11 what's the typical rate for the TP in EMC now? 03:43:40 is there any point to sending down more than one canonical motion command per TP cycle? 03:44:02 that's not a me question - I can never keep straight what's at the servo rate vs. the task rate vs. the (etc etc) rate 03:44:17 jmk, you there? 03:44:35 no, but Les has had problems with high speed planning, and he's not even at "HSM" speeds 03:44:46 what is high speed? 03:45:00 one sec - I'll send you a link 03:45:04 ok 03:45:21 http://www.datrondynamics.com/products.htm 03:45:33 watch the videos of the MiniRaptor 03:45:49 or the VelociRaptor 03:46:01 where are you looking? 03:46:15 there's a table about a screen down 03:46:54 where are the videos? 03:47:02 one sec 03:47:27 http://www.datrondynamics.com/VideoZone/Videos340kb/HighSpeedH.wmv 03:47:35 the velociRapto is 1,000"/min 03:47:47 yes - cutting speed 03:48:11 can it rapid faster? 03:48:18 I think so 03:48:45 but nonetheless, 1000 in/min is pretty fast for machining 03:49:17 I like the way the coolant is going on/off 03:49:25 yep 03:49:34 what kind of cutter it that, looks tapered 03:49:40 it's a pretty damned slick $35k machine 03:49:46 yeah 03:50:06 the spindle speed is crazy 03:50:58 the whole machine is a bit crazy 03:51:13 is it mostly for Al and softer? 03:51:23 the thing about HSM is that at some high speed, the chips start taking the heat away for you - they become the coolant 03:51:43 I think that's true even at low speed 03:51:47 I don't think so 03:51:55 the cutters are designed to heat the material, not themselves 03:52:06 well - at low speed, they hang onto the work or the tool long enough to transfer heat away 03:52:10 at least that's what the cutter mfgs claim 03:52:29 yes - well, they would say that ;) 03:52:42 so is this what les was trying to acheive? 03:52:52 not that fast, but yes 03:53:05 how many TP cycles/sec to you think are needed for 1000ipm? 03:53:15 he has a big machine with a lot of mass and power, and wants to machine at 400-600 IPM, I think he said 03:53:24 that's about 17 "/sec 03:53:38 well - again being pathological, consider a CAM post that outputs line segments instead of arcs 03:53:49 sure, that's worst case 03:54:08 and you want .003 max deviation (or even better) 03:54:13 sure 03:54:37 you're at around 300-350 * 17 lines/sec 03:54:47 how do you get that? 03:54:59 what's the min radius a machine could run at that speed? 03:55:21 well - 17 inches/sec / 0.003 arc segments (though that's not necessarily the max deviation) 03:55:28 the segments may be longer 03:55:39 1/0.003 is 333 03:55:42 seems like you need the min radius, then figure the coord for 0.003 error 03:56:08 I'm just getting an approximation 03:56:18 yeah, but it seems way off 03:56:29 heh - approximate ;) 03:56:39 your radius would be tiny for a move that small to have 0.003 03:56:59 approximate would be nice if it wasn't a few orders of mag off ;-) 03:57:14 but 4700l/sec is definitely fast enough anyway, since it's in the ballpark of the worst -case incorrect approximation ;) 03:57:42 yeah, but the machine has to run the TP and servo too 03:57:46 that was just for the interp 03:57:56 sure 03:57:59 I can get it faster with optimized code 03:58:05 but it's a good start 03:58:16 well - that's what the extra orders of magnitude are for ;) 03:58:42 so, does it make any sense to send more than one canonical motion per TP cycle? 03:59:16 out of my league at the moment, I'm afraid 03:59:35 ok, I don't think it does, as how would it get processed? 03:59:38 but yes, I think so 03:59:49 can the TP process mulitple points per iteration? 03:59:59 I guess that's what we need to know 04:00:03 I don't think so now, but it should 04:00:07 yep 04:00:20 put it on the list for jmk ;-) 04:00:28 there was discussion of sending splines to the planner as well, so there could be more information transferred per cycle 04:01:04 yeah, did you follow any of the eliptical motion stuff? 04:01:28 how would that be ot help? would it get implemented at the servo rate? 04:01:33 sounds ugly to me 04:01:55 I was following, and I think ellipses are an excellent idea 04:02:08 so how would they work? 04:02:15 that's the hard part 04:02:19 I can see it at a high level, but not in motion 04:02:27 to get axis-aligned ones is easy, but off-axis would be a pain 04:02:44 oh - ellipses are easy, even in integer math 04:02:48 I don't think it makes sense at the low level 04:03:05 you would have to put it in the servo thread for it to help 04:03:21 just calculate a circle, and scale the minor axis down by b/a 04:03:23 right now the servo gets all lines, doesn't it? 04:03:33 no - the planner gets circles 04:03:41 yeah, but PID, and everything else don't understand that 04:03:46 actually - the call is an ellipse in the emc source 04:03:49 right, the TP gets it 04:03:57 and makes a list of points for servo 04:04:05 PID only understands commanded position, and it doesn't matter how the command is calculated 04:04:10 yes 04:04:20 so at the motion level, it's all small lines 04:04:43 yes - it will end up being that way, but only because of discrete time quantization 04:04:52 so the only gain is if there it a bottleneck to the TP 04:04:59 it/is 04:05:07 if you could get the servo or TP rate to 1 microsecond, you'd have a smoother circle 04:05:19 no 04:05:29 yes, but I think doing more than lines at servo is a bad idea 04:05:31 well - maybe 04:05:47 I don't think so 04:05:52 why? 04:06:06 consider what happens if a line needs to end in the middle of a servo period 04:06:18 you want PID positions to be adjusted by the servo thread? 04:06:26 PID has nothing to do with it 04:06:41 they're at different levels 04:06:45 I think that's ugly, if you want stuff to end in the middle of a period, run it faster 04:06:56 motion gives PID the position command 04:07:05 (and I don't fully understand how they're put together, so I think I shouldn't try to explain it ;) ) 04:07:10 if it doesn't adjust at servo rate, then it's just a line 04:07:27 we need jmk 04:07:32 who me? 04:07:35 yes 04:07:45 no - if I command a move of 0.0035 inches, and the speed is 60 IPM, I shouldn't have to double the servo rate to get it 04:07:58 can you explain why you would want eliptical motion if there is no bottle neck to TP 04:08:06 (60IPM = 1 IPS = 0.001/ms) 04:08:18 if you command a move of 0.0035 inches, what you get depends on the moves that precede and follow it 04:08:28 right 04:08:43 it blends 3 points, no? 04:08:45 do moves have to start and end on a TP cycle? 04:08:53 they shouldn't 04:08:56 (ie, at the edge of a cycle) 04:09:01 no, servo cycle I would think 04:09:10 no, they shouldn't 04:09:27 shouldn't on servo or TP? 04:09:36 let me throw out a thought experiment, ok? 04:09:45 first assume absolutely no time quantization 04:09:45 if the velocity is updated on servo, then they have to send on servo, correct? 04:09:55 uhh, how 04:10:06 let me finish - this is a thought experiment 04:10:07 think math - continuous time 04:10:12 ok 04:10:43 with no time quantizaiton, you can calculate exactly when each segment should start and end, and you could also have closed form functions for position as a function of time 04:10:57 ok 04:11:14 those functions would have discontinuous slopes (velocities) if you don't do blending, but we don't care yet 04:11:25 ok 04:11:34 now, take that position(t), and call it a signal (just use one axis, say X) 04:11:45 ok 04:11:57 still continuous time, pass that signal thru a lowpass filter 04:12:05 ok 04:12:18 make the bandwidth of the filter be 500Hz 04:12:36 now you can sample the signal at 1KHz (nyquist) and do whatever you want with it in discrete time 04:12:47 the filter got rid of the high frequency stuff 04:13:00 well, are you saying the bandwidth of the machine is much lower than of the control? 04:13:05 this I see 04:13:06 because as soon as you go to sampling, you simply cannot pass high frequency stuff 04:13:11 yes, that too 04:13:18 but machine dependent 04:13:21 yes 04:13:24 let's assume the machine is infinite bandwidth 04:13:30 I don't see that 04:13:43 if PID is converting position error to velocity 04:13:45 don't see what? 04:14:00 how can velocity go to 0 in between a servo period 04:14:01 the VelociRaptor has higher bandwidth than a Bridgeport with 20 oz-in steppers 04:14:10 forget that 04:14:11 heh 04:14:38 if velocity only changes on servo period, how can it go to 0 at other times? 04:14:43 it can't, at the moment 04:15:04 so then motion has to end on a servo period, unless we consider machine bandwidth 04:15:14 true? 04:15:20 no 04:15:23 motion has to end on a servo period because of machine bandwidth 04:15:34 (emc machine) 04:15:41 well, real motion must start/emd on a servo period 04:15:49 no, assume the machine bandwidth is infinite, with infinite acceleration 04:15:57 but remember, real motion is a low-pass filtered version of the ideal path 04:15:58 emc machine == pc 04:16:14 no, I meant machine == iron 04:16:17 the ideal path can have bends at any time, not just servo time 04:16:19 motors, etc. 04:16:39 right - the fact that emc can't make changes to motion inside a servo period is what makes it a low pass filter 04:16:40 quite an assumption, but OK 04:16:42 jmk: with infinite machine bandwidth? 04:17:21 so what have we agreed to? 04:17:31 I don't know 04:17:35 that it's the low pass of the iron, motors, etc.? 04:17:48 that is one lowpass 04:17:49 if that weren't the case, could motion end between a servo period? 04:18:02 yo uhave an ideal signal with infinite bandwidth, you pass it through the controller (emc) which has a finite bandwidth, and then on to the machine, which should have even lower bandwidth 04:18:10 the iron "filter" is the dominant pole in the system 04:18:16 yes 04:18:30 if the iron hads more bandwidth than the controller, then you need a faster controller 04:18:34 if the pole caused by the servo rate is lower than the iron pole, then you should raise the servo rate until it isnt 04:18:40 swp: exactly 04:19:12 woohoo - we agree (I think) 04:19:15 but for any but the most exotic machines, the iron bandwidth is in the 10s of Hz 04:19:16 so, that being the case, why do we want to deal with more than linear moves at the servo rate? 04:19:32 why not just up the TP rate so we can keep division of labor clean? 04:19:44 I must of missed something 04:19:57 we started with the request for eliptical commands 04:19:59 I never suggested that you would want more than linear moves at the servo rate 04:20:11 and I didn't see any value unless there was a bottle neck to the TP 04:20:23 I did, but it's probably my lack of understanding / mental block on al lthe different rates in emc 04:20:35 swp: suggested eliptical moves at servo rate 04:20:46 at TP rate, I think I meant 04:20:49 well part of the value has absolutely nothing to do with rates 04:20:58 I see value in the GUI 04:21:05 but not at the lower levels 04:21:07 but not by calculating 100 short moves every TP cucle 04:21:09 cycle 04:21:20 its also lookahead 04:21:37 take skunkworks machine 04:21:48 he has a maxV of 300ipm, 5ips 04:21:52 if the TP gets fixed so that it can process multiple point per period, then arent arcs and lines enough? 04:21:52 and a max accel of 1 ips 04:22:10 that's the thing - the path shape is calculated at the servo rate, but the shape is decided at the TP rate (more or less) 04:22:18 so if he's scooting along at 5ips, he needs to start slowing down 5 seconds before a right angle turn 04:22:44 ok 04:22:54 if he does a 40 inch straight line as a single move, no problem 04:23:12 but what if he does it as 1000 moves that are .040 long each 04:23:35 I don't follow 04:23:45 (all parallel to each other, followed by another line off at right angles to the rest) 04:23:46 wont the TP just blend them and get the same result? 04:24:02 how far ahead can the TP look? 04:24:08 ah, so there is the look ahead issue 04:24:11 today, it blends adjacent moves only 04:24:19 ok, that sucks 04:24:43 if it sees 500 parallel lines, it doesn't know that number 501 is a right angle turn and it needs to slow down when it gets to number 150 in order to make the turn 04:24:43 so what are some of the proposed solutions? 04:24:54 yep 04:25:04 that's partly due to the fact that it can only accept one move per cycle though, isn't it? 04:25:09 obviously some form of deep lookahead 04:25:28 partly 04:25:29 fwiw, that's already written but buggy 04:25:34 I take that back 04:25:48 I think paul started that at Fest or at Les' place, right? 04:25:50 the "accept one move per cycle" is a different issue 04:26:03 I'm not sure which one paul attacked 04:26:04 that's the buffer prob, right? 04:26:09 or how successfull he was 04:26:21 "the" buffer problem - an optimist ;) 04:26:36 right now I thought we couldn't send more than one motion command per TP cycle 04:26:41 I just gave you the "lookahead" pathological case 04:26:46 now heres the buffer one: 04:26:49 the only way it gets more points is from an arc, no? 04:26:50 h 04:26:52 heh 04:27:04 straight parallel moves, no right angle turn at the end, no need for lookahead 04:27:11 ok 04:27:14 collinear 04:27:17 but the programmer decided to programm 0.0005" segments 04:27:38 well, that's just plain stupid 04:27:40 at 5ips, you gotta feed 10,000 of them to the interp 04:27:45 yep 04:27:50 I said patholocgal 04:27:57 that's CAM - great, but sometimes stupid 04:28:01 now assume he's milling a smooth curve 04:28:12 they're not quite collinear 04:28:22 yep 04:28:26 but still close enough that there is no need to slow down at the junctions 04:28:33 ok 04:29:01 so he programs a lot of em, cause he wants to track that curve really well 04:29:22 well should depend on the radius of the curve 04:29:40 petev: you'd be surprised at the crap paths that come out of cam software 04:29:46 yep 04:29:51 not mine ;-) 04:30:23 just look at a DXF where they used lines instead of curves (or text) 04:30:26 heh, mine's pretty bad 04:30:27 another way of looking at this goes back to my "signals and bandwidth" approach 04:30:32 DXF is not CAM 04:30:50 another thought experiment: 04:30:53 no, but the idea of linear approximations of curves is similar 04:31:01 suppose you have a 1" diameter circle 04:31:07 ok 04:31:12 circumference 6.28" 04:31:17 yep 04:31:22 assume a milling speed of 6.28" per second 04:31:26 ok 04:31:28 so you mill the circle in 1 second 04:31:32 yep 04:31:42 and assume you want to just keep going around and around, no entry or exit 04:31:51 ok 04:31:52 so X and Y position are 1Hz sinewaves 04:32:02 ep 04:32:03 not a lot of bandwidth needed there, is there? 04:32:07 no 04:32:19 except... 04:32:20 now approximate the circle as a square 04:32:35 ok 04:32:53 now X and Y positions are flat, then linear down, then flat, then linear up 04:32:57 infinite bandwidth needed 04:33:00 yep 04:33:03 now what is the bandwidth? 04:33:06 infinite bandwidth needed 04:33:46 adding more segments reduces the magnitude of the high frequency componets (because there is a smaller change in velocity at each point) but increases the frequency (more per circle) 04:34:04 ok 04:34:11 I'm still stuck back on the 1" diameter circle with 6.28" circumference 04:34:20 heh 04:34:23 2*PI*D 04:34:30 2*pi*r 04:34:39 petev: not where I come from! 04:34:40 oops, my bad 04:34:45 oops 04:34:53 sorry, it's irrelevant but I thought it was funny that you all let it past 04:35:14 I did that on purpose, to see if you were awake! 04:35:14 it was just an experiment 04:35:21 (yeah, right) 04:35:23 if tested, we would have revised the theory 04:35:51 goodnight guys... 04:35:55 I forgot where I was going with that (if I ever knew) 04:35:56 I think you did it to see if you were awake ;) 04:35:58 godnight 04:36:01 night 04:36:08 gnight 04:36:22 it keeps coming down to bandwidth 04:36:35 suppose you actually wanted to make an octagon, not a circle 04:36:39 as you decrease the number of samples, you increase the amount of information you need to convey per sample 04:37:03 true 04:37:04 ok, so relate this to the eliptical motion, I'm not seeing it 04:37:38 what is the ideal number of segments to break an elipse or other smooth curve into? 04:37:59 hmm, trade of error for bw 04:38:02 of/off 04:38:07 (trick question) 04:38:21 any time you have a non-linear motion, you would need (servo_rate) lines of G-code per second to get the same precision that just sending an ellipse to the servo controller would do 04:38:41 or the appropriate curve 04:38:48 ideally, you have a mathematical representation of the path, and you sample it at the servo rate 04:38:51 swp: but you are mixing division of work 04:39:05 jmk: yes 04:39:11 essentially, the "ideal number of segments" is one per servo period 04:39:12 no - the servo controller already does the sampling 04:39:33 the PID is also done at the same rate, though it could be different 04:39:45 so, why not just have the TP give a queue of points to the servo thread? 04:39:47 ignore PID 04:39:56 we're trying to make a signal called Xposition 04:39:58 it can calcualte them in batches 04:40:10 because you'd have to send 1000 commands per second, every second, if you aren't doing straight lines 04:40:11 we need to bandwidth limit that signal, so the PID (and the machine) can follow it 04:40:17 yes, queues of pose for servo 04:40:58 pete: what you are talking about is the essence of trajectory planning 04:41:07 taking a continuous path and sampling it 04:41:09 kinda 04:41:26 but why not change the position command to PID on each cycle it needed? 04:41:39 follow an arbutray shape 04:41:43 arbitrary 04:41:45 PID and position command are two different things 04:41:52 but you are talking about sending that "continuous" path to the trajectory planner as a series of segments 04:41:58 IE, already sampled 04:41:59 PID takes position command 04:42:08 jmk:yes 04:42:27 could handle the sample part by sayinng what servo cycle to update on for lines 04:42:36 that would save queue mem 04:42:38 right - and also takes feedback, and mixes it all up to get a velocity command (or torque, etc) 04:42:39 but the sampling in the g-code file is almost certainly wrong for the servo rate 04:42:51 hold on a sec - consider this: 04:42:54 swp: forget about PID, and velocity, and torque, and all that 04:43:07 no, TP busts it up and makes a queue for servo 04:43:10 that is trivial signal processing, it can be characterized with a bode plot or whatever 04:43:34 that was my point - it has nothing to do with position commands from the planner or the servo loop 04:43:49 swp: assume the PID is perfect 04:43:53 (except that it's calculated at the same rate, in the servo loop) 04:43:58 the position commands out of the planner are the signal we care about 04:44:01 roght - so - think about this: 04:44:05 we need a new position each servo cycle for optimum performance 04:44:22 we need a new position each servo cycle, period 04:44:26 given an elliptical path (or circular or whatever), emc will need to calculate N line segments 04:44:38 N is the servo rate * the total time for the move 04:44:39 yes, but now it's the same position until the TP runs again 04:44:50 ? 04:45:01 you mean because the TP runs slower than the servo rate? 04:45:05 yes 04:45:21 why is it better to calculate a million of them at once, and transfer a million commands, rather than calculating them on the fly from a single command? 04:45:23 I'm saying let the TP calc poses for the servo rate in batches 04:45:37 first, I consider that a distraction... nowhere is it written in stone that the TP needs to run slower than servo 04:45:50 that was a NIST decision, driven in part by CPU horsepower limits 04:46:02 but CPU limits are real 04:46:09 we need a real solution 04:46:35 I'll ask again - given that there will *always* be a new position command every servo period (even if it's the same as the last one), 04:46:37 second, there is an interpolater that does cubic splines between the TP output points, generating intermediate positions at the servo rate 04:46:37 why is it better to calculate a million of them at once, and transfer a million commands, rather than calculating them on the fly from a single command? 04:47:29 swp: first, why limit the shape with formulas in the servo thread 04:47:44 second, the servo thread needs to be tight to limit jitter 04:47:49 to avoid "resampling" 04:48:11 I'd ask that the other way around - why limit the formulas that the servo thread can handle? 04:48:11 breaking a shape up into short segments is a form of sampling 04:48:33 sure - it all depends on having an efficient calculator, but you need that anyway 04:48:33 aren't we always sampled at the servo rate? 04:48:44 but that sampling rate is almost never gonna match the sampling rate that you need at the servo stage 04:48:48 somebody calcs the position 04:49:24 I don't follow, TP knows the servo rate, why can't it calculate pionts for each servo period based on whatever blending and Q them 04:49:25 pete: if you tell me to do a circle by drawing 500 straight lines, you have sampled that circle 04:49:33 yes - you need blending as well, and that shouldn't be in the servo calc 04:49:39 yes 04:49:53 pete: the cubic interpolator does what you are talking about 04:50:02 the TP generates points at the TP rate 04:50:04 if your CAM program outputs a series of line segments that take 1.3 servo periods each, there's a problem 04:50:07 jmk: I don't see how motion is changed between servo periods, so it's always sampled 04:50:26 jmk: I know, I was considering a change to get better performance 04:50:30 I think we're having at least three conversations at the same time 04:50:36 heh - one each ;) 04:50:38 ok, you lead 04:50:46 that won't help 04:50:59 not if I'm not talking about the same subject you are 04:51:03 (and I think I'm not) 04:51:20 the original (ish) question was about having ellipse commands in the interp, and how the ellipses get doen to the motors 04:51:27 ok, I'm still on the value of eliptical commands 04:51:29 down 04:51:47 command as in G-code, or command as in TP->servo? 04:51:53 ok, lets try this tack... 04:52:00 the guy wants an elipse 04:52:04 ok 04:52:14 one approach is to tell his cam program he wants an elipse 04:52:22 (if he has one) 04:52:22 and let the program generate a bunch of straight lines 04:52:33 right? 04:52:39 ok, we all agree that sucks, correct? 04:52:43 that's one way, yes 04:52:47 at that point, he has sampled that elipse 04:52:55 yes, at the wrong rate 04:52:59 most likely 04:53:06 right 04:53:29 thats why an elipse command is good - you can send it to the trajectory planner and let the TP sample it at the right rate 04:53:41 so when you run that program, you'll get a machine that jerks all over the place, and gives you an approximation of the approximation of an ellipse 04:53:47 yes, but we were debating how far down it had to go 04:53:55 heh, exactly swo 04:53:57 swp 04:53:58 the command that is 04:54:04 ok - so command = TP->servo 04:54:17 not G6 or whatever 04:54:28 swp: thinks elipse goes to servo 04:54:36 I think to TP with poses for servo 04:54:46 I'm asking what you mean by "an ellipse command" 04:54:46 we might be using the term servo loosly 04:55:10 swp: a new g-code or whatever 04:55:34 ok - I think the value of that is obvious, from the sampling point of view that jmk brought up 04:55:42 yes 04:55:50 to me, "servo" is the block(s) that are responsible for making the machine follow a sampled position command (a signal) 04:55:54 it's also a hell of a lot easier for one-offs at the machine 04:56:04 servo never sees "commands", it only sees signals 04:56:10 jmk: i think of servo as the PID rate 04:56:17 yes - that's the hardware view of servo ;) 04:56:20 exactly 04:56:32 it sees a position to go to 04:56:33 servo period and servo are two differnet things 04:56:43 not formulas to calc the position 04:56:47 ok by me, so servo should be totally out of this discussion 04:56:58 ok, so servo period 04:57:03 servo period is the sample rate of the position stream 04:57:07 yes 04:57:09 right - except that the shape sampler also runs at the servo rate 04:57:15 yep 04:57:24 shape sampler? 04:57:29 do you mean TP? 04:57:36 to me, "TP" is the blocks that turn a mathematical path into a sampled stream of positions 04:57:38 it runs slower now 04:57:46 jmk: yes 04:57:50 that is for historical reasons only 04:57:56 no - I mean the thing that quantizes the expected path into straight lines for the servo loop to follow 04:58:08 or consecutive positions, if you prefer 04:58:12 swp: that's the TP AFAIK 04:58:18 and I prefer to think of the EMC "TP" and consisting of both the slow planner (TP rate) and the interpolator (servo rate) 04:58:37 the input to that overall TP is commands, and the output is sampled position 04:58:50 agreed 04:59:04 ok I thought the TP in emc was the part that blends successive paths 04:59:12 the EMC one happens to accomplish that in two stages, first the main TP samples at a low rate, then the interplator resamples faster 04:59:17 no, that's the interpolator 04:59:39 opposite, I think - interpolator goes faster (jmk?) 04:59:53 I agree with JMK 05:00:07 TP is slower 05:00:20 what the EMC folks call blending is done by the slow TP 05:00:21 ok - interpolator is at servo rate, planner / blender goes slower (so far) 05:00:34 although the effect of the interpolator is to blend some more 05:00:43 ok, now I'm confused 05:00:48 since it uses cubic splines 05:00:51 also dependent on the machine mode 05:01:02 exact stop etc 05:01:03 actually no, the interpolator isn't 05:01:08 thats the main TP 05:01:21 yes - sorry - we were typing at the same time, I think 05:01:40 heh 05:01:53 I'll shut up - jmk knows what he';s talking about (more than me, at any rate ;) ) 05:02:00 anyway, the output of the main TP is not a series of straight lines... 05:02:13 it is a series of points, but they get connected not by lines, but by splines 05:02:29 the interpolator does the splines part 05:02:43 ok, so where is the blending in the TP then? 05:02:52 on a longer time scale 05:02:56 ahh 05:03:03 lets do a simple examppe 05:03:14 G1 is rapid, right? 05:03:20 G0 05:03:27 ok, so G1 uses feed 05:03:27 blending has to do with G-codes or canonical commands, interpolating is sampling the blended path 05:03:27 I'm awake ;-) 05:03:36 heres our program 05:03:40 start at 0,0,0 05:03:52 G1 F60 X1 05:03:56 G1 F30 X2 05:04:00 done 05:04:14 y and z never move 05:04:19 yep 05:04:43 X must accel to 60ipm, then when it gets close to 1.0, it decels to 30ipm, then continues to 2.0 and decels to a stop 05:04:48 without blending, it does this: 05:05:14 accel to 60, cruise at 60, decel to 0 at 1.0, accel to 30, cruise at 30, decel to 0 at 2.0 05:05:22 with blending it does this: 05:05:47 accel to 60, cruise at 60, decel to 30, cruise at 30, decel to 0 at 2.0 05:05:55 ok 05:06:10 the decel from 60 to 30 is split, so half happens before reaching 1.0, and the other half after 05:06:14 and interpolation does nothing here 05:06:14 speed at 1.0 is 45 05:06:43 if the accel limits are low, the actual ramping may take many servo (in fact many TP) cycles 05:07:19 ok, so the TP is blending velocity, and the interpolator is blending position? 05:07:54 the tp is blending commands (lines and arcs) 05:08:08 and the interpolator is blending between subsequent TP positions 05:08:15 lines and arcs at a given path speed 05:08:18 but it's blending the velocity of the commands, or the position too? 05:08:44 they aren't independent 05:08:53 velocity = dP/dt 05:08:56 elaborate 05:08:59 yes 05:09:36 you could draw the ideal path on paper as velocities, then integrate to get position 05:09:42 ok, one sec 05:09:55 to clarify, what is the output of the TP? 05:10:03 is it a position and velocity? 05:10:15 poses (postions) at the TP rate 05:10:30 does a pose include velocity or not? 05:10:31 velocity is implied, by the differnece between successive samples 05:10:34 no 05:10:36 ok 05:10:49 so how does the TP blend the velocity in your example? 05:11:03 the interpolator did it then? 05:11:03 the commands into the TP did include velocity 05:11:09 yes 05:11:22 damn, I need paper again 05:11:26 ahh, so velocity at the TP sample rate 05:11:30 I got it 05:12:08 heh - we need to get you a smartboard 05:12:19 that would be cool 05:12:24 isn't there some website where you can sketch? 05:12:39 didn't MS net meeting have that? 05:12:44 there are probably collaboration programs that would let you 05:12:49 yes it did 05:13:24 ok, so many TP cycles per g-code, blends both position and velocity 05:13:38 velocity implied by position at TP rate 05:13:42 correct? 05:14:08 I guess 05:14:20 I'm asking 05:14:26 velocity coming out of the TP is implied by the distance between successive samples 05:14:31 yes 05:14:38 velocity going in is embedded in the commands 05:14:42 yes 05:14:48 we agree 05:14:50 "line from here, to there, this fast" 05:14:54 yes 05:15:07 going in, there is no knowledge about how long it will take 05:15:21 the part I wasn't clear on was that the pose out of the TP were assumes to be at each TP period 05:15:24 I got it now 05:15:29 (and in fact, that can change on the fly, thanks to feedrate override) 05:15:55 right - I knew ther ewas a problem with precalculation - I just couldn't remember it 05:16:07 hmm, so what if the TP gets too far ahead? 05:16:24 and the op changes feed override 05:16:26 right - it gets messy 05:16:31 yuk 05:16:41 the TP needs to redo all those queued poses 05:16:56 there are actually ways to precalc it 05:16:58 is that what it does now? 05:17:08 it's the same problem as the CAM program sampling an ellipse for you at the G-code level 05:17:13 no, because now it doesn't do lookahead 05:17:18 oh 05:17:51 heres a concept (no idea if the math is tractable) 05:18:17 given a mathematical representation of a path (either a smooth curve, or a series of straight lines) 05:18:25 one sec 05:18:46 you can work backwards from the end to compute the maximum velocity at any point 05:18:46 if the TP does not look ahead, how does the interpolator get multiple points to blend? 05:18:52 is there a lag? 05:18:54 yes 05:18:59 ok 05:19:20 so that interpolator Q can have the wrong feed rate for a bit then 05:19:37 the lag is only one TP period 05:19:40 typically 10mS 05:19:53 ok 05:19:54 so if you hit feedrate overrride, the actual feed might take 10mS to change 05:19:58 you ain't gonna notice 05:20:17 or start to change if the interpolator is blending many points, no? 05:20:50 the interpolator blends between 2 points, using in addition to those 2, the one that precedes them, and the one that follows 05:20:54 it'll start after one TP period, but take as many as necessary, determined by the machine accel parameters 05:21:05 so at any time there are four points of TP output in storage 05:21:14 call them 0, 1, 2, 3 05:21:29 3 is the newest 05:21:35 ok 05:21:39 the interpolator is moving between 1 and 2 05:21:50 when it hits 2, it asks the TP for 4 05:22:09 then it discards 0, and begins moving between 2 and 3 05:22:25 so it can take several TP cycles for the new velocity to be commanded 05:22:33 but not too many 05:22:35 yes 05:22:38 got it 05:23:10 that lag is probably less than the lag in userspace when you hit the feedrate control 05:23:16 sure 05:23:53 right - those will typically be servo periods, right? 05:24:10 the interp is generating a point (between 2 and 3 for instance) every servo period 05:24:22 right 05:24:35 according to the cubic 05:24:37 ok, but 0-2 , 1-2 etc are every TP cycle? 05:24:37 it evaluates a spline formule 05:24:42 yes 05:24:44 ok 05:25:31 ok, so where does the eliptical move fit in then? still seems like TP to me 05:25:35 the t in spline(t) goes from 0.0 at 1, to 1.0 at 2, then new spline coeffs are computed for the 2 to 3 spline, and t resets to 0.0 again 05:26:01 yes, has nothing to do with the interp 05:26:09 interpolator, not interpreter ;-) 05:26:16 ok 05:26:32 ok - and 0,1,2 are issued at the TP rate, or as necessary (ie, there's a parameter that tells the increment for T every servo period)? 05:26:40 so that would happen at the same place as arcs now 05:26:59 the interpolator increments it's t by the ratio between servo period and TP period 05:27:17 ok - so the poses are issued at exactly one per TP period 05:27:23 for instance, if servo is 1mS, and TP is 10mS, then the interpolator incrementes its t by 0.1 05:27:44 jmk: you lost me 05:27:56 what do you know about splines? 05:27:57 are you saying the cubic is normalized? 05:27:57 servo is the rate the interp(olator) runs 05:28:12 it is normalized in time 05:28:25 so the interpolator uses up one per TP cycle 05:28:37 one pose, that is 05:28:38 the spline is a set of coefficients 05:28:41 sure, I understand if it's normalized 05:28:45 you put 0.0 into it, you get point1 05:28:53 put 1.0 into it, get point 2 05:29:00 got it 05:29:01 for 6 axes 05:29:11 put 0.3 into it, get a point that is 0.3 of the way, along a smooth path between 1 and 2 05:29:24 along a smooth cubic path 05:29:30 ok 05:29:32 yes 05:29:48 so it can already describe an arbitrary quadratic (circle or ellipse), given the right coefficients 05:30:02 when the interpolator gets to 1.0, it generates a new set of cofficients using the next TP pose 05:30:13 a segment on one anyway 05:30:20 s/on/of 05:30:21 yes 05:30:32 ok 05:30:36 you can't describe a complete circle with a spline 05:30:49 no, but a TP portion of one should be easy ;) 05:30:55 TP period 05:30:58 one approach to trajectory planning is to describe everything in terms of splines 05:31:47 it seems that a high enough order spline should do fine for TP period moves and give flexibity to arbitrary move commands 05:31:49 then the RT code is easy 05:32:22 should have put a s in front 05:32:23 the problem is that no spline, no matter how high order, can describe a sharp corner 05:32:40 right, but the machine can't follow that anyhow 05:32:50 so you have to decide how much the spline can deviate from the ideal path 05:33:13 which is speed dependent, so you are right back at not being able to precompute the splines 05:33:51 yep 05:34:08 If you think about it, you see that there is exactly one pose per servo period 05:34:13 if you could precompute splines in user space, that would be wonderfull 05:34:18 but still seems like TP look ahead has value, it just can't generate ahead 05:34:25 and it doesn't matter where that pose is calculated, it still needs to be calculated 05:34:46 swp: but servo rate stuff needs to be tight to reduce sample error 05:35:00 swp: exactly, thats why I consider the "TP" to be the composite of the main TP and the interpolator 05:35:03 so, unless you plan to precalculate the entire program (not practical), you need to have a computer that is capable of calculating at the servo rate 05:35:09 none of the HW can support captures position until we get HAL IRQ threads 05:35:20 captured 05:35:37 swp: you do simple math (spline interpolation) at the servo rate 05:35:49 yes 05:35:53 you do more complex math (main TP and especially kinematics calcs) at the TP rate 05:36:00 yes 05:36:07 yeah, don't forget about kins ;-) 05:36:13 sure 05:36:18 jmk: how much do you think sample jitter is effecting EMC performance now? 05:36:22 that is done on the main TP output, to reduce the CPU load 05:36:26 but there's still exactly one pose per servo period 05:36:31 not enough to matter 05:37:14 so, what improvements can be made then? 05:37:17 yeah - you get 20 us jitter (worst case) on a 1ms period 05:37:26 remember, most noise introduced by jitter is at the servo rate, and it gets filtered out by the frequency response of the PID and iron 05:37:41 swp, servo period is less than 1ms 05:37:53 improve how you tell the lower levels what to do, by reducing the amount of communication overhead (to allow moretime for calculations) 05:38:04 setvo period is typically 1ms 05:38:05 petev: default EMC servo rate is 1mS 05:38:20 I thought that was TP rate, seems slow for servo 05:38:22 can be faster, but I haven't heard of anyone going faster than 5KHz 05:38:26 TP is 10ms 05:38:30 by default 05:38:43 so what's the point of 5K lines/sec of g-code 05:39:04 well - nobody's doing HSM with emc yet - it can't keep up 05:39:12 how about when you restart and need to fast-forward to line 1000000 05:39:12 it would need to be faster for that 05:39:19 that too ;) 05:39:27 jmk: good point, but I like the checkpointing better 05:39:58 how about when you load the file in AXIs, and it runs it in sim mode for the preview plot? 05:40:24 fyi: I'm getting 4700 lines/sec on the 1GHz C3 (which is about 600 MHz celeron) with un-optimized code 05:40:42 what does the standard interp do? 05:40:44 what does axis do when you load it? 05:41:08 it "runs" the entire file to generate the preview toolpath 05:41:08 jmk: not sure 05:41:15 would have to build something to test it 05:41:16 it does 05:41:26 oh 05:41:38 axis runs it through what? 05:41:49 there are million line G-code programs, at 4700 lines/sec, that is 200 seconds to load and display the plot 05:42:12 thru the interp, I think.... it doesn't send the commands to the machine, just notes the position and discards the command 05:42:18 so axis asks the interp to read it, but no exec, then reads back current position? 05:42:20 it runs the planner, but with output disabled (the mode is there for restarting without moving, I think) 05:42:20 (canonical commands) 05:42:47 if that's the case, the current interp is 4 x slower than what I have now, but all the code isn't in yet 05:42:48 right - they pipe the canonical commands back into their program, and make the plot that way 05:43:09 petev: how do you know its 4 times slower? 05:43:12 that includes communication overhead 05:43:34 I load the same program in axis and it takes at least 4x as long 05:43:42 yes, NML overhead too 05:43:57 overhead for comm/NML, and generating the 3D GL objects 05:44:09 and putting them into the display list 05:44:48 true, and right now, I'm reading from the file direct 05:44:58 later, I will read into a buffer for each line 05:45:02 should be much faster 05:45:30 well - it runs a 66000 line file in 4.348 seconds on this machine 05:45:42 axis? 05:45:47 no - your interp 05:45:55 the 879k one 05:45:59 your machine is faster than mine I think 05:46:07 I hope so ;) 05:46:15 I just spent $4000 on it 05:46:19 oh 05:46:27 that beats my $400 05:46:55 (2x opteron, 4G ram, 300G hd, dvd+-rw-DL, Nvidia 7800GT, dual 24" LCDs) 05:47:05 jmk: so what do you see as the major areas to improve? 05:47:57 hm - a little faster for the 2M one (but within the error margin, I bet) 05:48:02 in the area that we've been discussing? 05:48:16 yes, from interp to dac out 05:48:39 I'd like to build a collection of all the pathological cases 05:48:44 short parallel lines 05:48:48 curves made of short lines 05:48:51 etc, etc 05:49:06 then try to architect a TP that doesn't barf all over them 05:49:17 3-D lofted surfaces ... 05:49:33 jmk: what ideas do you have? lookahead? 05:50:07 the idea of computing splines in user space and using those as the RT primitive instead of lines and arcs is attractive 05:50:18 BTW, why can't cubic coeff be calced in the TP each period? 05:50:25 but I haven't studied it deeply enough to know whether it can work 05:51:22 today, the TP takes lines and arcs and generates a series of points 05:51:38 ok, so maybe NURBs to the TP? 05:51:42 then generates the cubic coeffs to interpolate between the points 05:51:46 yes 05:51:59 there was dscussion of NURBS 05:52:06 I'm talking about giving the TP its commands in the form of splines in the first place 05:52:16 yes 05:52:16 also quintics, and others 05:52:24 what about the usr/RT queue for the TP? 05:52:45 I guess if we can pass a whole spline, one per period is ok 05:52:51 that goes pack to lookahead 05:52:53 back 05:53:02 yes, forgot that 05:53:03 that's also stuff that can be precalculated 05:53:12 even if you are passing splines, you still need lookahead of some sort... 05:53:27 precalc in user space is nicer than trying to do it in RT 05:53:27 so we should fix that too so lookahead can be avialbe immediately then? 05:53:38 emc is a bit unique here because it actually uses feedback 05:53:49 not relevant to the TO 05:53:52 I assume a spline will take several TP though, so lookadhead should be available soon 05:53:52 TP 05:54:15 its too late for me to think straight 05:54:18 the other controller programs (DeskCNC, Mach, etc) don't, so they can do 500-point lookahead, and show nice smooth paths 05:54:29 jmk, swp has a good point, what about adaptive control in the TP? 05:54:43 if one axis is getting behind, why not have the TP slow down? 05:54:44 I don't see the connection 05:54:51 but they can't correct for anything on the fly 05:54:57 like feed override, etc 05:55:00 use the position error feedback at the TP level 05:55:05 they can do feed override 05:55:14 the op? 05:55:17 that's too late 05:55:31 why not have the TP do auto feed override based on error? 05:55:48 I don't even want to think about how nasty that would be to tune 05:55:51 sorry - feedback was a red herring - I'm not thining straight either 05:55:58 thinking 05:55:59 especially if you have non-trivial kins 05:56:20 just put a pid loop on it 05:56:27 the thing is, the mentality with the other programs is "set it and forget it" 05:56:36 emc is "set it, then check it" 05:56:45 it would be slick 05:56:50 other programs assume that the motor control section will do what its told 05:56:57 I think our TP should do the same 05:57:00 what about torque/force control on the spindle? 05:57:16 your thinking in the box, let's go outside the box 05:57:21 let's build something better 05:57:48 but you can't precalculate, and retain the ability to do things like feed override (or pause/resume) - you have to recalculate (resample) the segments involved 05:57:57 I can see a slower outer loop that modulates feedrate override (in RT) based on following error (vector sum of all axis probalby) or based on spindle load or something 05:58:05 yes 05:58:18 yep - that's the unstallable stepper thing Mariss has been working on 05:58:24 it's got to be a little faster though 05:58:43 SWP: I would never precalc to the point of sampling 05:58:55 not familiar with what mariss is doing 05:59:08 ok - good :) 05:59:13 to jmk 05:59:24 ok, one other thing 05:59:43 what about feed based on spindle RPM? we need this for rigid tapping and lathe 05:59:50 what are your thoughts? 05:59:52 Mariss is making a mode in the G-Rex that will sense when a stepper isn't able to keep up, and slow down all axes proportionally until it can maintain speed 06:00:01 oh 06:00:13 petev: that topic is good for at least an hour or too 06:00:14 two 06:00:16 I'm not 06:00:22 ok, tomorrow 06:00:31 I gotta crash 06:00:37 gnight 06:00:47 I'd love to make something (a feed wizard) that takes material properties (select Aluminum, 6061-T5), and sets feeds / speeds for that material / tool combination 06:00:53 night jmk 06:00:54 honestly though, that topic is probably the most important we could discuss 06:01:00 ok 06:01:05 and me too I think 06:01:19 swp: my CAM already does that and there are plenty of feed/speed calcs on the net 06:01:20 threading has been on our to-do list for at least 3 years, probably longer 06:01:24 damn - how'd it get to be 2:00 again? 06:01:40 you guys need to move west ;-) 06:01:47 petev: your CAM is more than either $0 or $75, I'd wager 06:01:56 next time we're chatting, lets put our minds on the issue of threading and see what we can come up with 06:01:58 yes, but the calcs from the net are free 06:02:06 jmk: ok 06:02:09 jmkasunich has left #emc-devel 06:02:09 threading - hmmm - my sheets have threads 06:02:27 ok, we have a lot to think about 06:02:37 I understand the motion in EMC better now 06:02:39 yes, and they should be available from within emc - "this is my tool, this is my material, this is the path I want - cut" 06:02:54 maybe 06:02:54 yeah - me, too. 06:03:03 I've had a hard time "getting it" for a long time 06:03:11 that should relaly be done in CAM, but could be nice for conversational 06:03:13 I'll probably forget 90% by tomorrow 06:03:17 yep 06:03:33 let's put it on cradeks feature list ;-) 06:03:33 conversational is where Ken Lerman wants to go - wizards for lots of things 06:03:50 AXIS-ConversationalCAM! 06:03:51 yeah, but I think he's taking the wrong approach 06:03:58 why save g-code space 06:04:05 who cares, HD are cheap 06:04:14 just put a conversational fron end 06:04:18 front 06:04:19 well - people can use the codes as well 06:04:31 yeah, but it make interp stuff ugly 06:04:41 look at the recovery issue with loop 06:04:50 plus the interp will be slower 06:04:58 and there's no standard to boot 06:05:06 sure - but is it easier for somebody to look at a 600 line file to make a dozen holes, or a 50-line subroutine, and a couple dozen commented calls to that sub? 06:05:10 I'm just not convinced 06:05:32 we can support subs as programs 06:05:41 I don't think that's too bad 06:05:45 I think we need to look at as many G-code references as possible, and make a "master reference" for the language and its major variants 06:05:51 but I'm not sold on the loops and conditionals 06:05:58 from that, we can choose what to implement or to not implement 06:06:09 yeah, it's hard to get good data 06:06:19 the most I could find are discussions on forums 06:06:24 no manuals to download 06:06:29 Gene Heskett mentioned that there's a reference in Machinery's Handbook - I'll look through that 06:06:34 ok 06:06:45 eBay, but some of those manuals are expensive 06:06:56 yep 06:06:58 (starts on page 1217, I think) 06:07:06 of the 27th edition 06:07:10 or was it 1279? 06:07:13 I don't have machinery handbook 06:07:30 oh - you should get it - has all the info your CAM hides from you ;) 06:07:37 I have some other books by moltrecht 06:07:51 I look for a copy cheap 06:07:54 I've got to get to bed. we can talk more tomorrow 06:08:01 ok, gnight 06:08:07 SWPadnos_ is now known as SWP_Away 06:08:19 petev has quit 06:50:18 SWPadnos has quit 00:22:10 rayh has joined #emc-devel 00:31:52 rayh_ppmc_usc has joined #emc-devel 00:32:49 IMO this next line in core_servo is just wrong. setp pid.0.maxoutput [AXIS_0]MAX_VELOCITY 00:35:25 Using the variable names from emc it should refer to [AXIS_0]MAX_OUTPUT 01:37:11 alex_joni has joined #emc-devel 01:37:31 morning ray 01:45:31 hi alex phone 01:54:08 Feeling any better? 01:54:23 unfortunately no 01:54:31 a bit worse I think :/ 01:54:43 Oh. That's not good. 01:55:00 but I'm sweating a lot, so I think it's getting out 01:55:11 Is this a stuffy head or just a brain ache? 01:56:05 that was pretty american. let me try again 01:56:14 stuffy head, muscle ache, a bit fever ;) the whole package 01:56:30 running nose, caughing.. 01:56:37 I could go on .. 01:56:48 I get the feeling 01:57:09 I'll not bug you much today. 01:57:16 oh.. but you can 01:57:21 that's nice for a change :) 01:58:39 IMO even if we get only a half dozen sample configurations, I'd like to see them packaged in their own subdirectories. 01:59:06 I agree 01:59:40 but the stuff I had to do to support one single emc.nml was nasty, I don't really like it 02:00:01 fixing default HAL files in configs/ and further .hal files in configs/foo/ is easy 02:00:19 but configs/foo/ needs to hold a .var & .tbl files aswell 02:06:36 In the past, the ini file has been key to finding all of the other files. 02:07:24 Could the ini file use something like ../emc.nml 02:08:53 yes that is one possibility 02:09:05 and it makes a lot of difference in the code needed to support that ;) 03:24:46 alex_joni has quit 04:12:18 rayh_ppmc_usc has quit 04:42:45 rayh: are you still around? 04:42:49 SWP_Away is now known as SWPadnos_ 05:06:17 Hi steve 05:06:39 Working on another pc this morning. 05:06:59 SWPadnos_: how you doing 05:07:11 doing fine 05:07:28 I noticed your comment about [AXIS_0]MAX_OUTPUT 05:07:58 you're probably right, but the values would be different than for emc1, so the users would still need to look at it 05:08:36 default for emc1 was +10 05:08:55 right - it's a "virtual 10V servo driver max output" 05:09:10 in emc2, it's user units / second 05:09:18 that's a direct velocity command to the hardware drvier 05:09:19 max velocity which it is set to now used to default to 1.2 05:09:47 I agree - it's a good idea to have this setting be separate from max_vel 05:10:01 we've been trying to figure out how to make it do that in a clean way 05:10:16 (expressions, fudgefactor parameters, etc) 05:10:31 this is clean, but it isn't directly compatible with the emc1 way of doing things 05:11:59 phone brb 05:12:02 ok 05:20:58 multitasking cause the phone is slow 05:21:54 heh 05:28:07 I don't see the difference between max output on emc1 05:28:18 and this thing that we are trying to set on emc2 05:28:36 I'm between runnables right now but let me try to find it. 05:32:58 rayh_m5i20 has joined #emc-devel 05:33:03 okay 05:33:10 04 float -W 1.20000e+00 pid.0.maxoutput 05:33:30 This is not max velocity is it? 05:34:00 it should be how much output do we need to achieve max vel 05:34:19 It's the range of the output variable? 05:38:56 phone 05:49:26 ok - I'm back (until the phone rings again) 05:50:33 yes - pid.0.maxoutput is the maximum commanded speed that will be output to the hardware, in user units / second 05:52:52 I thought that was what we had to change to 10 in order to make stuff run 05:53:13 nope - it just needs to be a little higher than the axis max_velocity 05:53:31 equal almost works, but a little headroom helps the PID 05:54:03 10 was necessary in emc1 because it was assumed that this was the voltage to output to a servo drive 05:54:07 So how do we tell HAL that we want +- 10 volts 05:54:16 or +- 7 05:54:31 or 0-10 volts 05:54:38 ah - that's where the scale parameter (in the driver) comes into play 05:55:30 note that HAL uses user units for everything, for as long as possible - this is different from emc1, which uses "volts" everywhere for servo output levels 05:55:31 Okay. And this we have to configure in each specific xxx.hal 05:56:00 it's machine specific 05:56:16 But what is the user unit for range of output signals 05:56:25 We don't have volts. 05:56:31 user units per second 05:56:40 No that is not at all right 05:56:53 it's a velocity command to the servo or stepper, so it's a velocity unit 05:57:11 Oh shit] 05:57:14 why? 05:57:19 we are way wrong here. 05:57:35 in what way? 05:58:14 You are telling me that hal can command usc in velocity 05:58:23 yes - that's what it does 05:58:34 Tries to fucking do. 05:58:46 no - does (when properly configured ;) ) 05:58:50 That isn't JonEs work at all 05:59:02 nope - that's JohnK and SWP's work 05:59:17 Jon is expecting a signal that runs from -10 to +10 05:59:31 in emc1, that was true. in emc2, it's not 05:59:52 It is a firmware thing not a version of emc thing 06:00:06 that's why I mentioned that the parameters from emc1 ini files wouldn't be directly compatible 06:00:11 no - it's a driver thing 06:00:26 I don't think so. 06:00:39 the hardware / firmware just gets a rate or pulse width setting from the (software) driver 06:00:58 all scaling is done at the ppmc.x parameter level 06:02:22 shit. 06:02:24 I can tell you exactly what units and scale factors are used, starting at the motion controller, and going to the outputs on the USC 06:02:49 then I guess I'll go for a walk and when I get back call my customer and tell them not to use ppmc 06:02:55 why not? 06:03:11 Cause it ain't gonna tune the way they need. 06:03:35 Sorry not meaning to take this out on you. 06:03:36 the only thing missing is asymmetric limits - going faster in one direction than the other 06:03:49 no trouble - I'm trying to understand why there's a problem 06:04:01 (which I don't yet :( ) 06:04:57 can you explain it to me? 06:05:20 after I recover from this shock maybe. 06:05:58 well - there may not need to be any shock - I think that ppmc is perfectly tunable - just not in the same units as for emc1 06:06:55 (I could say silly psychiatrist things like "explain it to me - let me help you", but that would be silly ;) ) 06:08:20 alex_joni has joined #emc-devel 06:08:39 hello.. 06:08:44 hiya 06:09:08 what's up? 06:09:15 seen a very long talk about TP last night... 06:09:22 heh - yep 06:10:17 nice.. any conclusions? 06:10:33 yeah - nobody understands the TP ;) 06:11:10 petev was wondering why you sould ever want anything other than line segments for the TP, since you can approximate any shape with them 06:11:13 should 06:11:30 yeah.. but that makes blending a problem 06:11:43 not a problem, but you need to be able to do that properly 06:11:51 and segments might be very short 06:11:52 it started with a discussion about whether or not ellipse commands should be there (prompted from the user list discussion) 06:12:00 yeah.. seen that 06:12:06 yeah - and feed override means you have to recalculate all of them 06:12:42 right.. feed override is a pita ;) 06:12:49 itwas on of those "the CAM program should do that for you, so why sorry about it" things 06:13:00 s/on/one/ 06:13:17 only some people's CAM program is notepad 06:13:37 yeah.. or mc ;) 06:13:53 sure - or maybe gedit, or kate ;) 06:16:30 rayh_m5i20 is now known as rayh_ppmc_usc 06:16:40 heh - change of hardware ;) 06:17:37 another mutation? 06:17:39 05 float -W 0.00000e+00 ppmc.0.stepgen.00.max-vel 06:17:39 06:17:50 0 means no user-defined limit 06:18:00 is the only thing that looks to be settable on the ppmc card. 06:18:31 cause scale is pulses per unit 06:19:48 ok - hold on a sec, I'm getting to the code 06:20:56 yes - that's the only limiting thing that gets set at the USC driver level 06:21:33 that should probably be split into two settings - one for forward, one for reverse 06:21:36 And what are the units associated with it 06:21:51 ipm or mmpm 06:21:53 user units per second (velocity) 06:21:55 yes 06:22:32 internally, the input velocity is multiplied by the scale to get the nimber of steps /second to output 06:22:36 number 06:23:14 right. I'm okay with that. 06:23:57 the tuning gets done at the PID block though - this is just a "hard" limit on the maximum pulse rate the driver will allow 06:24:42 I see that. 06:25:19 and it ought to be set to Max_Vel * Scale 06:26:00 what ought to be set to that? the max-vel parameter? 06:26:27 max-vel should be Max_vel 06:26:35 not multiplied with Scale 06:27:03 So we have no way of handling max ppr 06:27:14 scuse pps 06:27:37 internally, the max-vel parameter is multiplied by scale to get the max pps 06:27:53 rayh: what do you plan to do with pps? 06:28:06 hold off a sec alex - this is a continuation of a prior discussion 06:28:11 Right and that is the logical thing to use when you look at stepper motor characteristics 06:28:51 ok - yes, you need to calculate the max velocity from the max step rate 06:29:12 I don't look at velocity when I consider stepper motor and drive characteristics. 06:29:35 how about something in between? 06:29:41 but you need to do that anyway, because at some point, you're going to set the [AXIS_0]MAX_VELOCITY number 06:30:05 having either MAX_VEL or MAX_STEPS in the ini, and the run-script? or hal? takes care of converting one to the other 06:30:09 Well I guess I'll just have to rethink how I tell folk to design a stepper system. 06:30:36 are you thinking of stepper systems that aren't for machininn? 06:30:42 machining 06:30:52 I'm thinking of motion 06:30:56 not machining 06:30:58 ok 06:32:38 I can do that. It just starts at the other end of the design problem. 06:33:15 yeah - with this method, you have to know your final drive ratio and all to get the limit value 06:33:37 but the max step rate (or velocity) will also depend on that anyway 06:33:57 No you have to know all of that before you can begin to look at the stepper motor velocity/torque plots. 06:34:53 what's the design / setup process you want to use? 06:35:07 (or - used to use ;) ) 06:35:10 maybe O meed a ;pmger wa;l. 06:35:40 um - in english? :) 06:35:52 I tend to tell folk you can expect to get about 12 k pps 06:36:10 from a parport 06:36:44 Now go design your axis so that it moves as fast as you want. 06:36:51 or need. 06:37:15 ok - with the USC, the motor and drive system will be the limiting factor 06:38:08 how far can the USC go? as in pulse rate? 06:38:27 depends on the version, but mine can do 2.5 MHz 06:38:43 phone 06:38:47 jmk's is limited to 2 MHz 06:38:53 ok Ray 06:39:30 you can't get encoders that fast, and I'd be really surprised to see any stepper that can keep up, even with pretty fine microstepping 06:40:39 It is not a matter of how fast the usc works 06:40:58 nope - was just answering alex's question 06:41:00 * alex_joni goes back to lurking mode 06:41:26 it sort of is, because the step rate is no longer the limiting factor in designing a stepper system 06:41:30 The problem is that we have a motor that has so much torque at so many pps 06:41:44 and we design from that. 06:42:03 Not from the final velocity of the system. 06:42:39 right - you get teh final velocity by choosing drive ratios etc, based on the performance of the stepper you've chosen 06:43:06 We just have to write the paper that explains this stuff different than we did. 06:43:13 yep. 06:43:46 at its simplest, this method only requires one extra divisoin (max-vel = max_pps / scale) 06:44:10 that calculation would have to be done anyway, so you can set the axis max_velocity in emc.ini 06:44:27 Now at the pid box 06:44:34 ok 06:44:56 there are no percentages? 06:45:11 we just shove commanded vel in 06:45:26 yes, in user units / sec 06:45:38 and get xxx out. 06:45:53 and xxx can not be thought of as +-10 volt 06:46:06 yes, also in velocity (I'm not sure how this magically turns into a torque number, for those kinds of systems) 06:46:19 right - velocity (or magically torque) 06:46:33 hold on a sec - the input to the PID is a position 06:46:40 in user units 06:46:55 okay 06:47:13 the output is a velocity, to correct the current position to match the commanded position 06:47:35 okay 06:47:52 (again - I'm not sure how this works with torque mode, so I'll just leave that out) 06:47:56 alex_joni_ has joined #emc-devel 06:48:09 hmmm.. this is new :/ 06:48:10 No difference in that case. 06:48:26 I guess my Centrino just overheated and shut down :( 06:48:39 bummer 06:48:39 might be the fever and the fact that it's sitting in my lap ;) 06:48:39 oops. 06:48:49 alex_joni has quit 06:48:49 I've done that. 06:48:54 alex_joni_ is now known as alex_joni 06:49:00 I was just going to comment on how lucky you are that your balls didn't get fried 06:49:23 SWPadnos_: it was the other way around :D 06:49:27 heh 06:49:34 I don't want to know ;) 06:49:58 alex has a fever today 06:50:11 he thinks his balls are frying his processor. 06:50:21 yeah - I don't want to know ;) 06:50:43 SWPadnos_: 'image go away' 06:50:47 try that as a mantra 06:50:49 heh 06:51:19 Well at least I can understand why I am having issues with tuning. 06:51:32 heh - that's a good start 06:51:35 oopsy... just came in a mail from ebo 06:51:39 on the devel list 06:51:44 * alex_joni reads now 06:52:14 so, do you have concerns about the PID tuning? 06:52:20 method 06:53:46 yes. 06:53:58 wow that lag was huge 06:54:59 so input to pid is position and output is vel in user units. 06:55:30 * rayh hits his head on the table a few times to pound it in. 06:55:47 rayh: write it on the table first, that does all the difference 06:56:32 Good plan. I've got a permanent marker (sharpie) right here. 06:57:41 heh 06:58:32 Thanks SWPadnos_ 06:58:42 sure - did I help? 06:58:50 gotta run for a bit 06:59:00 ok - see ya around 06:59:10 understanding yes approval for the approach no. 06:59:18 rayh has quit 06:59:20 heh - OK 06:59:47 rayh_ppmc_usc is now known as rayh_away 07:03:26 hm - I don't see any ebo mails... 07:04:43 just one.. on the devel list 07:04:47 about configs 07:05:24 strange - when did it arrive? 07:05:41 20 mins ago 07:05:56 odd - maybe the .ro mail service is vaster than .us 07:06:05 my .ro is in texas :P 07:06:06 faster 07:06:10 heh 07:06:21 just traceroute it ;) 07:07:06 well - I'm looking at the archives on sf (logged in), and it's not there. and I haven't gotten any mail on the devlist sonce Ray's comment in the config thread 07:07:12 since 07:07:24 SF has been odd with emails lately 07:07:31 bummer 07:07:38 rayh_away is now known as rayh_ppmc_usc 07:07:39 yesterday ray's mail took 2 hours before it got to me 07:07:44 I'm back 07:07:49 the one that went through SF 07:07:58 that was fast ;) 07:08:01 rayh_ppmc_usc: talking about bad mailings at SF 07:08:06 They had some real troubles yesterday. 07:08:27 yup, and SWP still reports some 07:08:29 something to do with their server farm 07:08:46 said they'd get the whole new system on line in a few days. 07:08:57 well - we'll see what happens. I think the default retry period is 4 hours 07:09:29 One of the reasons that "we" want computation in halcmd 07:09:44 oh - I think you can drop the quotes there ;) 07:10:01 everyone I've talked to has agreed that they would be good ;) 07:10:06 yeah.. you're safe ... 07:10:10 is so that we can do stuff like (max-vel * 1.1) 07:10:41 exactly -check the logs from last night to see just how much in agreement jmk and I are 07:10:47 Now we know that we always want that so why not in the code itself 07:11:00 in the PID? 07:12:08 Wherever that ceiling is placed on pulserate or pulse read rate 07:12:31 I guess that is max vel again 07:12:35 ok - there are several limits, at different places in the command chain 07:12:55 one is the motion controller - it has a maximum position that it can ask for 07:13:17 next is the PID 07:13:20 then the driver 07:13:49 the driver limit needs to be from the actual machine constraints 07:13:57 (minus some safety factor) 07:14:33 the motion controller should also be clamped to this max safe limit 07:14:38 Well max pos is irrelevant for this kind of thing 07:15:00 sure - motion also uses the max_vel in the TP 07:15:28 so, we have essentially the same number being used in 3 places 07:15:32 SWPadnos_: but sometimes the axis might fall back a bit 07:15:35 motion, PID, and driver limits 07:15:36 all we need is a bit of overhead so that we can return any buildup in following error 07:15:42 then to keep up it will need to go faster 07:15:50 yes, and that has to be in the PID limit, and the driver limit 07:15:55 but not the motion controller limit 07:16:02 and then it might hit the limit.. so maybe the TP limit needs to be a bit lower than PID limit 07:16:14 (so motion limit < driver / pid limit) 07:16:20 yes 07:16:58 actual_motion > driver > pid > tp (in terms of speed) 07:16:59 and since this is IMO always the case, why not allow for it in the pid code. 07:17:09 for testing purposes, you have the flexibility of using just the driver (no PID), and setting the output rate manually 07:17:24 well - the headroom needed is machine-dependent 07:17:31 for testing I can make that allowance 07:17:47 so add a headroom variable 07:17:58 on a closely engineered system, you wouldn't want to go beyond maybe 3-5% headroom 07:18:20 on a deafult install for a hobbyist, you may need 10% 07:18:42 yes - the headroom variable is the pid.0.max-output (though we can't use formulas yet) 07:18:56 Lag is usually caused by accel so I'd think that it would be the other way round. 07:19:24 No pid.0.max-output is exactly that 07:19:50 the headroom is a fudge factor that you want to put in by computation at the hal 07:20:20 well - right now, we can't see the motion limit in HAL 07:20:29 that's directly loaded from the ini 07:20:56 yeah but it could be ([AXIS_0]MAX_VEL * 0.9) 07:21:05 if calculations were supported ;) 07:21:09 yes - if we had formulas 07:21:17 it seems to me that it would be more consistent to make a param named pid.0.headroom 07:21:17 we eventually will have 07:21:39 it may be possible for HAL to compute the proper headroom, but it still needs to know the limit in motion 07:21:43 Then we don't have to edit formulas in hal 07:21:56 it still needs the limit that motion has 07:22:03 so you'd need two pins still 07:22:09 It already has pid.0.max-output 07:22:11 yeah... but that would be a particular fix, not a general one for different situations 07:22:13 doesn't it 07:22:26 yes it does 07:22:34 you'd have to add another pin though 07:22:45 IT is simply one additional pin for the pid loop 07:22:57 I'm not sure that it's better to have two pins (max-output and headroom) 07:23:20 when one pin can suffice, assuming that it can be set with a formula 07:23:56 it would be ideal to have access to the internal parameters of motion 07:24:01 So you gotta tell the integrator, okay open up this hal file and find line 2689 and change the ([AXIS_0]MAX_VEL 0.9) to a ([AXIS_0]MAX_VEL 1.1) 07:24:59 you realize that i'm being the devils advocate here. 07:25:06 no - just the devil ;) 07:25:12 it might be aswell ([AXIS_0]MAXVEL * [AXIS_0]HEADROOM) 07:25:13 Right. 07:25:26 it NEEDS to be in the ini afterall 07:25:52 because probably you don't want a constant in the -hal file going to the pid.0.headroom pin 07:25:53 there needs to be a setting, so the integrator has to open *some* file and go to line 2689 and change something 07:26:53 I'll repeat my mantra: "sane defaults, but user configurable" 07:27:07 SWPadnos_: probably an integrator might beconfortable with editing the INI 07:27:14 or use a Configurator to do that ;) 07:27:27 sure - I have no problem with that 07:27:49 it might be aswell ([AXIS_0]MAXVEL * [AXIS_0]HEADROOM) 07:27:58 could as easily be 07:28:24 ppmc.0.headroom [AXIS_0]HEADROOM) 07:28:32 actually - [AXIS_0]MAX_VELOCITY * (1+ [AXIS_0]HEADROOM) 07:28:42 so if you leave it out, you still egt a max vel ;) 07:28:55 right. 07:29:15 internally to HAL, it doesn't really matter what the setting is 07:29:19 as long as it can be set 07:29:28 or something like 1.5 07:29:46 for default so that no one will ever run out of headroom. 07:29:49 sure - but is that percent, or a multiplication factor? 07:30:17 I would do something similar for the default following error settings also. 07:30:52 but then that's the devil talking 07:30:56 you realize that making PID slower, it will make the overall machine run slower 07:31:13 well - how do you mean? setting them as a fraction of max_vel? 07:31:37 I'd make all of these things percent. 07:31:41 we haven't talked about PIDFF parameters at all. how would it be slower? 07:31:54 not PIDFF, the limiting of PID 07:32:14 this is a final output limit we're talking about - not a slew rate limit 07:32:29 it shouldn't be able to command anything faster than the machine can do anyway 07:32:45 yeah.. but G0 should go at that rate 07:32:57 It it doesn't, then you can not feed following error back in during a rapid. 07:33:15 that's why it's set to [AXIS_0]MAX_VELOCITY 07:33:25 and why we were discussing how to get some extra headroom in there 07:34:15 I got the email, btw 07:35:07 sodi 07:36:04 2 of em in fact. 07:36:25 spaced about 10 minutes apart but carrying the same time stamp. 07:36:37 probably had to go through NRO 07:37:08 or whomever it is that keeps track of my email these days. 07:38:00 incidentally, there's nothing that stops an integrator from making up their own ini settings, like MAXPIDOUT 07:38:12 then making the hal file use [AXIS_0]MAXPIDOUT 07:38:26 yeah if they know that ;) 07:38:36 I only used max_vel because it was there in the default emc.ini 07:38:48 we can add emc2-related stuff to the ini file too 07:39:20 I didn't want to commit any changes to the ini file, just because of thing I had changed that are specific to my machine 07:52:03 Right. I fear for this also 07:52:25 I'm thinking though at we need at least a stock stepper and servo configs 07:52:33 that 07:55:43 yep - Alex and I were discussing that 07:56:11 we were all discussing that 07:56:13 I was thinking of making an emc_servo.ini, and changing the core_servo.hal file to match 07:56:17 I think that's clear to all.. 07:56:26 way ahead of me. I only saw the dust 07:56:31 heh 07:56:48 I can add something like PID_MAX_OUTPUT to the AXIS_n sections 07:56:58 problem is what hardware do we use 07:57:10 okay that handles the problem 07:57:29 the core settings are hardware independent (in terms of the units) 07:57:42 that's why the units are the way they are ;) 07:57:52 and we just have to explain to integrators that headroom is PID_MAX_OUTPUT - Max_Vel 07:58:03 sure 07:58:13 it's gotta be explained one way or the other 07:58:20 You bet. 07:58:37 I'd change the driver output limit to be equal to the PID limit as well 07:58:56 so effectively, we're adding a HAL_MAX_VEL to the ini file 07:58:57 Yes. 07:59:34 That'll get those stray pulses rounded up and put back in. 07:59:43 heh - yep :) 07:59:54 speaking of texas. 08:00:13 it would be ideal to remove anything that doesn't pertain to emc2 from the ini file, but unfortunately, some of it will be put back on exit 08:01:00 do you know what those things are or is there a way to test 08:01:16 edit the ini file, and align all the settings 08:01:24 run emc and exit 08:01:32 ah. 08:01:52 when you look at the file, any rewritten settings will be NAME = VALUE - not aligned 08:02:06 SWPadnos_: except the hal ones 08:02:43 no - anything that gets rewritten will have changed alignment - the HAL data won't be written at all 08:03:10 I meant ini values used from HAL 08:03:14 Huh. I thought the read/write that emc did was a diff 08:03:32 the diff is for the settings file, right? 08:03:40 parameter file , I mean 08:06:17 I know that for emc if you edit the file and add or remove comments or put in tickle type variables they will stay 08:06:28 in the ini that is. 08:07:09 right - there are some things that get rewrittten (OUTPUT_SCALE, for example) 08:07:28 I think that it only touches the lines that it recognizes as variables that are changed 08:07:31 actually - that one is a pisser, because it doesn't get read, and then getw rewritten to default every time 08:07:36 yes 08:07:47 but it ignores anything else you add to it 08:07:50 (I think) 08:08:00 That's my impression 08:08:10 SWPadnos_: exactly.. because it's used by HAL not by emc (that's what I wanted to point out above) 08:08:19 I'm checking (call me paranoid) 08:08:21 ok alex 08:10:43 yep - MAX_PID_OUTPUT was left untouched 08:12:30 nice 08:12:32 alex - looking at your changes, is there a reason for only checking the first 10 chars of the nmlfile name? 08:12:44 oh.. that was a paranoid check 08:12:52 had some segfaults I fought with 08:13:02 and that wasn't the cause, just made it 10 to be sure 08:13:08 forgot to put it back afterwards 08:13:16 does that include the path, or just the name? 08:13:19 I emptied ppmc.ini and shutdown and nothing came back. 08:13:31 oops ;) 08:13:39 i had a backup 08:13:44 phew 08:13:47 rayh_ppmc_usc: I think the shutdown procedure looks at the file and changes the stuff there 08:14:06 so if we don't need a variable and leave it out then it should not come back. 08:14:34 only the variables that emc uses, and which have changed. are written 08:14:42 unless there are some trip wires in that write routine that we don't know about 08:15:07 I suspect that it does an inifind on any variable, and if it isn't found, it doesn't write it 08:15:27 otherwise you'd end up with a pretty big file after the first run 08:15:45 (plus, if the var isn't there, it must be at default, and you can't check for differences) 08:16:00 I used to make them read only but I think nowadays they change the file permissions 08:16:37 gotta get to town. 08:16:48 there's an interesting (related) feature of KDE that I was reading about recently 08:17:08 also related to the ebo mail 08:17:39 they have the ability to read a series of config files, and overwrite settings from successive files (like ebo suggested) 08:18:18 but you can also put a [$i] in any of the earlier files, to make parameters (or whole sections, or entire files) "immutable" - so the user can't override those parts 08:18:44 it's pretty slick 08:19:19 nice 08:19:37 it's a little elss applicable here, but still a useful concept 08:20:14 the integrator can make emc.ini have some sane defaults, and mark some as unchangeable (like max_velocity ;) ) 08:20:23 yeah.. 08:20:29 but there can be other setups that override other things 08:20:31 yeah = usefull concept 08:20:42 like GUI 08:20:46 (user foo is an idiot, so use the simplest GUI available) 08:20:49 yep ;) 08:21:12 you know that it will be a pita to look for the .nml and .var files ;) 08:21:23 would only work if you use absolute pathnames 08:21:41 say you have a default ini / system 08:21:43 hm - for the config subdir thing? 08:21:52 for the multiple configs stuff 08:21:56 ok 08:22:02 like ebo said 08:22:12 and like you said 08:22:14 Catch you guys later. Thanks for the fun. Signed user foo. 08:22:19 sure - there's a config file "search path" 08:22:22 bye foo 08:22:26 see ya foo-bar ;) 08:22:32 bar-baz 08:22:34 rayh_ppmc_usc has quit 08:22:43 bar != baz 08:22:52 bar-baz!=0 08:23:01 fubar != pebcak 08:23:03 proven my case ;) 08:23:20 if bar!=baz then bar-baz exists 08:23:29 bar - baz always exists 08:23:37 given that bar and baz exist 08:23:39 :P 08:23:48 ok.. back to configs 08:23:50 I could write that in logic notation if you like ;) 08:23:55 ok 08:24:14 you write - I'll make some oatmeal and read in a minute :) 08:24:24 I'll wait 08:24:33 wanted to ask you about the mail I sent you.. 08:27:23 ok 08:27:39 (hm - 3 minutes - I must be getting old) 08:28:04 for the oatmail 08:28:08 ? 08:28:14 bathroom / coffee / oatmeal 08:28:19 heh 08:28:29 parallel processing 08:28:42 lol 08:28:52 hope you don't mix those ... ROFL 08:29:02 accidently 08:29:04 nope - separate process spaces 08:29:11 protected OS 08:29:17 make a list for when you're older 08:29:23 really old 08:29:31 heh 08:29:37 so - back to the email ... :) 08:30:09 yes 08:31:04 I'd say that the need for separate NML file directories is small (basically nonexistent) 08:31:09 would the scenario described there be ok? 08:31:28 having a few nml files in one directory is sufficient 08:31:28 SWPadnos_: yeah, and the subdirs might just reference as ../emc.nml 08:31:36 then all those changes are not needed 08:31:42 s/all/most 08:31:52 yep - as long as relative paths are allowed in the ini file, I think we're covered 08:32:23 they are, and work ok 08:32:30 the path can be expanded, so that an absolute name is handed to the NML code 08:32:33 yep 08:32:56 one of the changes for make install was running from the dir where the config file is 08:32:58 if relative paths work for the HALFILE entries, then that's covered as well 08:33:18 yeah.. but look at the changes of emc.run 08:33:46 I look in the dir where the ini is for .hal files, but also in the original config dir 08:34:08 so common stuff (core_servo , core_stepper , classicladder , etc) can stay in emc2/configs/ 08:35:00 I'm not sure if I like the "automagic" nature of that - all it saves you is ../core_servo.hal in the ini file 08:35:17 yes 08:35:19 I think it's the thing that cradek was talking about 08:35:39 just lt you specify all those files relative to the location of the ini, and it's all good 08:35:45 s/lt/let/ 08:35:52 that works as it is now ;) 08:36:04 then your work is done ;) 08:36:17 there is still need to move the configs around 08:36:35 for the nmlfile, I'd use the default dir, unless the person specifies ./yaddayadda.nml 08:37:03 actually - that would work for the others as well - assume default dir unless a path is specified 08:37:12 with ./ being a valid path 08:37:28 say again please 08:37:44 well - the nml file is unlikely to change 08:37:57 right.. that's why I wanted that to be in the configs/ topdir 08:38:00 so I thought that it should be takes from the default config dir 08:38:06 taken 08:38:14 yes.. but that can be done in 2 ways: 08:38:18 but, you still should be able to specify a different one 08:38:21 1. use ../emc.nml in your ini 08:38:32 2. take over the changes I did 08:38:50 ahh.. you want to hardcode it inside emc2? 08:38:53 the default value? 08:38:55 no 08:39:06 so only change it if needed? 08:39:30 I think we're saying the same thing, it 's just a question of how the decision is made to take the file from a different dir 08:39:46 and the easiest way would be just like bash does it 08:39:56 the problem is that you've got 3 or 4 software components that do that 08:40:01 if you type "foo" - bash searches the path for foo 08:40:03 taking the nml file out of the ini 08:40:07 if you type ./foo, it doesn't 08:40:29 so you can explicitly override default behavior very easily 08:40:41 GUI (aka emcsh, or AXIS, or xemc..), IO (aka ioControl.cc), TASK (aka emctaskmain.cc) 08:40:50 and emc.run 08:41:40 I guess the question is just what the "search order" is 08:41:53 you're not hearing me ;) 08:41:57 bear with me for a while 08:41:58 could be 08:42:03 lets take IO 08:42:05 bearing ;) 08:42:13 IO needs to talk to task, right? 08:42:29 therefor it needs to open some NML channels (or listen to some) 08:42:30 sure -I understand that all processes need to be looking at the same NML file 08:42:41 ok.. now how is this done: 08:43:07 1. there is a function emcGetArgs() that's called, and looks for args to the program 08:43:18 searches for -ini & the like 08:43:39 next there is a function called iniLoad() usually, which reads the ini for values it needs 08:44:13 if it finds a NML_FILE reference it replaces the DEFAULT_NML_FILENAME with it 08:44:20 then tries to read it 08:44:38 but the programs get executed from the directory where the ini is 08:45:20 yep - and all of those programs have to either (a) have the same complete file path specified, or (b) use the identical default behavior 08:45:33 (or (c) have an environment var) 08:45:37 c is bad 08:45:44 yes 08:45:59 a is bad too, because you can't have absolute paths in the ini 08:46:16 hmmm - well that leaves ... 08:46:21 B!!! 08:46:27 ok.. how do you mean b? 08:46:40 say you have emc.nml in the ini 08:46:53 you try to open in the same dir, and that fails 08:46:59 what will you do? 08:47:11 all programs that use the nmlfile have to search the same paths, in the same order, to find the nml file 08:48:06 which paths? 08:48:19 that's what we're trying to decide ;) 08:48:20 you don't know where you are.. 08:48:36 probably should issue a pwd first, then try to see 08:48:42 but that's just as bad :( 08:48:53 sure you do - $0 is the executable name with full path, no 08:49:30 in ioControl.cc ? 08:49:40 yep - it should be the first arg 08:49:43 not scripts.. 08:49:44 argv[0] 08:49:55 humm.. with full path? don't think so 08:50:03 I'm not sure about that either 08:50:15 but a pwd is also workable 08:51:04 ok - scripts don't get the full path - bummer 08:51:23 scripts don't need it 08:51:25 they know it 08:51:35 or better said they decide it based on where the ini is 08:51:40 ok 08:51:41 $0/argv[0] is the name the program was invoked as 08:52:03 ok - thanks (saves me from writing a "hello argv[0] program") 08:52:28 so it should have the full path 08:52:36 only if you ran /the/full/path/program 08:52:37 emc.run executes everything with full paths 08:52:42 yes 08:52:51 ;-) (at least it does now) 08:53:21 SWPadnos_: I am thinking this is complicating it too much 08:53:39 how about we have (by agreement) the default nml in configs/emc.nml 08:53:48 and all ini's are in configs/foo/ dirs 08:53:50 yeah - as long as the system works from emc.run, and you can specify both absolute and relative paths, I think that's enough 08:54:05 and reference that nml file by ../emc.nml 08:54:24 I think the config should work from configs/ as well 08:54:24 actually you don't need to do that, we could have DEFAULT_EMC_NMLFILE = "../emc.nml" 08:54:48 config would work, if you have a NML_FILE=emc.nml in it 08:55:02 unless there's a "configs/sample" or "configs/default" dir 08:55:18 yesp 08:55:19 in there you would either have a). no NML_FILE at all 08:55:27 or b). one that reads ../emc.nml 08:56:52 ah - OK. DEFAULT_NML_FILE (../nmlfile) is in scripts.run, and is overridden by an ini setting NMLFILE, if present 08:58:40 well not in scripts.run, actually inside emc (emc2/src/emc/nml_intf/emccfg.h) but you get the picture 08:59:04 right now the NML_FILE in the ini might be missing 08:59:20 components using that will try the default value before giving up 08:59:21 emc.run I meant. I'd think that the same thing would be needed in both the run script and the header file 08:59:44 so that programs use the same defaults as the script 08:59:55 the script doesn't use the nml file 09:00:08 it does specify it though, right? 09:00:13 the changes you've seen to the script are only to pass the nml file as an argument to the files 09:00:19 to be able to find them easier 09:00:33 ah - OK. 09:01:09 so I did the NML search in the emc.run script, then passed the absolute path to it as a -nml parameter to all parties involved 09:01:16 except AXIS.. didn't touch that 09:01:18 phone 09:02:07 ET phone.. swampy 09:07:04 ok - back 09:37:10 right.. 09:37:11 missed that :( 09:37:29 heh - it's midnight - you should go to sleep ;) 09:37:34 passing the nml file seemed like a good way 09:37:48 yep - I agree 09:38:15 the only thing that happens is that you can't run the programs "manually" and expect them to find the same file (but I can live with that) 09:38:27 right 09:40:32 well.. seems afterall you agree with my changes ;) 09:40:47 I think so 09:41:11 I just didn't understand them at first (I'm not so used to the cvs diff format, or shell scripting in general ;) ) 09:41:51 well.. I was a bit worried about changing functionality without talking to others ;) 09:42:13 that is a concern 09:42:23 I agree partly because I have no stake in how it works now ;) 09:42:26 well.. functionality isn't changed 09:42:37 mostly the way things get passed 09:44:44 anyways.. guess I'll bring it up on sunday 09:44:57 probably a good plan 09:45:07 or maybe on the dev list 09:45:38 yeah - that would give people a chance to look over the changes before discussing them on Sunday 10:00:58 guess I'll do that tomorrow 10:01:01 gone to bed now 10:01:03 night 10:01:17 ok - night 10:01:30 alex_joni has quit 11:26:14 jmkasunich has joined #emc-devel 11:26:23 hey there, jmk 11:26:29 hi 11:26:47 its friday! 11:26:54 (i get to sleep in tomorrow ;-) 11:26:57 woohoo - you can stay up as late as you want!! ;) 11:27:20 not really, I have to sleep in just to catch up from all the other staying up late 11:27:37 heh 11:28:02 you and pete are terrible when it comes to keeping me up late 11:28:47 we try ;) 11:28:54 you succeed 11:29:10 pete especially - he has an unfair advantage 11:29:12 check the logs on this channel for a nice discussion I had with Ray today ;) 11:29:29 logger_devel: bookmark? 11:29:29 See http://solaris.cs.utt.ro/irc/irc.freenode.net:6667/emcdevel/2005-12-02#T11-29-29 11:30:06 we overlooked the obvious in our discussions with skunkworks re: pid headroom 11:30:20 what is that? 11:30:25 all we have to do is make a new [AXIS_n] var, called PID_MAXOUTPUT 11:30:44 just because emc1 dodn't have it doesn't mean that emc2 can't 11:30:48 didn't 11:31:49 do you mean the axix..whatever HAL pins from the motion module? 11:32:13 no - since PID needs a little extra room (over the MAX_VELOCITY), make a new var in the ini 11:32:27 and assign that to pid.maxoutput and stepgen.maxoutput 11:32:38 could do that 11:32:44 why not use MAX_OUTPUT 11:33:01 (I think that's what Ray suggested, just starting to read the log) 11:33:05 because then we'd have to have formulas, or PID won't be able to catch up to step inputs 11:33:29 so you lower max_output a little, or add a little to PID_MAX 11:33:57 I don't think anybody is using MAX_OUTUT right now 11:34:40 well - I added it to the core_servo.hal file, and I thought that motion used it 11:34:55 motion doesn't (I don't think) 11:35:20 the path from ini file to motion is convoluted... would take some checking to confirm that 11:35:23 I was probably looking at it like an emc1 parameter ;) 11:35:34 I kjnow it used to be used there 11:36:36 it used to limit the PID output, back when the PID was integrated with the motion module 11:36:51 now I'm almost certain the motion module doesn't use it at all 11:37:06 easy test: hack the hal file so the PID limits are fixed at whatever works 11:37:17 then change the ini MAX_OUTPUT to 0 11:37:29 ok - I'm thinking of max_velocity, not max_output - that's what I made core_servo use 11:38:12 also, the PID (and possibly the various output drivers) should be able to have asymmetric limits 11:38:45 perhaps, but that is rather specialized 11:39:08 note: there is a HAL limit block, that lets you independently set min and max 11:39:14 true 11:39:31 though a Z axis could easily have different parameters going down vs. up 11:39:38 PIDFF, limits, accel, etc. 11:40:05 the emc1 PID had a bias parameter for that kind of thing 11:40:17 I don't recall if the HAL PID has the same 11:40:23 could certainly be added if not 11:40:34 I think it does, come to think of it 11:41:20 yep - it's there 11:59:59 wow, alex seems to be making this ini file thing a lot harder than it has to be 12:00:24 could be 12:00:34 use the directory that contains the ini file as the current directory, paths contained within the ini file are relative to that 12:00:36 simple 12:00:56 you want to use the generic .nml file, say ../emc.nml in the ini 12:01:07 it's a matter of making all of the programs that use the NML file do that as well 12:01:33 (which includes all of the UIs) 12:02:17 don't all the various binaries get the path to the ini from a command line arg? 12:02:48 yes, and also the location of the NML file, in a patch that Alex is testing 12:03:24 but he had to change emcsh.cc, emctaskmain.cc, ... to do it 12:03:51 oh 12:03:59 I know what to do! 12:04:02 emcargs.cc, iocontrol.cc 12:04:09 get rid of NML ;-) 12:04:12 and he left out axis 12:04:19 hey - that's a good idea 12:04:28 and you can sleep in tomorrow! ;) 12:04:29 lol 12:05:25 actually, I'm planning on throwing together a preliminary version of halvcp tonight 12:05:30 (if pete doesn't show up ;-) 12:05:43 maybe you should just leave the two emc channels ;) 12:06:07 three actually, I'm also on the board channel 12:06:13 is pete? 12:06:18 no 12:06:23 well - there you go ;) 12:06:27 its only 4:30 out there 12:06:57 at least it would make it slightly harder to distract you from coding all night 12:07:04 yeah 12:07:15 but I've enjoyed the distractions 12:07:34 there are few folks who really talk about these kind of details 12:07:43 true 12:08:09 it's nice to have conversations where people aren't saying "this is how it's done, you have to make it the same" 12:08:26 that's probably a big part of it 12:12:07 petev has joined #emc-devel 12:12:52 * jmkasunich hides 12:13:08 heh 12:13:10 u don't want to eal with threading? 12:13:15 eal/deal 12:13:29 actually I do... 12:13:36 just not until 2am ;-) 12:13:42 I have any idea to do it easy in the HAL 12:14:08 I think we could mod the HAL gearing comp and add a few pins to motion 12:14:34 if the gearing would take a start count value for lock up, it should be pretty straight forward 12:14:49 take z out of coordinated mode, hit the lock pin 12:15:03 what do you think? 12:15:16 I dunno 12:15:26 it might work for rigid tapping 12:15:31 do u think TP or HAL for starters? 12:15:38 single point threading is more complex 12:15:47 huh? 12:15:49 I was thinking inside EMC proper, not in hal 12:15:58 single piont threading doesn't nead gearing 12:16:20 how else do you get the pitch you want? 12:16:36 it's just a helical move 12:16:46 doesn't have to be geared to spindle speed 12:16:55 only if you have a servomotor on the spindle and treat it as a position controlled axis 12:17:00 circle in x,y, linear in z 12:17:01 that is not the norm 12:17:17 now I'm saying huh 12:17:38 I'm talking about single point threading on a lathe 12:17:40 threadmilling works that way - with helical moves 12:17:45 with single point, the cutter only has a little point, it spins much faster than a tap would 12:18:04 oh, I was still on a mill 12:18:06 no, with single point, the cutter is mounted in the lathe toolpost and spins not at all ;-) 12:18:19 single point on a lathe is the same as rigid tappin on the mill 12:18:26 not quite 12:18:31 multiple passes, for one thing 12:18:33 why? 12:18:38 ok 12:18:55 but each pass is the same 12:18:55 tapping doesn;t need an index pulse on the spindle encoder 12:19:03 multipass threading does 12:19:15 actually, the passes are slightly different 12:19:17 also, threading might involve more than just moving Z 12:19:22 u don't need an index, just the start count like I mentioned 12:19:26 you offset by a little to increase the depth of cut 12:19:28 tapered threads for instance 12:19:56 so u want to gear multiple axis to spindle speed on the lathe then? 12:20:01 yes 12:20:05 and if you are threading to a shoulder, you want to pull the tool out as you finish the pass 12:20:20 NPT threads are tapered, for example 12:20:39 each axis could have a gear module 12:20:56 what are the trade offs for TP vs HAL? 12:21:14 it seems pretty specialized for HAL 12:21:20 I see HAL as keeping things tighter, but probably limited to linear gearing 12:21:53 the TP still has to be aware of what is going on... 12:22:32 shouldn't it just be happy with the position feedback it see? 12:23:01 the way I see it, a threading (or tapping) pass is an ordinary coordinated move, but instead of using time as the independent variable, it uses spindle position 12:23:03 does the TP even look at the following error, or is that servo only? 12:23:30 do u think the error will be acceptable that way? 12:23:49 the TP always uses position feedback 12:23:50 certainly won't be good enough for gear hobbing stuff 12:24:05 it just gets it as steps generated for stepper machines 12:24:40 swp: I thought from yesterday, the TP was just assumeing things went where it said to? 12:25:01 yes and no :-/ 12:25:28 right - sorry ;) 12:25:37 jmk: what's the no part? 12:25:41 (I told you I'd forget 90% by today) 12:25:46 emc looks at the feedback, for purposes of following error detection 12:26:00 it also uses feedback when stopped, to set the command when it starts again 12:26:02 right, but that's just for error, correct? 12:26:04 rihgt - the TP is too slow to be able to use it 12:26:08 "stopped" = motion disabled 12:26:23 yes, not for control 12:26:27 so if gearing works, the TP should be happy with no error 12:26:47 I guess I don't get what you are porposing 12:26:50 proposing 12:27:07 I was just thinking about putting gearing modules on the axis in HAL 12:27:30 if we mod the gear module to take a start count, we can start the same relative to the spindle each time 12:27:42 so you essentially disconnect an axis from the motmod axis.0.position-cmd output, and drive it from the gearing module instead 12:27:48 yes 12:28:00 and motion gives the start count and lock gear pin 12:28:00 the trouble is that there are sometimes lead-in and trail-out moves 12:28:16 once its disconnected, TP has no idea what is going on 12:28:27 you would have to blend the lead-in with the "geared" output over time 12:28:58 (note: I proposed this idea at Fest, and was met with these concerns ;) ) 12:29:43 you can almost do gearing just by using a PID module 12:29:53 what are the various lead in going to look like? 12:29:55 I don't have concrete facts yet, but I feel that threading/tapping is a machine tool operation, and should be handled by the machine tool oriented part of the SW, not the generic part 12:29:59 swp: yes 12:30:01 (or the scale block) 12:30:30 for ridgid tapping, lead in could be handled by adjusting spidle speed 12:30:39 It probably needs to be part of the interpolator 12:30:44 for a lathe, I'm not sure what it looks like 12:30:50 I think rigid tapping doesn't use leadin 12:30:53 I always start from a groove 12:31:06 and finish in one too? 12:31:07 jmk: I don't use it on my machine 12:31:07 for the reason that John mentioned - it changes the independent variable away from "time" 12:31:30 jmk: finish in groove or off end of part 12:32:10 off end of part usually only happens with left-hand threads (unless you run the spindle backwards and put the tool either upside down or behind the work) 12:32:29 but both lead-in and lead-out are issues 12:32:30 yes, and right hand start off end and end in groove 12:32:36 the issue is, how does the TP handle that - there's no longer a 1:1 (or 10:1) ratio of poses vs servo cycles, since the completion rate of successive poses is locked to the spindle 12:32:48 so what do the lead in/out moves look like? 12:32:58 depends on the shape of the thread 12:33:17 does your lathe have a threaded spindle nose? 12:33:28 for a normal thread, I'm having trouble seeing how leadin is anything but slower speed 12:33:43 my lathe is d1-4 cam lock 12:33:49 ok, that won't help... 12:33:51 I can thread either way 12:34:02 lathe spindle nose threads don't end in a groove 12:34:08 hm - what if motion had an input that could change the increment to the spline independent variable (away from servo period / TP period)? 12:34:23 they just smoothly retract the tool, the thread gets shallower and disappears over perhaps half a turn 12:34:27 that is lead out 12:34:29 oh, so you are saying the thread fades out at the beginning or end? 12:34:40 ok, got it 12:34:43 its a right angles to the centerline of the part 12:35:11 sure, but that seems like a coordinated move on x with gearing on Z 12:35:16 seems easy 12:35:27 you probably don't need lead in and lead out on the same part, but they are kinda equivalent 12:35:36 sure 12:35:46 the X move has to be synced with the spindle too 12:36:00 not as much as Z 12:36:08 yes it does 12:36:18 I think more error in X is acceptable 12:36:24 say X pulls out over half a revolution 12:36:33 ok 12:37:01 if you are nearly done (last few passes) and you start the pullout a few degrees of spindle rotation late, that pass is gonna dig in 12:37:35 yeah, but that seems like TP speed stuff and it will only take a little heavy or light cut 12:37:48 if Z messes up, your threads are wavy 12:38:20 they're both important 12:38:49 anyway, lets think about the toolpath 12:38:53 ok 12:39:16 assume for now, a right hand thread, normal rotation, starting off in the air past the end of the part, and finishing near a shoulder 12:39:25 ok 12:39:35 initially, part is spinning, tool is sitting still, a little past the end of the part 12:39:42 yep 12:40:04 at some point (probably based on index pulse) we say GO! 12:40:12 or some count 12:40:41 but I think we say go and the gear comp syncs to the count if we use HAL 12:40:42 the position command for Z immediately begins to go left, at a rate dependent on spindle speed 12:40:51 ok 12:41:14 first problem is that the commanded speed just went from zero to something without any accel 12:41:36 so the axis is gonna fall behind and take some time to catch up and settle out 12:41:41 there are limit in PID, no? 12:41:52 yes, agreed 12:42:06 but we're still in air 12:42:12 so the initial position needs to be far enough out in the air to allow for that 12:42:18 yes 12:42:33 could be a problem if we were doing left hand and starting at the shoulder 12:42:49 anyway, lets keep going 12:42:55 ok 12:43:04 Z stabilises, tracking the spindle, the cut begins 12:43:11 yep 12:43:15 if the cutting load slows down the spindle, Z tracks it 12:43:20 yes 12:43:30 say we're cutting a 1" long thread 12:43:35 ok 12:43:36 after 1", now what? 12:43:45 we keep Z moving, and retract X 12:43:56 if you wan