10:57:15 logger_devel has joined #emc-devel 10:57:15 topic is: "Welcome to the Enhanced Machine Control development place. | Regular Developers' meetings 24/7 !" 10:57:15 Users on #emc-devel: logger_devel alex_joni cradek SWP_Away SWPadnos_ LawrenceG @ChanServ 11:18:42 [Global Notice] Hi all. Okay, here goes. In just a few moments, a rather large main rotation server will be restarted. It will be followed by another, and another, and then by smaller servers. Please bear with us. 11:26:35 alex_joni has quit 11:26:35 SWPadnos_ has quit 11:26:35 LawrenceG has quit 11:26:49 LawrenceG has joined #emc-devel 11:27:09 alex_joni has joined #emc-devel 11:27:28 SWPadnos_ has joined #emc-devel 11:27:31 SWPadnos_ is now known as SWPadnos 11:30:37 SWPadnos has quit 11:30:37 alex_joni has quit 11:30:37 LawrenceG has quit 11:30:37 SWP_Away has quit 11:30:37 cradek has quit 11:30:37 ChanServ has quit 11:31:06 cradek has joined #emc-devel 11:31:06 SWP_Away has joined #emc-devel 11:31:09 SWPadnos has joined #emc-devel 11:31:09 alex_joni has joined #emc-devel 11:31:09 LawrenceG has joined #emc-devel 11:40:40 ChanServ has joined #emc-devel 11:44:31 SWP_Away has quit 11:44:31 cradek has quit 11:45:45 SWP_Away has joined #emc-devel 11:50:02 cradek has joined #emc-devel 11:57:04 SWP_Away has quit 11:57:36 SWP_Away has joined #emc-devel 12:35:10 [Global Notice] Hi all. We've completed our upgrade of the network to add a patch which should help us cope better with clonebots for the time being. Meanwhile, we can't stress enough---if you can't connect to freenode, please CHECK OUT THE WEBSITE NEWS PAGE. There's currently a summary of the events of the last 18 hours there; please take a look at http://freenode.net/news.shtml for information on what happened and how it will affect your access to the n 12:36:07 [Global Notice] [...your access to the network.] Thanks for your patience and understanding, and thank you again for using the network! 12:41:14 morning 13:04:52 alex_joni has quit 16:03:31 alex_joni has joined #emc-devel 16:29:25 rayh has joined #emc-devel 16:31:25 Any problems with me adding README files to the existing configs? 16:31:31 NONE 16:31:32 ;) 16:31:43 also .ini's if you'd like 16:31:55 a stepper/stepper_mm.ini would also be very appreciated 16:32:28 Did we get to the point where we allow more than one ini in a config directory? 16:32:37 sure 16:32:45 that was the plan all along 16:32:56 but on install only one will get copied over I think 16:33:01 and jmk's configurator will make a simlink to the chosen one. 16:33:02 or at least only one will be default 16:33:12 I think so .. 16:33:25 Okay. 16:33:32 right now the old emc.ini is in stepper/stepper_in.ini 16:33:58 okay. 16:38:41 can I commit a whole group of files after I've added them? 16:39:33 sure. I answered my own question. 16:40:14 yup.. you can 16:40:29 just make sure you don't have other changes you don't want to commit 16:45:54 going to take a nap.. was up too late last night 16:46:00 and too early up this morning 16:47:00 catch you later 16:50:12 Hiya Ray 16:50:56 Hi SWP_Away. Get some sleep. 16:51:03 ? 16:51:04 already did, thatnks :) 16:51:07 thanks 16:51:14 about 14 hours actually 16:51:39 I mentioned the change to ppmc.c to jmk and he thought you were going to commit it. 16:51:57 brb bread machine is beeping at me. 16:52:02 yep - I think he was in a bad mood last night, so he just said "let JonE deal with it" :) 16:52:05 ok 16:54:45 Okay. So you gonna put the number changes in? 16:55:04 yep - I'll do that. there's another change to make as well though - I'll test that now 16:56:29 k 16:57:59 question for you. 16:58:04 ya 16:58:36 univstep, univpwm, and univppmc will all share a common xx_io.hal 16:59:02 not sure about the ppmc - isn't that a servo driver? 16:59:10 or is that the cage system? 16:59:22 they all look like servo drivers 16:59:29 to emc and hal 16:59:57 the I/O for the USC and UPC are the same 17:00:37 if there's a different board for some other unit (the ppmc), then it might need different IO 17:00:47 Yes. The ppmc is a bit different. It uses 8 IO in any config. 17:01:01 so ppmc is out of this 17:01:24 hmmm. does it only have 8 I/Os (vs the 16 in and 8 out of the USC)? 17:01:53 since io.hal is the only common whole file between upc and usc I suppose separate files is better than one. 17:02:04 directories sorry. 17:02:12 * rayh needs more coffee. 17:02:13 actually, the PPMC I/O card and the PPMC DAC cards aren't supported by the driver at this point 17:02:27 the encoder card is though 17:02:52 at least, it'll get encoders exported if it's detected. I don't know if it'll work ;) 17:03:17 Okay. We leave the ppmc out completely for now. 17:03:22 yep 17:03:42 I think jmk wants jonE to actaully help a bit, so we've got a framework for him to put the code into now 17:03:53 I've got a univstep config about ready to go here. 17:03:57 cool 17:04:18 I'm sure that it is different from jmk's so should I wait. 17:04:40 the config files? 17:04:55 the one you sent me was just about complete - is jmk working on something else? 17:04:58 I'll make all the filenames conform univstep.xx 17:05:10 I think that he said he had one running. 17:05:14 ok 17:05:57 one thing though - the estop interlock isn't there unless you use ladder 17:06:46 I thought I put a loopback in HAL. Let me look. 17:07:10 I know the loopback is there, but I'm not sure that actually "works" 17:07:46 though with the USC/UPC, it'll shut down regardless of what emc thinks anyway 17:07:59 alex_joni has quit 17:07:59 newsig EstopSense bit 17:08:00 newsig EstopWrite bit 17:08:00 linksp EstopSense <= ppmc.0.din.15.in 17:08:00 linksp EstopSense => iocontrol.0.emc-enable-in 17:08:01 linksp EstopWrite <= ppmc.0.dout.07.out 17:08:01 linksp EstopWrite => iocontrol.0.user-enable-out 17:08:16 It loops back based on board pins. 17:08:19 ok - the estop sense will be a little weird then 17:08:39 so it should get out of estop as long as the two jumpers are on the board. 17:08:42 whenever SSR8 is off, input 15 will read "estop" 17:09:08 yep. 17:09:24 so you can't tell the real state of the external estop chain until you try to turn the system on 17:09:40 (which is why jonE says you should connect estop to input 14 as well) 17:11:51 I'm about to commit a change that works for a single board, but may break multiple boards - can you test multiple boards yet? 17:15:00 I don't see that the jumper between 15 and 14 does anything. 17:15:21 Sure. I just have to edit the source to look for the second parport. 17:15:26 it doesn't now, because there's no external estop connected 17:15:35 no - I mean on one parport 17:15:39 by chaining boards 17:15:45 As listed above, the tkemc does display the external estop condition. 17:16:08 hook up a switch and set up halmeter 17:16:16 oh. I don't have the cards nor headers required for such a test. 17:16:18 to look at EstopSense 17:16:24 ok 17:16:37 that's what the jmk change was for (the one I'm reverting) 17:16:38 I can and have tested a usc and upc at the same time 17:17:04 sure - add "cfg=0x378,0x278,0x3bc" to check all 3 ports 17:17:05 on different parports 17:17:22 but how about b400 17:17:23 it seems to pick up the first bus automatically 17:17:36 I was going to try my PCI parallel port card as well 17:17:47 that's what I was using. 17:17:50 I installed the dual PCI parport card ans the m5i20 yesterday 17:18:01 I want to run some I/O benckmarks 17:18:16 Great. 17:18:30 hey - were you running on a PCI parport when jonE had you cut the pin13 wire? 17:18:40 I wonder if you'll have any problems with estop with the dual parport. 17:18:53 It failed both ways. 17:18:56 yes - you can't have multiple writers to the EStopSense pin 17:18:59 ok 17:19:09 you may have a PCI-connected parport in your chipset 17:19:16 but then this is the athalon64 3300 17:19:26 A64 - cool 17:19:48 you could have multiple writers if you use an and or or block. 17:19:53 I'd love to try RTAI on my dual opteron, but the 64-bit and SMP issues are holding me back (ie, I don't know if there are any :) ) 17:19:54 Did that and it works fine. 17:20:06 yes, you can combine them with logic 17:20:22 the estop component really should be called a latch 17:20:26 Paul tells me that dual core is a problem for rt. 17:20:45 yes - RTAI has SMP support, but I'm not sure how good it is 17:21:11 if you can control it well, then keeping all RT tasks on one CPU (the one with direct access to I/O) is a good thing 17:21:11 There is a great posibility that rt interrupts happen during the exchange of floats 17:21:28 between CPUs? 17:21:39 Yep that would be my solutions. rt on one proc and user on the other. 17:21:57 floats are an atomic transfer - they're only 32 bits. doubles are either 64 or 80 bits, so they take multiple transfers 17:21:59 but still working both sides of shmem my trash it. 17:22:09 nope they are NOT atomic. 17:22:21 supposed to be but ... 17:22:27 which - floats? 17:22:38 yes. 17:23:15 they are atomic on rt side but rt can interrupt a supposedly atomic in user space. 17:23:28 getting a result from an FPU register to memory isn't atomic (I think you have to transfer it to a normal register first), but the store to memory is atomic 17:23:43 but what do I know of the truth or even comprehension of what I just typed. 17:23:54 so you can't have a half-stored float in memory 17:23:56 heh 17:24:06 anonimasu has joined #emc-devel 17:24:24 I believe this was the problem Paul faced with the 4xx bdi. 17:24:38 doubles are a different story, as I mentioned 17:24:40 and it's eating of stuff far away from emc. 17:24:46 and most everything in emc is a double 17:24:58 but not in HAL 17:25:04 rayh: I don't think that was the problem 17:25:24 I could send a log of my recent conversation with him. 17:25:49 rayh: I'd be interested to see that 17:25:51 I would like to see it sometime - he's asmart guy and the rest of us may be overlooking something 17:26:21 I'll ask him if he minds that I share it. 17:26:59 ok. or even better would be to write a short paper about the trouble, and we can try to come up with solutions (or rebuttals) to the problems he points out 17:27:27 k 17:27:39 in his copious spare time ;) 17:28:59 I want to do a bit more testing before I add univstep to cvs. 17:29:18 I believe that I can reduce ferror and min_ferror more. 17:29:41 hmm - univ_motion.hal is loaded after univ_servo, and it overrides the FF1 parameters 17:29:55 sorry - usc_motion.hal 17:29:55 0x0804832b : mov 0xc(%ebp),%edx 17:29:55 0x0804832e : mov 0x8(%ebp),%eax 17:29:55 0x08048331 : mov %eax,(%edx) 17:30:19 What I saw the other day was ferrors in the e -4,5,6 and settings in the e -2 17:30:25 here's a store to memory in void f(float a, float *m) { *m = a; } 17:30:33 where m is a pointer to a malloced region 17:30:40 it shows that the mov is atomic 17:30:45 yes - that's a float. check a double 17:30:51 (if you don't mind) 17:30:56 but the issue is floats, right? 17:30:58 Yes it does with values from the ini file. I'd like to keep it that way. Would you do something different. 17:31:13 no - I'm pointing out what the hal file does now :) 17:32:08 0x0804833d : mov 0xfffffff8(%ebp),%eax 17:32:09 0x08048340 : mov 0xfffffffc(%ebp),%edx 17:32:09 0x08048343 : mov %eax,(%ecx) 17:32:09 0x08048345 : mov %edx,0x4(%ecx) 17:32:15 double is definitely done in two steps 17:32:22 yep - so I thought 17:32:28 but the issue is floats, right? 17:32:45 actually, another interesting thing to see is what happens if the numbers are in float registers 17:33:07 ah. so we should remove the setp .. FF1 from univstep_motion.hal. 17:33:19 like void f(float a, float b, float *m) {*m= (a*b); } 17:33:26 rayh: yes 17:33:49 cradek: then the same thing with doubles 17:33:50 I was thinking it would be nice if a [AXIS_x]INPUT_SCALE call would fail gracefully. 17:33:58 how do you mean? 17:37:37 I was wrong, a lot of stuff in shmem is doubles 17:37:49 then that might be a problem without locking 17:38:00 yes - the emc structs use doubles almost exclusively 17:38:07 paul kept saying float when he was talking about this, but he must have meant double 17:38:10 but HAL doesn't use them 17:38:14 that may be 17:39:18 but this is irrelevant to the problem where emc was messing up non-rt fp 17:39:36 that was an emc but or miscompilation 17:39:46 yes - that would be an incorrect FSAVE/FRESTOR kind of thing 17:39:47 (something was leaving a value on the fp stack) 17:39:52 right 17:40:07 jepler proved that with his test program 17:40:17 it seems likely that it would be an emc task that wasn't marked as using FP, but that actually did 17:40:32 agreed 17:40:49 he never would say what he did to fix it, except maybe he said he recompiled something 17:41:00 he was very evasive for some reason 17:41:06 there weas a lot of that going on 17:41:19 "I know how to do that, it's easy" full stop. 17:42:21 rayh: if you think he's found serious bugs in the basic emc architecture, I think we should investivate promptly. 17:45:59 phone 17:47:41 Okay. That guy just got his 4th axis running with m5i20. 17:47:47 slick 17:48:01 one more death defying act. 17:48:17 maybe I'll make driver for my rotary axis this weekend 17:48:19 And that guy claims to be the first to implement motion from a PC. 17:48:29 which headers are used on the m5i20? 17:48:48 headers? 17:49:07 yes - the m5i20 has 3 50-pin headers on it 17:49:17 oh yes. 17:49:36 he is using the first header to a 7i33 analog card. 17:50:05 ok - that's the default configuration in the emc driver? 17:50:14 (and FPGA code supplied with emc) 17:50:19 I've got the same here to their pwm motor amp card. 17:50:34 Yes. PeteV was the guy that did all that. 17:50:40 yep 17:50:57 When you start the m5i20 configuration halcmd will show you all the pins. 17:51:22 You only need to watch the led's on the card to see that they all change from red to green. 17:51:57 I think my card only has 8 LEDs on it 17:52:31 and they're on the bottom side of the card (it's plugged into a riser card which is plugged into a motherboard on the back of a touchscreen) 17:52:32 Right. I used a beer coaster (aka dead cd) upside down to watch those. 17:52:36 heh 17:52:45 I've got one or two of those 17:53:12 well - I just completed a run of CDS with the changes hal_ppmc driver 17:53:44 it's quite sensitive to the ini/hal file settings though - it didn't work with the stock univstep config (from CVS last night, I think) 17:54:21 I'm looking at what's different between that and the config that works (basically the one that you sent me) 18:01:44 Is there a stock univstep in cvs? 18:02:10 I think there's something - not sure what state it's in 18:02:12 There should really be no need to change tuning settings for univstep. 18:02:18 (except that it doesn't work ;) ) 18:02:44 Right. 18:02:55 * rayh goes looking at sf 18:04:12 this may just be an earlier copy of your stuff -I'm not positive that I got it from cvs 18:04:32 nope no univstep stuff yet. 18:04:43 ok - then it must be me ;) 18:04:47 May have been my earlier tarball to you. 18:04:52 that could be 18:04:53 That did not work. 18:05:03 I'm just looking at the differences - there aren't many 18:05:32 interesting to watch fe trip point and fe on arcs and such. 18:07:19 hmm - do you think I should add a "delta" pin to the encoders? 18:07:46 I did for testing, and it was useful. it's a reasonable representation of velocity as well (at high speeds) 18:07:52 It certainly makes for some fascinating viewing. 18:08:38 I'm thinking a wiki writeup on "how to do delta" would be excellent. 18:09:18 yep - there are a lot of p"probing" options available with the various available blocks 18:09:29 It costs almost nothing in compute power so perhaps we should for all the sample servo systems. 18:09:34 you can do differences by usinga summer block, and setting one input scale to -1 18:10:25 Yes you can... 18:11:02 and then with a few motions we can create an autotune system. 18:11:34 but not for 2.0 release 18:11:54 nope 18:13:01 I see that following error trip point drops off almost instantly when an axis stops 18:13:24 yep - it's using the MIN_FERROR->FERROR formula 18:13:25 but any ringing or overshoot takes a bit to settle. 18:23:12 hmm - you know - that should be a problem 18:25:10 duh - I found the problem with the univstep from before 18:25:22 no - wait, that shouldn't be it 18:44:39 do I need to set the time and tmax params for a sum2? 18:45:37 mope - those are outputs 18:45:48 the TMax is writable so you can reset it o 0 18:45:51 to 0 18:46:53 ah sorry. 18:51:13 perhaps 'nother dumb one. both 18:51:15 those are supposed to be for checking max execution time 18:51:15 02 float R- 4.05995e-05 axis.0.f-error 18:51:16 02 float R- 2.22069e-03 axis.0.f-error-lim 18:51:27 also read only 18:51:34 those show the current ferror, and the limit 18:51:46 as it changes with the speed formula 18:51:46 are params and I want to connect them to sum2 18:51:54 Right I got that. 18:51:55 you can't connect params 18:52:02 only pins 18:52:12 I can to either halscope or halmeter. 18:52:24 another big failure of halcmd 18:52:28 ??? 18:52:36 no - it's a HAL thing 18:53:03 big failure of HAL??? 18:53:06 software can look at pins, params, and signals, but only pins can be connected to signals 18:53:20 no - params aren't meant for lots of updating 18:53:36 they're for settings and status - not "realtime" stuff 18:54:00 keep on with the excuses... 18:54:06 I'm all ears 18:54:17 jmk was considering changing things in emc3 so that there are no params, only pins 18:55:40 the block constant says that it can make a param available on a pin. 18:55:48 how would that work? 18:56:06 yes - you set the param, and the output pin of the constant block has that value 18:56:22 it's a block with no input pins, and one output pin 18:58:02 so it does not track changes in a param only the setp commands to a param? 18:58:29 params don't chenge, except via setp or code which is internal to the component that exports them 18:59:36 changes caused by "code which is internal to the component that exports them" is exactly what I want to watch. 18:59:52 and that is a BIG nfw? 19:00:22 can scope show the diff between signals? 19:00:48 nope 19:00:55 unfortunately 19:01:48 Okay I'll just write this up to a big failure in architecture. 19:02:20 um -you're trying to use testing tools, and you can't look at something - that doesn't sound like a huge failure in the architecture to me 19:02:45 it's an annoyance, but not a major architectural problem 19:03:24 (this is like not having a differential probe for your oscilloscope, then complaining to the manufacturer about not having isolated grounds) 19:05:07 so - try that update, make sure I didn't break anything ;) 19:05:42 gotta run - it's time to clean the garage, so I might have achance of parking indoors this winter :) 19:06:01 thanks steven. I'll test that right away. 19:06:15 cool - I'll be around, and check back from time to time 21:32:28 alex_joni has joined #emc-devel 21:33:22 hello 21:43:36 alex_joni_ has joined #emc-devel 21:53:49 alex_joni has quit 21:53:56 alex_joni_ is now known as alex_joni 21:56:06 alex_joni has quit 22:14:02 who knows if these are bugs: 22:14:10 when you turn machine off, spindle stays running 22:14:18 when you switch to mdi mode, spindle stops 22:14:54 err, manual not mdi 22:16:16 logger_devel has joined #emc-devel 22:16:16 topic is: "Welcome to the Enhanced Machine Control development place. | Regular Developers' meetings 24/7 !" 22:16:16 Users on #emc-devel: logger_devel anonimasu rayh SWP_Away cradek @ChanServ LawrenceG SWPadnos 22:16:48 you'd think that the spindle should get shut off when you turn the machine off 22:17:10 it does stop if you hit estop 22:17:14 but not simply machine off 22:17:15 though leaving it running has the advantage that you won't break bits as the machine coasts to a stop 22:18:15 well ESC turns off the spindle and aborts motion both 22:18:56 what is esc in the GUIs? 22:19:04 TASK_ABORT 22:19:09 (stop motion and spindle) 22:19:10 ok 22:19:38 and machine off is MACHINE_OFF or the like (just making sure that the issue is in emc, not the gui) 22:20:12 TASK_SET_STATE(machine off) 22:20:26 there are three states 22:20:36 estop, off , on 22:20:52 the off state might actually be called estop-reset, I don't remember 22:20:53 or estop, ready, on 22:20:55 but yeah 22:20:57 yep 22:21:40 I think it's more strange that switching to AUTO mode turns spindle off 22:21:50 that is a weird one 22:21:59 err manual 22:22:01 do you mean from auto, or any "mode" change 22:22:03 ok 22:22:10 dammit I use axis so I never deal with these stupid modes 22:22:25 hit f3, f4, f5 until I can jog 22:22:39 hit f3, f4, f5 until R works 22:22:44 sorry 22:22:51 so you can go between MDI and auto without affecting the spindle, but switch to manual, and it stops? 22:22:58 let me make sure 22:23:27 yes 22:23:40 going to manual causes EMC_TOOL_ABORT 22:23:42 in tkemc or axis? 22:23:47 any 22:23:52 this is not a gui issue 22:23:56 ok 22:24:33 wonder if I can run emc1... curious 22:25:02 unless you've changed a lot in the last few weeks (when you switched to emc2) I would hope so ;) 22:25:26 I'm at a different machine... 22:25:31 ah 22:25:36 not kernel 2.6, I hope 22:25:47 nope 22:26:01 emc1 does not stop the spindle when switching to manual 22:26:07 ok 22:26:13 then I'd say it's a bug 22:26:17 emc1 does not stop it for estop-reset either, so I guess that's normal 22:26:21 I'll file a report 22:26:30