[325] you guys see my email about units? [326] yup [64] you're right, they could be furlongs for all it matters, but it needs to know they are furlongs to convert [65] no [66] why not? [69] The only time it needs to know what the units are is at the user input/output [70] all it needs to know is an array of internalunits -> specific unit, unit name [71] right, but if user input is in mm, it needs to know how to convert mm to internal units [72] yes [73] but that should be done from an array/map of things not any hardcoded values [76] ? [77] I wasn't proposing any hardcoded things (or do you mean limiting it to METERS, INCHES, MM is hardcoding?) [78] If you look at the code, units are only defined at the Task & GUI level. [79] so when I want to set up my machine in miles and kilometres the I just put the right values inthe config [80] which code? emc as it atands or emc2? [83] I'm talking about a proposal for emc2 [84] as it stands there is lots of harcoding in various places .. emc2 should just be flexible IMHO [85] "The code" = EMC sources [86] internal values still have units associated with them - it is inevitable [87] emc may pretend it isn't so, but it's only pretending. [90] emc cannot or should not be ablke to tell [91] its just 1000 units .. could be microns, could be miles ... [92] _any_ variable that contains a length or position has units, whether they be steps, counts, inches, or light years [93] if you don't know the units, you don't know the length [94] I thinks thats the point ... [97] you're right that most of emc doesn't care, but conversions at each end do care [98] the core should choose an appropriate unit based on its step sizes, encoder counts, processor speed etc etc [99] NFW! [100] in the core, it should be floating point [101] as you like ... [104] but thats how we are in the mess we are in [105] I disagree [106] we are in the mess because we don't have a consistent core unit [107] so the internl units are fixed at the moment as mm AIUI [108] seems that way, but not clearly documented [111] when I try to run at 2 steps/mm all hell breaks loose [112] nope. Internal units are defined by the UNIT parameter [113] paul_c: not true [114] not exactly ... [115] internal units _are_ mm [118] well, maybe not [119] but they are defined in _terms_ of mm [120] the docs claim internal units are mm... [121] hence units = 1.0 for mm, 0.0398234234525 for inch [122] and thats some more lunacy ... [125] if units are  0.0398234234525 its inches .. [126] robin_sz: the fact that all hell breaks loose when you try 2 steps/mm means the code is busted - floats wouldn't do that [127] thats why I would rather specify units by name [128] and if units as  0.0399 ... ? its still mm [129] 2 steps/mm is a math problem when checking the following error.. [132] my opinion - counts should be changed to machine units at the HAL level (and my encoder module has a scaling parameter to do that) [133] then the pos feedback, and the command, and the ferror, are all in machine units [134] the ferror limits should also be in machine units [135] fine so far ... [136] hmm ... error not in number of pulses, counts etc? [139] the output of the pid loop is commanded velocity in machine units per second [140] and the stepgen module scales that to steps/sec [141] robin_sz: no, _nothing_ internal is in steps [142] sounds dodgy ... [143] so to set the ferror I have to know how big the internal machine units are? [146] no [147] if you want ferror to trip at 0.1mm, you set it to 0.1mm [148] ahh, [149] confusion over the term /machine units/ [150] if you want it to trip in 25 steps, then yes, you need to know how big a step is [153] OH, you were thinking machine units = steps? [154] you mean mill/lathe/plasma machine units [155] not /internal representation of something within emc/ machine units [156] machine units = emc2's internal length units [157] which are always real length units [160] expressed as floating point [161] _not_ anything expressed as integers [162] doenst sound sane to me at this point [163] working with steps as a basic unit is sane? [164] no [167] then what is? [168] I agree that everyting should be in say, mm or whtever unit you choose to set up in [169] right [170] machine units = "whatever unit you choose to set up in" [171] and then translation into miles/inches/microns for programming and display as you run the thing [174] exactly what I was saying [175] BUT .. :) [176] internally, within emc [177] that need not be machin units [178] so you add a fourth set of units, internal units? [181] linear units are just floats - It is only the input/output stages that need to convert to real world units [182] it could be an arbitary unit, chosen by emc to scale the registers and the timer lloops and a whole bunch of other things [183] Angular units are a different kettle of fish... [184] paul_c: keep quiet about angular - linear is bad enough for now! [185] robin_sz: scaling and loops and all that rot only matter if you are using ints [188] we will need to consider it at some stage [189] I know [190] but one thing at a time [191] btw, the same rules would apply to angular - internal should be radians, so sin, etc, are straightforward [192] agreed [195] part and display inits can be degrees, radians, grads, etc [196] for instance, I might choose to set up my sub-micron table using units of metres for convenience [197] acc = 4.8ms^2 [198] right [199] but if emc uses m as the internal representation, I could run out of precision [202] nope [203] a float always has 24 bits of precision [204] yes ... [205] so my range can be +/- 1.00e-12, or +/- 1.00e+12, and in both cases, I can access 2^24 distinct spots in that range [206] but surely it should look at the maximum axis movements (0.02m) and the 10^12 counts/m encoders and scale its internal units accordingly? [209] why? [210] the encoder counter should scale the feedback [211] and the step generator should scale the output [212] do you care if internally a move on you micron table looks like G01 X0.000010 Y0.000200? [213] so how are the internal units decided then? [216] by the machine builder [217] speced in the ini file [218] "internal_units = METER" [219] or "internal_units =MM" [220] eek [223] 1^10 metres [224] internal units is probably a better name than "machine units" [225] paul_c: what? [226] sorry... idle maths in the wrong window. [227] surely thats just config units? [230] from the config I dont care how emc represents that internally [231] if you wish - but give me one good reason why internal units need to be different than config units [232] my one good reason why they should be the same: [233] halscope and halmeter will let you look at internal values - the values would make more sense if the user (troubleshooter) knew what the units are [234] I get the feeling we are argueing over a point that has little relevance within (emc or emc2) source. [237] not really, i think how the core handles its internal representation of the world is important [238] but it is only a number ! [239] hmmm - do we all agree that we want config units, part units, and display inits (shelving the internal units part for a moment)? [240] yes [241] three words for the same thing... [244] config != display != part [245] config units are just handy for set-up [246] config units are the key to setup [247] the other two are quite independetn of each other, and the config units [248] most stuff in the ini uses them - limits, screw pitch, ferror [251] nods [252] once the machine is set up, you can change display and/or part units to make inch or metric parts [253] ndos [254] Ah.... config units = native machine units [255] right [258] that's why I called them machine units in my email [259] all it needs is a table mapping conversion rates to names [260] terminology might need tweaked [261] and display units = inch or mm depending on a scaling factor [262] yes, or feet, or meters, or microns [265] nods [266] and the steps are defined in terms of the native units [267] steps? what steps? [269] you mean input scale and output scale? [270] o/p steps for ypur motors/encoders [273] hi matt [274] paul_c: right [275] i.e. No change to what we have now. [276] matt: we're talking about units for emc2 [277] hi, my connection isn't that good so I may come & go [280] i was just replying to your email [286] paul_c: I don't know what we have now well enough to be sure [287] but I don't think its exactly the same [288] similar tho [291] the difference is in terminology. [292] right now everything is handled internally as mm as i understand it [293] does emc today use internal units (floats) in the pid and ferror calcs, or integers and steps? [294] floats [295] and those floats represent mm, even if the user says "units = 0.039..." ie inches? [298] and there in lies one of the problems that Robin has [299] i'm gonna try something... [300] wot the hell? my irc window rolls up every time I move the mouse outside it.  what did I do? [301] I think: [302] 1. For my purposes Part units would always equal Display units. Is there a case where this isn't true? [305] 2. [306] On Sunday 14 December 2003 10:27, jmkasunich@att.net wrote: [307] > Machine units are selected in the ini file, and never change while [308] > EMC is running.  The ini line should be something like: [309] > "MachineUnits = inch" or "MachineUnits = mm", not some gibberish [312] double click on the top bar [313] > like "MachineUnits = 0.03856234" [314] I agree, but what about units for an angular axis? Perhaps there should be linear_units and angular_units rather than than MachineUnits with linear or angular selected on a per axis basis. [315] 3. I think a lot of init parameters ought to be handled as integer quantities of basic units, stepper steps or encoder counts. It doesn't make much sense to allow floating point units for things like backlash or home offset when they will have to be rounded off to "counts". [316] that makes sense [319] that was my reply so far [320] hmm .. /me is thinking [321] re: angular - I glossed over that, but would apply the same principles [322] but I strongly dislike the thought of using steps/counts for anything [323] backlash is a length, not a count. [326] right [327] so it is expressed as a length in the in [328] i [329] BUT ... [330] it is a function of screw wear, and doesn't change when you change from fullstepping to microstepping or to servo [333] angular units are easy - Internally, always in Rads 'cos thats what the maths is done in. [334] internally emc is free to represent that in whatver terms are best fo it .. [335] but I argue that internal units should = config units, so they mean something when troubleshooting [336] not a good reason for choosing machine architecture in my opinion .. [337] although it does help development [340] again, why not internal = config?  what benefit is there to having them different? [341] because the config units may not be the ideal size for the internal representation of the machine [342] if my basic resolution is .001, and i set backlash to .0015 it can't be done (if it's rounded up there's no difference between .0015, .0016, .0017, etc.) [343] they're all - .002 [344] if your basic representation is a float, you can set backlash to 0.0015324, and the rounding will be done at the last possible moment, when the values are actually scaled to counts and rounded to ints [347] I've done realtime control using both float and fixed point, and believe me, float is _FAR_ better, if you have the CPU to handle it. [348] on Pentium machines, the speed of float and int are similar (except for divides), so I see no reason to use ints for anything that isn't inherently integer [349] like say step counters ... [350] right [351] so why not let emc represent *internally* the position in steps [354] so far the hal concept is that an encoder counter module would count in integers, and scale to float [355] and externally in config units? [356] X steps, Y steps, Z steps? [357] hmmm .. yes, cold be dofferentt [358] all axis need to use the same units internally for kinematics [361] the place this really bugs me (in the current setup) is the PERIOD variable. When I'm trying to find the fastest PERIOD I can use on a machine it's difficult to tell where the next "step" in time is since it's a divisor for the 8254 clock frequency [362] which is like 1.8blahblah MHz [363] 1.18 iirc, so ~1uS resolution [364] ~! [365] IOW, you make a small change and no change in actual period, then another small change and actual period changes by over a microsecond? [368] I'm not that opposed to floats really, but we need an ini file maker that only lets you choose logical values [369] YES - that's my point!!! [370] this all goes away when you offload the stepgeneration onto external hardware ;) [371] robin - you still have a servo period [372] mshaver: logical? .. [375] Oh, you know what I mean! [376] jmkasunich: yes for taskplanner/servo lopps, agreed [378] matt: small comfort for now, but rtapi displays the actual timer period in nsec, so you can see rounding [379] those periods will be an integer number of the base period [383] mshaver: part of the problem is that at the moment we are locked to two (and only two) values for units, what is logical may vary, depending on application [398] Is Fred joining us Matt [399] robin_sz: yes, support for other units (cubits, etc) should be easy to implement, not deeply ingrained in the code. [400] re: cubits [401] I thought about calling him to see, I could do that... [404] they could be easily implemented as display and part units [405] mshaver: yep, I have run into deep problems with the current setup on plasmas [406] using them as internal units could be trickier [407] if we want to avoid a clutter of conversion factors in the ini files [409] if internal/config units are limited to a predefined set, then emc knows what they are [413] it can automatically convert to/from any other units in that set [419] jmkasunich: just sent you a note re internal units. [420] mshaver: emc gets into knots when you start trying to do 10 steps/mm and 30m/minute ... [421] and a single conversion factor can be spec'd for custom part or display units [423] mshaver: which is only 5khz steps [424] Sure it can.  It's under units in the tkemc menu [427] robin_sz: That is a quanitisation error... [428] not just that though ... [429] its more fundamental to the desing .. [430] if I pretend those are mm, not m it works fine [431] because its using a fixed internal representation of the units [434] if it was allowed to decide that on the fly, then those two ini's (which both result in a 5khz max o/p) should yied the same results and the same internal represntation if the units, but with different scaling in i/p and o/p [437] my net connection crapped out so I called Fred [438] is he getting on? [439] his wife said he'll be back in 15min & I left him a message to call & that there was a good discussion on irc [442] I'll try not to bug him too much about the trajectory planner... [443] robin_sz: I have a couple of ideas that may help resolve the problem. [444] he told me the other day that rb is working on it [445] I'm late.  Where are we in the topic list? [446] we were talking about units before noon, but should we change and focus on an agenda? [449] Can we take these one at a time? [450] let's settle units _once_and_for_all_ ;) [451] K [452] Can we first get a concise statement of the problem. [453] the gist of what happened before noon: [456] config units - units for things like input scale, output scale, ferror, backlash, etc [457] part scale: g-code - can be changed from inches to mm (does g-code support feet, meters, etc?) [458] display scale: for the GUI [459] can be changed by user [460] G code is unitless. [463] wouldn't just a units line in an ini do? [464] perhaps, but in the real world you need units. [465] Units are imposed at run times. [466] except for g20/21 [467] If I write a program to make a part, you better know the units used by the prog when you run it [470] g-20 inches g21 mm. [471] right - so G20 and G21 would set part units [472] default part units would be set in the ini file [473] Why must you know.  If I wanted to make a 1/25.4 model I could write inches and mill mm. [474] yeah, but that's the exception [477] If I order a part from you and ship you a g-code file, you better run in the units I programmeed [478] or I'll reject the part [479] you'd better write it in the file then ...as a comment [480] three states-default,g20 and g21 seems like it would cover everything [481] that's why I would put G20 or G21 in the file [484] That should be no problem.  You should put a g20 or g21 in the head of the program. [485] exactly [486] So the internal units are no problem with the units of the g-code? [487] haven't got to internal units yet - that is where we tend to disagree [488] the way I see it, gcode units get converted to internal units as soon as the gcode is read - the conversion factor is set by G20/G21 [491] well in servos the real internal units are encoder counts [492] les: part of the problem IMHO [493] Well, now we've got les on the integer side ;) [494] haha [495] internal stuff should be floats [498] hey floats are fast nowdays [499] which is a coding decision [500] fair enough .. but why should 1.0 as an internal unit represent 1 machine unit? [501] apart from the debugging thing? [502] how long is 1.0 machine units? [505] its .. 1 long [506] that should not be a difficult question to answer [507] 1 what? [508] it ain't a length without a unit [509] what ever the machine builder wants it to be.. [512] 1 count [513] how long is a count? [514] 1 micron [515] 1 metre .. [516] heh [519] both ar possible values [520] Are we saying it is one of the value placed in input or output scale. [521] depends on the encoder res/step size - that's the point of scaling [522] there are very few pure numbers in the world - nearly everything in engineering has units/dimensions unless it is a dimensionless number like a gear ratio [524] maybe i don't really understand the problem [527] lets say it 1mm ... [529] so 1 machine unit is 1mm [530] is there a problem even? [531] nope [532] I think Matt's got a point here.  If all of the ini vars were done in relation to one encoder count or one pulse it would eliminate the problems that we have with the ini configuration between inch and mm, [535] but would you still choose 1 machine unit => 1 internal unit if I had 1 step/mm or 1,000,000 steps per mm?? [536] All of the other cards I have used use counts [537] if you use steps, then change from fullstep to microstep, you need to change everything [538] I think ini's in counts would be a very bad idea [539] nods [542] very bad [543] limits, backlash, etc, are lengths, not counts [544] and my machines are 3.1m long, not 392992992 counts [545] No you would simply change the input or output scale and every other value will be scaled to that. [546] way big numbers [549] prior to ray joining i expressed the concern that floats are ok, but that they need to be rounded to integer numbers of counts in the end. I just wanted ini params that were unambiguous. [550] the _only_ things that should use counts are the encoder reading hw/sw, once it's inside it is in length units [551] makes sense .. makes the ini's nice and undertandable [552] and lets face it ... hard ini setting is what trips up most people or puts them off // [553] But so does defining the internal machine units as one count and interpreting every ini value based on it. [556] input scale should apply ONLY to the encoder input - it should not affect any other ini params [557] agrees [558] that's why I want to define the internal machine units as a real length unit [559] nods [560] either meter, inch, or mm [563] Right now they are defined in mm. [564] ray__: to the user, the internal units should be totally invisible .. [565] They are now. [566] ok robin, call it "config unit" instead of internal unit [567] ok. [570] internal units is another arguement, ignore for now [571] config units shold be inch, mm, m, micron .. choose one from a list with know relationships to oother length units [572] we have config units, part units, display units [573] k [574] exactly [577] right [578] and it will have to be a double right? [579] double or float [580] some numbers, a point, some more numbers. worry not about how it is stored for now [581] OK - I didn't know whether les was refering to length or format [584] actually in the ini file I don't want it to be a number at all [585] we have a list, so it should be a name on that list [586] MM, or FEET, or MICRON, not 1.0, or 0.039, or 0.001 [587] for clarity [588] right [591] default_unit= [592] I'll agree with you there [593] yup [594] No that will not work for a vehicle approaching mars. [595] 1/25.4 is a constant [598] the list could include KM if we want it to [599] and even lightyear ... all we need is a list of how they relate to some random, arbitary unit [600] Why do we insist on making it some unit that has a name? [601] and frankly, emc2 won't be going to mars - one of the things we're trying to accomplish with emc2 is to make is easier to use in the "normal" case [602] ray__: because when I write axis_lneght=xxxx it needs to be in units I know what they are [605] Sure lets dumb it down.   [606] Matt's right, we need face to face. [607] thought it was going fine so far ... [608] the kind of folks doing flying carpets and mars shots have the know how to deal with emc1 [609] This was the point I'd hoped we'd not reach... [612] emc2 will sacrifice some flexibility (not much) to help the normal guy use it [613] I agree that all of the config values should be defined by a single entry.  But why do we have to assign an arbitray set of names to that unit? [614] but be high performance? [615] ray__: well, what would you use then? [616] I'd use the encoder count or the step pulse. [619] les: yes [620] ray__: I'd much rather use an engineering unit, rather than an arbitrary unit like steps [621] I would vote for some real world unit for configuration. Else [622] It should be easy enough to explain to an integrator that once you set that variable, everything is in terms of it.  Even acceleration is in encoder counts per second per second. [623] ray__: but they are different for ech axis and may change from day to day [626] esp. since steps aren't always the same on all axis [627] it would be hard to "get a feel" [628] Obviously, at some point we have to associate counts with mms/inches, etc. I think the whole disagreement here is where that point is... [629] Yea youre right.  Hate to admit it. [630] accel in m/sec^2 is easier to understand [633] But accel is still a universal rather than a per axis thing. [634] no its per axis [635] The point at which the unit/count is defined *must* be in the ini file. [636] yep [637] currently the hal does the unit-to-count translation in the device drivers [640] beyond that point, the units are arbitary [641] all hal data is in units [642] not counts [643] scaling is part of the device [644] How? [647] makes sense  I guess .. you just tell the device to go to position 1.001220 machine units and it does it, generating as many pulses as it needs to do that [648] right [649] hal<->driver is 1.001220 [650] we need not know how many pulses it made, thats the devices resposibility [651] the driver knows that 1.001220 is 2543 pulses, and makes that many [654] the device just needs to report back its position in machine units [655] nods [656] encoder counter knows that 1234 counts = 1.001220 inches [657] But now you are back to exactly the same problem of multiplying all sorts of values in the ini by hand. [658] servo cycle difference equations and digital filters will be using awfully tiny numbers [661] no no no .. [662] les: they'll be using tiny floats [663] the ini is in MM or M or MICRONS, whatever you decided [664] ray__: if ini says "config_units = MM" then input_scale is counts per MM [665] Right but to make a machine accel at 20 ipm^ you got to change the number [668] which number? [669] Accel [671] accel would be in mm/sec^2 [672] nods [673] or 20units/sec^2 [677] Righ. But then it does not work for someone interested in inches. [679] define "interested" [680] then set config in INCH then [685] machine builder sets config units, and sets accel, backlash, scaling in those units [686] Now if you want mm you've got to change all those things in my post this morning. [687] if you set config values in MM it rather assumes they are the units you like working in for [690] if user wants to see things in a different unit, they change part and/or display inits only [691] ray__: why? [692] config units would _never_ change in the life of the machine [693] nods [694] "cause that's the way it's always been done. [697] what has? [698] emc should use linear units. [699] really any conceivable arbitrary unit should be cofigurable to the user without writing code [700] that's cause emc1 only has 1 "units" [701] les: for part and display units I agree [704] for config units, maybe [705] for most people they would choose config, part, and display from a predefined list [706] one (or two) list entries should be "custom" where they can specidfy the name and the conversion factor to any other unit in the list [707] ray__: we are talking about the units used to define the ini, purely for accels, velocities and axis lengths, not the USE of the machine, that is free to chnaged onthe fly between whatver units you like [708] so they can say "custom unit "blarg" = 0.125 mm" [711] yes [712] nods [713] Gnats Elbow units. [714] then if they want, they can set display units to balrgs [715] robin_sz:  I've got that now. [718] okie [719] picnet: if you want to catch up .. [723] no idea, robin_sz [724] watcher: logs? [725] http://www.quacky.co.uk/~robin/watcher.log [726] I agree that there is a problem with the use of units in the ini.  I'm not so certain what the correct answer is. [729] that's why we're talking ;-) [730] the answer is : choose a unit from a list and stick to it. [731] we don't need to decide this todday [732] give them a big enough list ... [733] agrees with robin (but allow them to define one custom list entry) [736] suppose the commanded move is not an even multiple of steps/counts. Does the driver round off to the nearest attainable position and report that back, or does it keep the remainder in it's own local storage and report back that it completed the whole move? [743] there are probably two drivers involved [744] one for output one for feedback [752] it just has to be done in a way that quant. error does not accumulate [753] step/volt gen & encoder - right [754] error won't accum [755] say encoder steps are .1 [756] feedback will go 0.1, 0.2, 0.3, etc [759] if you ask the pid for 0.15, it will jitter from 0.1 to 0.2, unless you use deadband [760] if you use deadband, it will go to either 0.1 or 0.2 and sit there [761] ok [762] it would be the same if encoder steps were 0.123132351 [763] Deadband always involves error. [766] right, but it doesn't accumulate [767] You must be certain that you refer back to a pre-deadband value each time you compute position. [768] I was just wondering whether the error was passed back up the line in the feedback [769] I made that mistake on a spreadsheet once. [770] the encoder counter module keeps counts as an integer, and converts to float each time [773] well encoders are integer sevices so just round up or down will pop position to one or the other [774] devices [775] Is this a good point to switch subjects? [776] yeah - the encoder must say position_int += 1, not position_float += 0.1231 [777] I think so [780] wont mention backlash. [781] Automake [782] yes, I think we've about killed units for now [783] autoyuck [784] let's get rid of it [787] so far emc2 doesn't use it, and I won't add it unless forced to [788] It doesn't work - and should be in a branch. [789] Why not make it work? [790] OH, you mean emc1? [791] shuts up [794] throw the tp in that brach as well... [795] I was its original proponent. I wanted to solve the Makefile problems. If it's not working out though... [796] the emc2 config works. [797] IF EMC1 is to use something, let's port the emc2 config across [798] emc2 is simpler tho [801] yup [802] That sounds like a good plan. [803] only 2 RTOSs, plus GTK to configure [804] and it relies on the rt configs. [805] My only point is that emc* should build with a ./confgure;make;make install (maybe a make depends in there if needed) [808] mshaver: yes [809] much of the mess we have is down to the rcslib def files. [810] Well, that was reletively non-contentious! [811] ./configure ; make ? [812] ./configure figures out which RTOS you have, paths to include files, etc, and writes it to Makefile.inc [815] I can do an rcslib (rt & non-rt) compile in under two minutes. [816] then make reads Makefile.inc to do the compile [817] and presumably a ./configure rt=../rtai-13 etc can be done for those people who have more than one to play with [818] Oh yes [819] yes - rtdir=foo [822] everybody happy. [823] has three or four to play with... [824] and they all lived happily ever after... nect subject? [825] coffee ? [826] If we could in include some soothing music or a suggestion that the end user take certain stress-reducing medication it might help. [829] ;-) [830] How about some chicken soup... I am setting here in a flu induced haze trying to follow..... [831] end_user_meds= xanax? [832] subliminal messages = "you are getting very sleepy" [833] I think coffee is in order, John you gotta go soon? [836] SteveStallings: good plan! [837] then a loud BEEP to wake them when done [838] not really [839] I've gotta admit that we did cover a couple of topics during the first hour. [840] wife's home, but I have some time before she puts me to work [843] what else did matt mention as agenda items [844] ? [845] RTAPI & HAL [846] I'll go put some wood in the stove and then I'd love to hear your thoughts on where we're at with the HAL/RTAPI/EMC2. I was very interested in your post describing the actual stepper moves you did with the encoder, etc. I wanted to write a shell script that would set this up on my machine. [847] RTAPI and HAL are rather big topics [850] perhaps I should do a "status report" email to the lists, we can get more specific next week? [851] but if anyone has questions, fire away [852] Is it too soon to start planning for NAMES 2004? Is anyone mentioning EMC2 to NIST? [853] never too soon ;-) [854] no mention of emc2 except what appears on the list [857] will try to get to Detriot [858] I did talk with Fred P about working out a way to put motion and IO commands on the interpreter stack so that we can implement tool changes that require motion during. [859] my wife is in Chicago the same weekend - I might miss Saturday, but I'll definetly be there for Monday [860] q1: Is cvsroot/emc/rtapi the same as cvsroot/emc/emc2/src/rtapi? [861] more or less - emc2 is live and updated, rtapi is dead [864] Re EMC-Monday.  I'm still looking for a better meeting place. [865] although cvsroot/emc/rtapi might be used as a sandbox for some more radical ideas [866] good idea paul [867] should get some of this ioctl stuff committed [868] I keep hoping you'll lose interest in it [871] ;-) [872] I have some general questions about the emc project [873] shoot [874] far from it - I see it as a very good way of queuing messages for other parts of emc2 [875] emc2 that is [878] Sounds like a good topic, les [879] can it have: [880] servo support, stepper support, a HAL, pidff, quintic, and notch/lowpass? [881] yes, yes, yes, I think so, dunno, probably [882] pidff is feedforwards on the PID loop? [885] and adaptive resonance control....? [886] notch/lowpass is just to adjust phase margin much like an op amp [887] most of what you describe sounds like dig signal processing [888] I want to do adaptive resonance...but [889] HAL is _very_ much oriented towards that [892] you can add blocks, re-route signals, etc [893] so YES [894] onw would have to sove big matrices each cycle in rt [895] if someone writes said blocks, HAL has the hooks [896] jacobeans [899] A side note respecting this: [900] I need to do some "intro to hal" docs - it is far enough along that you could play with it les [901] cool [902] gotten bogged down in halscope, but that will be needed for playing [903] you guys have the programming skills... I just think about the math in traj planners and such [906] I was talking to FredP yesterday and he said that funding out his way wasn't looking so good. [907] segmentqueue is in rogier's court...fred does not understand his code [908] ouch - if fred doesn't get it, what hope have we mere mortals? [909] Going to need Fred to explain some of the math involved in the trajectory planner [910] sadly this is so emc1 specific that it will not be useful for emc2 [913] It's not panic time yet, but it's remotely possible that the whole MEL could (with the exception of the meter & kilogram) uh, evaporate. [915] well paul the math in the code is wrong [916] that's the bottom line [917] les: you math, me code - we'll get there eventually for emc2 [918] My point is... [921] I don't even want to try to understand it in emc1 [922] I can do a traj planner [923] sorry matt [924] that we need to gain the understanding of what we have in emc1 sooner rather than later. [925] If it is reusable that is. [928] because there might not be a later? [929] I dread reimplementing emcmotcontroller() [930] It's tough Matt... I have been scouring tc.c and tp.c for a workaround while I wait for rogier [931] much of emc1 is reusable, but there is some real screwball coding in there [932] really hard to follow [935] just too many function calls [936] mshaver: emcmotController is a fairly simple state machine. [937] that;s another point - we need to separate the what from the how - the algorythm from the code - magic from the rabbit - ,etc. [938] right [939] are the "canonical motion commands" well documented? [942] in the source code ? [943] no [944] anywhere - code, papers, whatever [945] (silly question really) [946] I mean the pid math kind of stuff - perhaps I have the wrong function name there [949] they are really the interface between the g-code interp and the motion planner, aren't they? [950] pid math is no big deal - out with the old, in with the new [951] yes [952] yea, for you guys maybe! [953] yes pid is really just a few lines [956] mshaver: Did we ever get a definitive answer to GPLing the emc/rcslib code ? [957] I have a pid loop in hal, it's self contained, les or someone could probably improve it, but the point is that it is well isolated from everything else [958] goodness. [959] break anything into small enough chunks and you start to understand it [960] well the only good stuff to cde is feedforward (also only a few lines) [963] and a phase margin filter... a double loop. [964] les - we should talk later about pid [965] ok [966] it is trivial pretty much [967] the planner gets complicated though [970] take a look at emc2/src/hal/components/pid.c [971] "planner gets complicated" - understatement of the year [972] I am on mlrc so i will have to check it later [973] haha [974] paul_c: basically, we can put gpl notices in the code, but it doesn't gpl the work of Fred & Will. However, if others improve this gpled version then anyone who wants to use it as public domain code would have to separate the gpl parts from the pd parts. [977] Suggest we follow EMC-Monday with an EMC-Coding week in some remote part of the world. [978] after a couple passes thru the code, they'll never be able to separate it out [979] Tiger? haha [980] Crystal Falls ? [981] presumably that then prevents Fred and Will from contributing? [984] fred did that already [985] Wanna use my house.  It is usually above zero that time of year? [986] jmkasunich: That's the whole idea [987] up right ray? [988] There are a set of cabins across the lake we could use. [991] I'd have a hard time getting away for a week, let alone bringing along my PC and hardware/test equipment [992] heck there are prob cabins ON the lake [993] Might still be able to ice skate her. [994] robin_sz: Not at all it's just that their lines of code are still pd. [995] I've got plenty of PC's and test equipment. [998] mshaver: im not sure you can have some lines in a file GPL and some not [999] The whole program is eithe r GPL or not at all.. [1000] exactly [1001] I really don't want to get into the license thing - we'll be here all day. [1002] emc2 is GPL, period [1005] if we have to use some PD code, we can - after all, it's PD [1006] once in there, the combined work is still GPL [1007] right [1008] so my original point is .. can Fred and Will contribute to GPL'd projects during work time? [1009] dunno [1012] doubt it [1013] well .. just checking :) [1014] Yes.  Will did it already with some of his graphing stuff. [1015] Some of the addon tools are GPL based [1016] might be a moot point though, if their boss has them doing other stuff [1019] robin_sz: Yes, AFAIK it's done all the time. [1020] are you going to use the emc g code parser? [1021] right, then its no problem .. [1022] onwards McDuff .. [1023] les: yes, that part is one we will reuse for sure [1026] There is even a note on the net that allows employees to work with gpl. [1027] good.. that part works very well [1028] NSA works on the kernel! [1029] fine . [1030] lets it rip .. [1033] and NASA contributed many of the network drivers... [1034] We probably need more meetings like this. [1035] for sure [1036] seemed to work ok [1037] I wonder how the kernel developers coordinate their work. [1040] mailing lists - busy ones [1041] The best thing would be to get everyone together, but we'd all go broke. [1042] we should do this every week [1043] yes [1044] request tracker is good for bug/feature tracking [1053] commit mailing list gives an idea of what people are up to [1054] If we are at all serious about trying to find a retreat for EMC-Tu-Sat, I do know of some camps within a couple hours drive of detroit. [1055] I think emc2, being more compartmentalized/modular should ne easier to work on in a distributed way. [1056] I hope so [1059] http://www.bestpractical.com/rt/ [1060] We also need to have some targets to aim for with a time scale... [1061] yeah - so far it is "work on it when I can, it's done when it's done" [1062] Can anyone here except perhaps ray, me les & Paul afford a week's vacation (I'm unemploed basically so I've got the time) [1063] paul_c: What sort of units would we use for that;) [1066] It will not be like NAMES, but there will be a CNC gathering at the Cabin Fever show 17 and 18 January in York, PA. [1067] would like to have something sort of working at NAMES [1068] I get "unscheduled vacations"... [1069] I _might_ be able the take a week, but can't really afford to fly anywhere [1070] is facing redundancy for certain in the new year. [1073] and I'm saving my pennies for a G2003 [1074] I am trying to make a living with an emc equipted machine so I am preety keenly interested [1075] likewise ... [1076] almost at my wits end too [1077] because I am running at 1/4 speed [1080] try that file ... it shold be a lot smoother [1081] I will [1082] agenda for next meeting? [1083] If you guys could live with rustic.  I know of a place within two hours of Detroit. [1084] It has cabins and a nice lodge. [1087] is that anywhere near Birmingham? [1088] rustic = outhouses? [1089] ha... I can do rustic [1090] Nature trails and such. [1091] trails are fine, just like running water and showers [1092] No but if Paul stuffs you in his luggage? [1095] let's try to figure out how to import/rewrite enough of the emc1 into the emc2 to get it moving (at least a little). [1096] right .. [1097] does it have ASSL or Cable ? [1098] Does rustic include power and internet? [1099] I'd have to check on connections. [1102] like understanding the cannonical functions? [1103] Yes there is plenty of power.  Some of the cabins are even heated. [1104] Even swimming for the polar bear club. [1105] Next meeting agenda idea: task breakdown for emc2 development? Perhaps getting everyone up to speed on what's there presently and how to write compatible modules. [1106] yeah [1109] needs to write some doc [1110] I have to go deliver cnc carved stuff... will you be back on same time next week? [1111] that's the plan - we'll post time on the lists [1112] (especially if it changes) [1113] ok off to the retailers for me... thanks and bye [1116] bye les [1117] We need to spread out this work in a way that: 1. Takes advantage of everyone's individual strengthes, but 2. Doesn't require everything to be finished before anything works. [1118] seeya Les. [1119] right [1121] I've been thinking about a HAL demo - move a GTK slider, and it moves a (possibly imaginary) motor to track it [1124] I could have that done by mid-week if I'm lucky [1125] people could play with it to come up to speed [1126] Nothing personal, John but I'd lke to see you concentate on the central code. [1127] That's why I wanted to replicate your experiment. [1128] the demo would be nothing more than a commented version of the experiment [1131] if you have a jog wheel, I can drop the GTK slider part [1132] (that would be the only new code - and not to hard anyway) [1133] Gotta get going, Thanks to all. [1139] One other thing too - If ray is going to be able to contribute in the GUI dept, we need a tcl gateway/interface. Once I get really up to speed I'll try to make that work. [1140] sounds good [1141] Is there a definition of what EMC2 is to be posted anywhere? Does it still include RCSLIB stuff? [1142] it will include only what it absolutely needs from rcslib [1143] emc2 should (will ?) use rcslib [1146] I've got a few impending domestic disaters to tend to for a few moments, but I'll stay connected. [1147] only posted definition is the README in the emc2 directory [1148] (it's rather vague, but could be updated) [1149] Is there any other IPC method besides rcslib that we could use? [1150] For me, the one-to-many communications either locally or distributed, is one of the strengths of EMC [1153] Local IPC can be done with exisying libs [1154] OK, but we move the parts of rcslib we use to the emc2 tree - no dependency on the big rcslib tree [1155] that does what paul just said? [1156] rcslite [1157] I _really_ want to keep the dependency list short and simple [1160] There are a couple of IPC libs that support remote comms [1161] but they tend to be rather large... [1162] large compared to rcslib?  wow, that's large [1163] 30Meg [1164] paul_c: is disc space a problrm? [1167] gaack [1168] only on embedded systems [1169] complexity is a problem, and size ~= complexity [1170] no ... [1171] rcslib can be reduced to les than 80 files [1174] and compiled in under two minutes [1175] some big things are simple to use ... [1176] to use, yes [1177] to understand, modify, and fix, no [1178] I use gcc, but must rely on others to make sure it works [1181] right [1182] why should the compiler make any difference ? [1183] same with GTK, I guess... [1184] so .. same applie to ther lumps [1185] both gcc and GTK have well defined and documented interfaces [1188] 80 files?! [1189] that;s it? [1190] or there abouts [1191] so I don't have to understand, modify, or fix them [1192] if rcslib were well documented, same would apply [1195] at present, that's a big if [1196] (but it's not) [1197] mshaver: Remove any legacy code & non-linux plat stuff, and the code shrinks [1198] I never did change my ssh key to get the stuff on quacky [1199] jmkasunich: you mean it's not documented, or it's not a big if [1202] i thought you rwe [1203] it's not documented [1206] I plan on moving some of the quacky stuff over to SF during the xmas break. [1209] yeah, time to go public anyway [1210] trying to document it in the process... [1211] it always seems to come back to documentation [1212] as well as writing some test routines. [1213] doxygen is your friend ... [1216] only if the good stuff is inside the source [1217] the doxygen gives low level detail, but not a high level overview [1218] and doxygen is of limited value in pure C [1223] seems like the "meeting" is winding down...  anything else of general interest?