Hi Imperator_ Hi Pablo how are you How is your card improving? slowly, i have soldered one of the counter chips on a adapter pcb, so i can put it today on my pci development board I suppose you will use EMC, right? emc2 to be precise. I have tryed some times ago to write a driver for emc1 and i have given it up I think HAL will be very useful for you I think the idea of HAL is very intuitive yes, my hal driver is working Hey, you have already written a HAL driver? jep with help from John and Paul it was easy Wonderful. At EMC FEST John drove some steppers with HAL. He also showed to us the halscope... it worked great yes that is very helpful I have some students how are simulating my planned machine frame, and the results are very interesting with a force of 150N from the tool the hole maschine bends only about 6um What kind of frame are you considering? Something like a gantry mill or a knee mill? knee mill ?? I will make a portal mill. So the table is moving. The gantry with a moving portal is a very flexible construction I see...So you are going to build a very strong machine. yes i want to have good surfaces also in aluminium In the case your machine performed very well, would you consider building and selling them? i don't think that makes sense. I would like to be able to do it. But if that ever happens will take a long time I guess to sell your construction ? Yes, I would like to be able to build many machines and sell them. Or to retrofit old machines... Ok then you have to make a buissenes out of it, but there are many companys how are doing that already Yes I know it is very, very difficult, but who knows. Imperator, ich muss weg gehen do you want to make a real business aout of it ore doing that in your free time Ok, see you I would like to make a real business out of it But slowly :-) good luck I have not planned to quit my job. lost connection for a while (Imperator_/#emc) what is that rayh, I never heard that (rayh/#emc) Emc is supposed to base it's actions on known values. (rayh/#emc) For example a commanded move checks current position as it plans a trajectory to the new. (rayh/#emc) A command to turn on coolant looks to see the state of coolant and estop and such while it is planning to turn on coolant. (rayh/#emc) At this level world model is not a real big thing. (Imperator_/#emc) and what has to be improved (rayh/#emc) I've heard concern among c programmers that there are to many global variables in the EMC. (rayh/#emc) I believe that these are where the world model is kept. (Imperator_/#emc) ok (rayh/#emc) I keep seeing violations of this world model in my own graphical interfaces. (Imperator_/#emc) so the world model is a big struct variable ?? (rayh/#emc) Something like that. (rayh/#emc) If you need to know current feedrate, you need to look at that part of the "struct." (rayh/#emc) Morning Steve. Morning, figured you would be ready to pounce today. 8-) Morning John morning I think.... (rayh/#emc) Imperator and I just started talking about "world model." (Imperator_/#emc) I think many of the information in that "world model"you can see on the HAL pins rayh: what are "violations of the world model"? (rayh/#emc) One example of what I consider a violation is where we reset from INI without consideration of the values currently in a global variable. (rayh/#emc) I just recently discovered that feedrate overrride is a global. basically everything is a global... :-( (rayh/#emc) I always thought of it as a local thing in the gui. (rayh/#emc) It's treated as local in both tkemc and mini. (rayh/#emc) I guess when we were writing these we never thought to ask EMC what the current value of feedrate override was. I'm not sure at what level feedrate override is implemented... I've been hacking madly in the motion controller, and "feedrate override" as such doesn't exist there - it must be implemented at a higher level If you plan to support the concept of multiple/remote GUIs, then it would seem that each GUI should not only ask, but also display the current value of feedrate override. (Imperator_/#emc) is it possible to put such things to tha HAL ??? I think it is useful, and easyer to have HAL pins not only to the Hardware, also to the GUI (rayh/#emc) You hit the nail on the head there steve. (rayh/#emc) IMO the same logic can be expanded throughout. (rayh/#emc) Since we have multiple processes working, each needs to know some part of world model. I just grepped the code - feed override is mentioned only in the rs274 interpreter, emcsh, keystick, and usrmot (rayh/#emc) At the hmi level with tickle, I've got to ask what values are. seems like part of the problem is who (what process) do you ask? different variables "belong" to different processes (rayh/#emc) Will the real world view please stand up. (les/#emc) should be a bunch of feed over ride stuff in emcmot (les/#emc) let me check les: not by that name... emcmot is rather generic... there is a variable in the structs called "scale", that seems to scale the commanded velocity, I think feedrate override modifies that (rayh/#emc) I think this is where it gets sticky, emcmot works both sides of shmem. emcmot is a mess (les/#emc) yes scale also covers pause and resume I think Ignorance displayed here... doesn't NML "know" where things are? Or do you have to specify in your NML query which process to ask? NML is message based - you would need a "get feedrate override" message if there is a central list of all available messages, I haven't stumbled across it yet in addition, NML can't talk directly to emcmot Ah.... so the issue is expanding the library of message types and doing the back end work to parse and respond to them? for all I know the message already exists... the documentation is horrible * jmkasunich is grumpy - wading thru the code until 4:30am .... and jmkasunich is rapidly becoming the resident expert.... 8-) that's scary I'm sticking mostly in the motion controller module (rayh/#emc) Seems to me that we've got a pile of variables that reflect the same concept but the problem is that _nothing_ sticks in one module... there is more cross coupling between processes than I can understand with my feeble little brain (rayh/#emc) one variable in tkemc --> one variable in emcsh --> an NML var name --> scale in emcmot --> ..... yep, exactly I'm seeing that too, as I try to halify emcmot... (les/#emc) and on to tc, tp, etc etc one variable in shmem, one in HAL space (rayh/#emc) I saw that from some discussion a while back. having the same info in more than one place is one of the seven deadly sins of programming (rayh/#emc) So where should world view reside and is it a process or a struct? question: how detailed and global a world view do you have in mind? Well, I see you guys are off on the right track. I'll go hide now while you work it out. 8-) (rayh/#emc) If you've got the NIST coffee mug there in front of you, you can see that there are levels of world model. do you want a world view that contains everything from the line of G code you're executing, to feedrate override, to the state of the limit switch inputs and step pulse outputs? no mug, but I seem to recall the 9 box dwg from fest (rayh/#emc) That's it. (rayh/#emc) Think for a moment of hal across the bottom. unfortunatley having _only_ seen the fest version, I don't know if the boxes have captions, or what each one means (rayh/#emc) There are lots of world model variables and values at that level. right - accessible thru HAL, but not thru NML, etc (rayh/#emc) You can get at any parm or value there can't you. (rayh/#emc) Most are only needed at that level. depends who "you" are, but for the most part yes GUIs would need help, an extension of emcsh to handle HAL, or something like that (rayh/#emc) You got it. The who needs the info is the quesstion. right.... having a true "world" view, where anybody can see anything, gets us to the nightmare of interconnections and cross-dependencies that we have now (rayh/#emc) Would a world view as pointers to variables rather than values of variables work? I don't see how the viewing is done as the issue I think what I want and what you want are going in opposite directions I'm looking for more compartmentalization, and *well documented* interfaces between the compartments but a world view implies no walls at all... (rayh/#emc) I think compartments are a good thing. Does namespace carry your thoughts here. (rayh/#emc) Or is process a better word. I guess I don't understand... I wish we could have had this conversation face to face :-( (rayh/#emc) I know that feeling. (rayh/#emc) I guess that i've thought of world model as a giant set of cubbyholes where we stuff values. perhaps a concrete example of what you wish to achieve with the world view will help me understand ok, does this mean that every process can see (and stuff) every cubbyhole? (rayh/#emc) The stuffing would immediately lead to disaster. (rayh/#emc) So we'd have to set up rules for stuffing. even the seeing is scary (except for troubleshooting) (rayh/#emc) Yep. I've written several of these logical workarounds where I look at a value and then send something I've got control of to affect the value of what I've been able to see. the idea of compartmentalization is that each section (interpreter, GUI, task, planner, etc) only reveals to adjacent modules the info they _need_ to do their jobs (rayh/#emc) The trouble is that by the time my workaround gets where it's going the world model has changed. for troubleshooting you do want a way to float up to the ceiling and look down on the whole thing, but normal operation should be localized (rayh/#emc) I don't see that we are thinking very far apart from each other. I like that analogy that just popped out... think of an office full of cubicles... each worker sits in his cube, and sees only a couple adjacent cubes. workflows should be set up so that each worker takes stuff from one or two others, and delivers results to one or two others the workers should _not_ interact with folks at the far end of the room, only with nearby folk (rayh/#emc) And the role of managers? the boss can float around the ceiling and look down to see what everybody is doing though (troubleshooting) role of managers - get out of the way! (when things are going smoothly they aren't needed) (rayh/#emc) Something like axis position may cross a lot of cubes. depends on what you want to do with it (rayh/#emc) Right. HMI wants to display it. (rayh/#emc) IO wants to guarantee position before some action. (rayh/#emc) Interpreter wants to change it. (rayh/#emc) As does HMI in manual mode. (rayh/#emc) Gotta run for a minute. HMI doesn't actually change it in manual mode - HMI asks the interp (or task, not sure) to change it (Imperator_/#emc) sorry what is HMI ?? human machine interface - fancy language for GUI (Imperator_/#emc) i think, the most things of the world model are still in HAL, so we are not so far away to have the world model, ore ? not true - HAL only has low level stuff... things like feedrate override, g-code, etc, are at a much higher level (Imperator_/#emc) yes but that are not so much variables the more I dig into EMC code, the more I realize that HAL only scratches the surface (or perhaps scratches the underside is more accurate - GUIs and such are the surface) (Imperator_/#emc) so maybe that has to be turend about 90 degree I'm not sure exactly what info Ray needs access to, dunno if it's simple variables or more than that (rayh/#emc) I'm back' (Imperator_/#emc) is it a good idea to connect the HMI also with HAL pin's ?? probably not for one thing, we can run GUIs on physically separated computers - HAL is one computer only (Imperator_/#emc) ok, but did anybody use this feature ?? (rayh/#emc) John's right that much of the time work is passed about between a few cubes next to each other. (rayh/#emc) NIST's idea of world model allows for this. (rayh/#emc) Different granularity of information at different levels up the coffee cup. the idea of keeping connections between cubes limited is that the fewer connections a cube has to the outside world, the easier it is to modify the contents of that cube without screwing up everything else Would it be possible to "expose" everything, not by presenting a "cubby hole" but rather by exposing (by the owner) a process by which to request a change to or a copy of each cubby-hole? (rayh/#emc) There's that "exposure" word again. if you expose everything, you have to assume that somebody will change anything sooner or later... so you're right back to dense interconnections again Power == pain. 8-( I'm not saying we shouldn't expose anything, but _all_ interconnections should be documented (rayh/#emc) Documenting is essential. for instance "this module reads 'foo', does blat to it, and puts the result in 'bar'" foo and bar are the interface, and can be part of the world view (rayh/#emc) Is it halcmd that allows a body to look at parameters and values? yes and halmeter and halscope too And the owner of a "cubby hole" can return a error code if it judges the requested change to be invalid. (rayh/#emc) Good. Then something like halcmd becomes a process by which we can expose hal values. rayh: are you talking of exposing to other parts of emc, or to a human who is troubleshooting? (rayh/#emc) Both. I have reservations about the first one... * rayh sees john clench his jaws. lol (les/#emc) I was just out doing that error log for Dave part of the reason for the HAL is to allow different arrangements of hardware without changing the higher level stuff (rayh/#emc) For the most part, the things I imagine wanting to do, and needing world model to do them will be coded into the normal relationships between modules or cubes. if GUI starts assuming that there will always be a DAC, for instance, what happens when you have no DAC? (rayh/#emc) But there will be just as normal things that happen on ocasions that step outside the ordinary wiring. if the ordinary wiring can't handle things that happen as part of normal operation, then the ordinary wiring is busted and needs fixed (rayh/#emc) I see that, and if gui want's to get a dac value, it'll need to ask if there is one. asking about the existance of a DAC is adding layers and layers of complexity, both to ask and to answer... Then there is the issue of user extensions... if HAL exposes, for example, the parallel port pins using one of its standard components, then a user can use a scripting language to manipulate the parallel port to run things like a tool changer.... without learning C or compiling code. Pause it too long... maybe Aunt Tillie should run for cover.... (rayh/#emc) To me, a part of the ongoing value of halcmd is that it allows us to expose hal values. if you write GUIs that manipulate (or even try to read) hal pins and signals that are not part of the "standard" set exported by emcmot or emcio, you are begging for bugs (rayh/#emc) Maybe there are two faces to world view. At one level, within a part of the HAL there are variables and values that known and commonly used.. emcmot will export some variables that are always there, like axis.0.joint_pos_cmd (rayh/#emc) They are available to more distant cubes if they use a process like halcmd to see them. others, like stepgen.0.step, or encoder.0.phaseA, will not always be there (rayh/#emc) I can see that. (rayh/#emc) Autotuning might be a case where we want to expose variables and write values from a more distant cube. (rayh/#emc) We can do some axis tuning from the gui now. The results are iffy at best. yeah, autotuning is a _good_ example of doing that - but autotuning is not "normal" machine operation, and I have no problem with that (rayh/#emc) Probably a difference in the meaning of normal. on the other hand, I don't think other "cubes" should be reading axis.1.motor_pos_fb - they should be getting their position feedback from the emcmotStatus structure, which is the proper interface to the higher level emcmotStatus->joint_pos_fb is corrected for backlash, the hal var is not (rayh/#emc) Proper is a good word. (rayh/#emc) Yep. and if I change the actions of the backlash comp, a higher level process that reads the hal variable might have a problem, where one that reads the emcmotStatus variable will not (rayh/#emc) Good stuff. We are seeing the sorting out of information from one level of world model to another level above it. (rayh/#emc) This is one of the things NIST sees as happening. The scope of world view changes as we change levels. emc already does much of this multi-level stuff (or at least it tried to), but without documentation of the "proper" channels, folk started using what ever seemed to work (rayh/#emc) John would say that "normally" gui does not need to know backlash comp. right (rayh/#emc) You are right on with that. I'm probably the worst offender. not your fault tho, we can't expect you to follow rules that aren't written down (Imperator_/#emc) so maybe we can say that worldmodel is no struct, it is a collection of structs and HAL, and .... this is a natural result of a project that was originally written by two guys in the same room being spread out to a larger group (rayh/#emc) When Fred added the possibility of motion with tool change, it opened my eyes a bunch. (rayh/#emc) Hell. I didn't even know there was a motion stack. (rayh/#emc) Much less where it resided. Imperator_: there are levels of worldview, HAL is one, the command/status/error things are another, etc (Imperator_/#emc) and so we have the worldview if it will be documentet very well (les/#emc) There is quite a larger motion stack with segmentqueue you should use the one appropriate to the task at hand... and if you find yourself reaching far away to get/set some data, think carefully about what you are doing - maybe there is a better way (rayh/#emc) My only fear is that we deny access to various parts of world view by hard coding stuff. les: I just added this comment in front of tpRunCycle(): /* what the hell does this do? It is one of the key functions in the whole planner, and it doesn't have any overall comments :-( */ (rayh/#emc) Think carefully when you autotune. rayh: the way I see autotuning - you would do it without loading emcmot at all (rayh/#emc) Be able to write an autotune, expose the variables and write them as needed. the PID and motor control are all HAL - tune that first, using a square wave as position command (les/#emc) jmk: tell me about it! I have racked my brain trying to figure out where the VERY simple trap planner really is (les/#emc) the answer: Spread out all through tp, tc, emcmot, and others with globals (rayh/#emc) Well, there are a whole class of machines that autotune continuously. ! wow, didn't know that (rayh/#emc) Man, for not face to face, this is opening up some great stuff. rayh: I think even continuous autotune would be outside the normal emc, it would be a hal component that sits next to the pid block, watching pid's inputs and outputs and occaisionally tweaking a gain (rayh/#emc) That certainly is possible with the way that you've developed hal. (rayh/#emc) And the gui/hmi could have a button or menu item that enabled that hal autotune module. if you think about it, how does a human tune a pid - he sits there watching inputs and outputs and occaisionally tweaks a gain (rayh/#emc) Yep. That's it. (rayh/#emc) 'cept I listen more than watch. I wouldn't put an autotune button on the GUI (rayh/#emc) You're allowed to think not. (les/#emc) I see autotune as just another feedback loop with longer time constants what about steppers? do you autotune them? (rayh/#emc) We had a tuning tape for the old Sheldon hydraulic lathe. (rayh/#emc) Ran it about every four hours. putting an autotune button on the GUI is an example of reaching about 10 cubicles down, and assuming things about what you'll find there maybe you won't even find a PID - I could do a stepper driver that doesn't use conventional PID HAL would let me connect that driver to emc in a way that is transparent to emc - until you push that autotune button (rayh/#emc) Absolutely, so in terms of my thinking of world view, when you reach far, you need to be certain that the info you get back, and the rules that you write to use that info must be correct for that reach. rayh: you must be planning on writing some *very* intelligent code (rayh/#emc) Imperator_: is correct that there are many parts to world view. (rayh/#emc) Yes I do plan on writing some very intelligent stuff. That does not eliminate the possibility that some folk may do some very dumb stuff with the same possibility. (rayh/#emc) It should be sufficient to disclaim, "professional driver, closed course, don't try this in your neighborhood." (rayh/#emc) Or should it? (Imperator_/#emc) there are many documents on the web about autotuning we must think differently... I cannot deal with complex systems, so I approach them by breaking them up into simpler chunks, minimizing the cross-coupling between the chunks, and then makeing each chunk work indivdually... the kind of cross-coupling you want to do makes that very hard (rayh/#emc) I don't think it should. As long as halcmd is available, we can both do what we need. seems to me auto-tuning takes place at the level of the PID loop, so I would try _very_ hard to prevent autotuning from having any connections outside that level... emc should be unaware of autotune, and autotune should be unaware of emc (rayh/#emc) And I should add that sufficient documentation of processes is available. (rayh/#emc) I can appreciate that but others may want other autotuning procedures as well as yours. (rayh/#emc) I'm with you that "normal" operation be built in and followed. (rayh/#emc) But at the same time, abnormal, operation must be permitted. seems to me, when you put a button on the standard GUI, that becomes "normal" (rayh/#emc) I'm guessing that that button may not be a part of the standard gui. (rayh/#emc) or it may be grayed out when the conditions needed to use it are not met by the world view in existence. If you want to build a custom GUI that only works with some configurations of the HAL (like servo, but not stepper), then that's different but I think the standard GUI should avoid interaction with low level details, so it works with any functional HAL configuration (rayh/#emc) I was struck this week by Tom Yager's comment in InfoWorld. "It's time someone pointed out that one can only extract from data the intelligence that went into it. (rayh/#emc) If data such as the stuff needed to autotune is available, we could do data mining using any one of a bunch of statistics. rayh: I don't want to ever hear you say you're not a programmer - you're talking about stuff I wouldn't touch with a ten foot pole... difficult, challenging problems no matter what language you write it in (rayh/#emc) NIST wrote a feature based control. It was based on the idea that there was a model of the part someplace in the machine and it went out and found a block of material using probing and adjusted it's view of the machine so that it could cut the part from the available block. (rayh/#emc) Allignment and orientation of the block of raw stock didn't matter at all. can any mere mortals read and understand the code? (rayh/#emc) I know that feeling, John. to me it is far more important to have code that is clear, understandable, and supportable I want to have 10 developers who are able to work on emc, find and fix bugs, etc (rayh/#emc) Yes. That is the "truth" at that level. to me that is far more important than esoteric features (rayh/#emc) Where "world model" comes to the front is when we need to stretch the normal to match a new situation. and when you get those 10 developers, the features will come as long as the stretching is done with forethought and planning... ad-hockery as gotten us where we are now (rayh/#emc) The code and arch of the hal is great, readable, comprehensible, and direct. for that matter - the "normal" should be defined with stretching in mind - there are 10 ways to skin any cat - we need to think about all 10 and pick the one that is cleanest and most extensible, not the first one that works (rayh/#emc) Most any developer could attack a new module for it. (rayh/#emc) Might not work well if I do it -- but I could try. we'll have you writing C yet ;-) (rayh/#emc) Tried writing hello world once, all I got back was, "forget about it." (rayh/#emc) Figured if I tried again it might say, "your father was a hamster, and your mother smelled of elderberries." (Monty Python) I wish there was a way I could snap my fingers at 11pm, (or 1am) and be able to talk to you and matt and fred... some of what I'm doing now is defining "normal" for emc2, and I don't know if I'm doing it right (rayh/#emc) In my opinion, a properly designed world model will allow for orderly expansion. we agree there... the problem is moving from the abstract to the concrete... what variables, how are they accessed, etc (rayh/#emc) Charge on. Keep it simple. easier said that done... HAL is the result of about 4 months of thinking before I started writing, with a problem domain that was well defined... I don't know enough about the outer reaches of emc to define the problem domain... (rayh/#emc) I think that Steve's "expose" term is a good one. I've been removing cruft from some of the structures by commenting out struct members that I don't think are needed and compiling, if no errors, then yep, they're not needed :-) if error, put em back (rayh/#emc) Write local variables but write tools that allow those variables to be exposed if needed elsewhere. (rayh/#emc) Would your procedure rule out stuff like non-cartesian machines. I haven't touched kinematics did you know that emc has messages/hooks that would let you change the servo or traj rate while things are running? (rayh/#emc) I saw those, and tried to use them a few times. (rayh/#emc) The results told me that I didn't want to go there. they are gone in emc2 changing the sample rate of a sampled data system in midstream is insane, IMHO (rayh/#emc) I proposed changing the input_scale in mid stream once. (rayh/#emc) Got hammered pretty good for that. I've moved scaling to the HAL - you could change it if you wanted to, but you probably wouldn't like the results " I'm at 1.0, I'm at 1.0, oh wow, now I'm at 25.4 - gotta run!" (rayh/#emc) Many spindle controllers do this. Course for high speed, fine for live tooling. you mean they change from a course encoder to a fine one, with appropriate scaling factors for each? (rayh/#emc) It would require a fairly complete set of rules that define the change. (rayh/#emc) Same encoder or resolver. huh? (rayh/#emc) That's what I said. (rayh/#emc) Guy at Mazak said it's magic. I know what you said, what do you mean? ;-) "any sufficiently advanced technology is indistinguishable from magic" (rayh/#emc) Eric Raymond? Authur C. Clarke IIRC (rayh/#emc) I was thinking about it in terms of Gecko's step multiplier. (rayh/#emc) If you kicked in the step multiplier for high speed, and bypassed it for low speed. rayh: it would be tough to do that without skipping steps (it has been discussed on the gecko group), but that is similar to what I was talking about - you essentially change from a 200s/rev to 2000s/rev, and change the scaling at the same time to compensate (les/#emc) So...emc2 at present is exclusively cartesian? les: emc2 at present is scattered across the floor but I have done nothing that would break the existing kinematics and support for non-cartesean machines (les/#emc) :) * rayh has to wrap up here soon. right now I think trivkins is the only kinematics file that has been copied over to the emc2 tree, but the others will hopefully work too (les/#emc) inverse kinematics is basically just an array rayh: do you grok the differences between free, coordinated, and teleop modes? (rayh/#emc) Huh;) (rayh/#emc) I know the word grok but the others are a mystery. all three are in emcmot, Fred tells me teleop is not used for machine tool control coordinated is normal multi-axis moves, free is used for jogs (I think) can you jog more than one axis at a time? (rayh/#emc) That's how I understand it. (rayh/#emc) Yes if you have the control (hmi) capability. (rayh/#emc) It get's sticky with the keyboard as control because of the inverted and dual coded nature of each keystroke. teleop would be used for "jogs" of something like a hexapod, where you don't want to jog an individual actuator, instead you want to jog the cutter along +X for example (rayh/#emc) Ah. That's where I've used it. (rayh/#emc) Thanks for reminding me of that. so you have used it? Fred thought it was only used for things like the flying carpet. (rayh/#emc) You can get a whole set of error messages around teleop when you are someplace between joint and world mode. yeah, all joints must be homed before you can go into teleop (or coord, IIRC) world mode in the GUI must correspond to coord mode in emcmot joint mode corresponds to free mode in emcmot jmk...how are things going? busy... I'm trying to get emc2 working that is indeed a worthygoal but I keep getting sidetracked as I try to clean up weird stuff tell me about it... the sheer size and complexity of emc makes my head hurt emcmot is huge to say nothing of the rest of emc that's what I'm hacking in I feel for you. matt split it into three chunks when he moved it into emc2 motion.c handles init, command.c handles motion commands, control.c is the actual motion controller then there's motion.h, with lots of huge and crufty structures (les/#emc) where is the planner? tp.c, tc.c, called from control.c (and elsewhere, I don't know how it all plays together) tpRunCycle() is called, followed by tpGetPos, IIRC, and presto, you have position setpoints (needs interpolated after that though) Abdul cleaned up some code for handling model_manual or model_auto boards on homing (les/#emc) dave: So homing is functional? not yet...really weird...finds the home switch and stops.... if one jogs (once) then it picks up the index and homes. homing is screwy emc2 is gonna get a new homing algorithm (les/#emc) The only problem I have with STG is the fact that emc wakes up with garbage numbers I suspect Abdul will get it fixed today (les/#emc) if one is negative it will home the wrong way ...and those numbers are not in your var file? (les/#emc) Nope that doesn't happen on my stg(1) (les/#emc) Fred and other have noticed this on the new board? (les/#emc) If you turn the machine off and wait a while it will wake up with zeros (les/#emc) yes on the new board I've got an old board ...and am still on 2-18 bdi that is (les/#emc) some cap somewhere holds a charge for a long time and at one time we thought computers were absolutely reliable.... (les/#emc) Fred found that disconnecting the card "resets" it as well seems to me the driver should latch the counter value at startup and subtract that from all subsequent reads (les/#emc) it should (les/#emc) need some code that does exactly that the HAL driver will (when I get there), can't help you on emc1 tho well homing should zero the encoder registers on index pulse (les/#emc) but if a negative number is in there it can home the wrong way sounds like the driver needs some help (les/#emc) Did that this morning when I ran your home log test nasty of it (les/#emc) I was able to just jog it enough to get a positive number (les/#emc) hmm let me look at newstg.c... lots of code there...but it may not be too hard to follow. hello steve (les/#emc) not seeing anything there...must be in emcsegmot I haven't a clue matt might know (les/#emc) yup Hi Dave, thanks for waking me up. 8-) (les/#emc) minor but nagging problem...cold boot fixes. I see people are beginning to show up on chat again...pretty quiet after fest Dave - I thought that significant progress on finding "home" was made at EMC fest, at least that is what is in my preliminary report. Oh, yes... john, matt, paul, etc cleaned up some iffy code. it also broke some things... I'm testing the vital systems card and it broke it... Oops.... on all machines, or just non-stepper machines? hopefully homing will be fixed today....Abdul is having better success on his 2.4 system than I am on 2.2.18 probably just on the vital card. I don't have home switches for the ppmc or the stg I now have home, plus and minus limits and estop set up for the vital card and of course the hardwired estop chain....with a relay that latches out when estop is hit still lots to do on the machine....spindle, spindle gearing and tool change. I'd better run ... have been working on goodies to hang the monitor out front like it should be. thanks for the log stuff...I hope the floppy finally treats you well. (les/#emc) no problem see ya later back for a bit - I saw something about homing and what Fred and I did at Fest... we added a #define, called NO_SWITCHES IIRC, if you have a home switch it should _not_ be defined (it basically shortcuts the entire homing process and zeros the axis where it stands, which is all you can do if you have no switch) Lost connection for a while (jmkasunich/#emc) how did you change that? (Imperator__/#emc) that is what proffessional maschine controllers do (Imperator__/#emc) i think (jmkasunich/#emc) agreed - but I didn't think emc did that, how did you make it work? (les/#emc) well if you do a home offset the speed doubles...that is hard coded (les/#emc) here is what I do: * jmkasunich listens (les/#emc) set homing velocity in the ini to the negative direction (les/#emc) switch is normally closed (jmkasunich/#emc) switch at negative end? (les/#emc) set the ini to reverse direction (les/#emc) yes negative end (les/#emc) then after index latch I home offset to center of travel (les/#emc) it's in the .ini on my website lmwatts.com (jmkasunich/#emc) I'm trying to match what you describe with the code (les/#emc) On most all cnc stuff (including other than emc) I do it that way (jmkasunich/#emc) the code seems to say: approach switch until hit, keep moving to index, then latch that position, and move to offset (jmkasunich/#emc) so the latched position is actually when you are on the switch (les/#emc) you can do that too with home velocity signs (jmkasunich/#emc) (offset moves your home position elsewhere) (jmkasunich/#emc) guess that's what I'm missing - I thought there was only one home velocity, and it's sign had to point to the end of travel with the switch (les/#emc) latched position is the first index pulse after hitting the home switch and reversing (les/#emc) let me pull up an ini so I can get specific (an0n/#emc) what do you use homing for? (jmkasunich/#emc) to ensure that the machine coordinate system is the same every time you power up the machine (an0n/#emc) isnt zero where you have your workpiece? (jmkasunich/#emc) depends... most pro machine have machine zero in the same place every time, and workpiece zero is handled by offsets (Imperator__/#emc) is it possible to place the homing code in a way that is easyle replaceable by others, because i think there are also other posibilitys of homing for example the distance coded glass scales (an0n/#emc) oh (les/#emc) ok I forgot... I set HOMING_POLARITY=0 (an0n/#emc) I didnt know that was different.. (les/#emc) 0=negative going 1= positive going (an0n/#emc) I am still a newbie.. (jmkasunich/#emc) I see, there is HOMING_VEL _and_ HOMING_POLARITY (les/#emc) right (jmkasunich/#emc) I thought the sign of HOMING_VEL was what determined HOMING_POLARITY (les/#emc) you can make it bounce the switch or go right through (jmkasunich/#emc) so the sign of HOMING_VEL tells it which way to go to find the switch, and HOMING_POLARITY tells it whether to bounce? (jmkasunich/#emc) waitaminnit - HOMING_POLARITY just determines whether the switch is active hi or lo (jmkasunich/#emc) good night an0n: (jmkasunich/#emc) Imperator__: right now it isn't even possible to disentangle the homing code from the rest, but I'm hoping to change that (jmkasunich/#emc) I don't know if replaceable homing code is possible - maybe (jmkasunich/#emc) les still there? (Imperator__/#emc) ok, that would be very good to disentangle it in feature (les/#emc) it's been a while but IIRC a 0 HOMING_POLARITY and a negative HOMING_VEL will make it go towards decreasing count, then blow through the switch in the same direction until index (Imperator__/#emc) ah i mean in future (jmkasunich/#emc) as I understood it, HOMING_POLARITY simply specified the switch as active hi or lo (les/#emc) I have a zero HOMING_POLARITY and a positive HOMING_VEL so it reverses at the switch then hunts for index (jmkasunich/#emc) but maybe if you lie about the switch polarity, it thinks it's on the switch, so it moves till it's "off" (really on), then moves back on (ie. reverses) (les/#emc) no that's HOME_SWITCH_POLARITY (jmkasunich/#emc) oh, ok, there are two of 'em ;-) (les/#emc) I use 1 for that...normally closed switches which is the safe and usual way to go (jmkasunich/#emc) grepping code (les/#emc) I think the options needed are (without the user writing code): (les/#emc) 1) home with switch and index in any position (les/#emc) 2) home with switch only in any position (les/#emc) 3) home at present location (les/#emc) and a variant of #3... (les/#emc) Home by driving into a stop (les/#emc) that should just about cover it (jmkasunich/#emc) homing into a stop - ouch (les/#emc) it was used a long time ago (jmkasunich/#emc) 3 is easy, and involves no movement (les/#emc) mostly for steppers (jmkasunich/#emc) so moving to a stop is not really a variation - really #4 (les/#emc) it was a soft stop (jmkasunich/#emc) 1 and 2 both have variants tho - thru and bounce (les/#emc) well I would consider #3 obsolete these days...but then I am a commercial user (jmkasunich/#emc) sherline uses #3 (jmkasunich/#emc) it could be handy for one-offs even on a machine with switches... (les/#emc) thru and bounce handles with signs and/or a direction as now (jmkasunich/#emc) use an edge finder on a part feature, zero the axis, repeat for other axis, then run (jmkasunich/#emc) don't like that signs crap - unless we document it better (les/#emc) yup (jmkasunich/#emc) it's a case of "the code is designed to home thru, but if you wiggle the parameters just so, it will bounce" (les/#emc) it is not documented anywhere that I know of....I just had to fool around to find it (jmkasunich/#emc) all the code comments (what little there is) don't mention it - for all I know, you are simply exploiting a bug that happens to work the way you want it to (les/#emc) yup (jmkasunich/#emc) I'd rather explicitly have the user say bounce or thru (les/#emc) bouncing on and end switch is pretty much industry standard (jmkasunich/#emc) I was gonna change it to bounce and drop the thru, but that's why we're talking - should we keep thru as an option? (les/#emc) if the home switch is in the middle somewhere you can never know which way to go when the controller wakes up right? (jmkasunich/#emc) that's another interseting point ;-) (les/#emc) which is why all the machines I have seen put it on one end (les/#emc) but it is a fact that in emc1 it can be anywhere (jmkasunich/#emc) what happens if you start on the wrong side of it? (les/#emc) right.... (Imperator__/#emc) then it hits the end switsh first, and then you know that you have to search in the other direction (les/#emc) but if it is on the end that can't happen (jmkasunich/#emc) I don't think emc has code to reverse on a limit switch (Imperator__/#emc) that can also happen if the switches are on one end (les/#emc) I wrote a thing like that on a machine a long time ago using a tech80 card (les/#emc) but emc does not have it (jmkasunich/#emc) if switch is at the plus end, and homing velocity is positive, you _will_ eventually hit it, or you are already on it (jmkasunich/#emc) if it is in the middle, you have three possibilities, you will eventually hit it, you are already on it, or you passed it (jmkasunich/#emc) if you passed it, you're screwed (les/#emc) It is possible to be on the switch or past it when it wakes up...but unlikely (les/#emc) for that I use a hard limit over ride (jmkasunich/#emc) if it's in the middle, it's very possible (les/#emc) right (Imperator__/#emc) i have looked on the Haidenhain manual, there are different modes. (les/#emc) like 50% probability (jmkasunich/#emc) I want to draw a state diagram for homing... the states will be things like: (jmkasunich/#emc) "looking for switch" (jmkasunich/#emc) "backing off switch" (jmkasunich/#emc) "looking for index" (jmkasunich/#emc) "move to offset" (jmkasunich/#emc) etc (les/#emc) It's a pretty simple state machine I guess (jmkasunich/#emc) perhaps we need multiple homing velocities... one to look for the switch (as fast as possible, while ensuring that coastdown won't hit a hard limit) (jmkasunich/#emc) and another to find the exact switch point (much slower, only used after we find the switch) (Imperator__/#emc) jep, and it has to go in the slow modus only from one side over the switch (les/#emc) that is done with two speeds in old emc (jmkasunich/#emc) assume both vels are positive, it will go fast positive until it hits the switch, then fast negative until off it, then slow positive until trip, continuing slow positive until index (les/#emc) it goes slow to find home but doubles in speed to do the offset. (les/#emc) That is hard coded at the moment (jmkasunich/#emc) if the first vel is pos and the 2nd is neg, then it will go fast positive to the switch, slow negative until trip, and continue slow until index (jmkasunich/#emc) in both cases, once you have trip and index, why can't it rapid to the offset position? (jmkasunich/#emc) insread of the 2x thing (les/#emc) It would be good to not hard code the 2X for sure (les/#emc) this is in emcmot (jmkasunich/#emc) yeah, I've been looking at that code, it's gawd-awful for readability... (jmkasunich/#emc) there is "sort of" a state machine, but not a real one (les/#emc) I can't follow it at all...too many globals for my little brain! (jmkasunich/#emc) I think they just started hacking, and what they wound up with resembles a state machine (they call it homing_phase instead of state) (jmkasunich/#emc) I'd like to draw the state diagrams first, then code it (les/#emc) yes (Imperator__/#emc) a easy thing is that if you have the referece switch is on one side, that the reference switch is presst until the end switch cames. so you know that if the reference is pressed you are between reference and end switch, and you have to drive in the other direction to release the reference, then you come back to press the reference again (jmkasunich/#emc) Imperator__: yes - if you can move beyond the home switch, then things get much more complicated (Imperator__/#emc) jep (jmkasunich/#emc) another complication is that some folks use one limit switch as the home switch (les/#emc) I have a home switch, then 1 cm later an estop switch, then 1 mm later a constant velocity shock absorber tuned to 1/2mv^2 max (jmkasunich/#emc) is the estop switch an input to emc (hardware limit) or a hard shutdown of the amps, etc? (les/#emc) Both... (les/#emc) as a commercial system it has to be hard wired...but it tells emc as well (jmkasunich/#emc) so emc has three inputs for axis on your machine, pos_hard_limit, neg_hard_limit, and home_switch (les/#emc) correct (jmkasunich/#emc) hitting hard_limits faults emc anyway (les/#emc) this is required in commercial systms (Imperator__/#emc) i think the thing with limit switches as home switches is used to controll everything with only one parallel port (les/#emc) I have SOFT limits about 1 cm from the switches (jmkasunich/#emc) yeah (jmkasunich/#emc) soft as in existing only in software, or another set of physical switches? (les/#emc) yes (jmkasunich/#emc) :-) yes to which one? (jmkasunich/#emc) emc has software limits (only after axis is homed) that abort motion (les/#emc) EMC will stop before you hit the limit switch...IF THINGS ARE WORKING (jmkasunich/#emc) right - then that's the soft limits I was referring to... only valid once the axis is homed (les/#emc) right (jmkasunich/#emc) emc also ignores hard limits if you are homing... that's for the benefit of the guys who use a limit switch as home (les/#emc) Us commercial guys don't get to do that but I understand (jmkasunich/#emc) it's not so much commercial that is the deciding factor, it's size and speed... sherline is commercial, but they have no limits or home switches (jmkasunich/#emc) of course their rapid is about 15 in/min (les/#emc) My hardware limits have to disconnect the servo amps, short the servos, and turn off the spindle (Imperator__/#emc) i think with commercial you mean real machines les, no toys (jmkasunich/#emc) who says "have to" anyway - what is the authority? UL, electric code, OSHA? (les/#emc) The issue is all about getting insurance (les/#emc) factory mutual (jmkasunich/#emc) so it's not commercial as in selling machines, it's commercial as in somebody other than you might be the operator ie. an employee (les/#emc) right (les/#emc) you can use a lot of non-approved gear even these days...but you just can't get insurance (les/#emc) not an issue for hobby stuff (jmkasunich/#emc) anyway, we digress... but it does point out the wide range of situations we need to support (jmkasunich/#emc) there are probably about 10 different ways to home (les/#emc) yup (les/#emc) but it boils down to just those cases we discussed (jmkasunich/#emc) with variations like bounce or thru, and shared switches (jmkasunich/#emc) and if switch in the middle, hit far limit and go back, vs. hitting far limit causes an estop (les/#emc) right (jmkasunich/#emc) I think if someone wants switch in the middle, they should design the switch actuator so the switch remains pressed if you go past it (jmkasunich/#emc) makes the code simpler ;-) (les/#emc) but I wonder...with home offseting why put the switch in the middle ever? (jmkasunich/#emc) right (jmkasunich/#emc) if you assume switch stays pressed when past it, then it's easy (jmkasunich/#emc) fast positive till hit (jmkasunich/#emc) fast negative till off (jmkasunich/#emc) slow positive till hit and index (jmkasunich/#emc) if you are already on the switch, you just skip the first move (Imperator__/#emc) jep (les/#emc) I think emc had that option for any homeswitch position because it might be used for something other than a cnc controller (Imperator__/#emc) for my case with the absolut encoders, i need a "no homing" mode, it hase just start reading the encoders (jmkasunich/#emc) absolute gets interesting... (Imperator__/#emc) :-) (les/#emc) I think a provision for absolute would be rarely used...but has merit (Imperator__/#emc) we use that and kill all the homing code (les/#emc) right (jmkasunich/#emc) right now, pushing home means either make the current position "zero" or go to position "zero" (jmkasunich/#emc) in either case, after you push the button and the dust settles, the display reads zero (jmkasunich/#emc) (neglecting home offset for now) (les/#emc) same even with offset for me (jmkasunich/#emc) with absolute, I would still want pushing the button to mean "go to position zero" (jmkasunich/#emc) so offset doesn't mean move to a non-zero position, it means move away from the switch and call that zero? (les/#emc) a button might be nice... it's just MDI G0x0y0z0 or similar (jmkasunich/#emc) here's a hack, but it has the advantage of not changing a lot of code... (les/#emc) ofsset is as you described it yes... but it can move in any direction (les/#emc) it happens automatically if a non-zero value is in the .ini (jmkasunich/#emc) right - move away from switch by "offset" (pos or neg) and then call that spot "zero", right? (les/#emc) so when i home it automqatically offsets too. (les/#emc) right (jmkasunich/#emc) not "call switch location zero and move till display says "offset" (jmkasunich/#emc) ok, got it (jmkasunich/#emc) back to the abs encoder hack (jmkasunich/#emc) make the HAL driver for an abs encoder with an output that is a fake home switch (jmkasunich/#emc) one hal parameter is the abs location of the switch, the pin tells you whether you're above or below that location (les/#emc) hmmm (jmkasunich/#emc) wire that to the normal emc home switch input (HAL software wires) (jmkasunich/#emc) then you can do a normal home, and it works (les/#emc) well homing just has no meaning with an absolute encoder... (les/#emc) so just disable it? (jmkasunich/#emc) of course you loose the benefit of being able to know where you are without moving (jmkasunich/#emc) homing is embedded within emc... soft limits only apply once you have homed, for instance (jmkasunich/#emc) homed/not_homed is one of the key states of each axis (les/#emc) Yes a routine could do a virtual home if absolute encoders were used (les/#emc) or selected (jmkasunich/#emc) yeah, so that is another case to embed in the homing code (les/#emc) in other words just set that flag or whatever (jmkasunich/#emc) abs encoder, yes/no (Imperator__/#emc) i think for the absolute encoder it is possible to hit the home switsh, and wire the offset input with the encoder input (jmkasunich/#emc) home sw yes/no (jmkasunich/#emc) index pulse, yes/no (jmkasunich/#emc) search vel (fast for finding switch) (jmkasunich/#emc) home vel (slow, for precise homing) (jmkasunich/#emc) all those (and maybe some I'm forgetting) are inputs to the home algorithm, and it has to do the right thing (les/#emc) sounds ok (les/#emc) if those are truly velocities...signed numbers (les/#emc) covers about everything (jmkasunich/#emc) yes - velocity is _always_ signed ;-) (les/#emc) It is to us engineers (Imperator__/#emc) amazing how complicated things can be (jmkasunich/#emc) one more - reverse_on_limit yes/no for the guy with switch in the middle (jmkasunich/#emc) and maybe override_limit_during_home yes/no instead of automatically overriding them (Imperator__/#emc) and if the reference switch will be holded (les/#emc) I suppose...for other than cnc use (jmkasunich/#emc) and we are ignoring the drive to a stop guys... (jmkasunich/#emc) they need to have a timeout or something (jmkasunich/#emc) I guess a move of axis_length + 1 would do it (jmkasunich/#emc) then stop, and set your zero (or do the offset move, then set zero) (les/#emc) the usual way was to do it with servos at a temporarly low P gain....with steppers just a shock absorber or something (jmkasunich/#emc) I'm tempted to pretend you never mentioned that one - either use switches, or jog to position (edgefinder, etc) and zero them (les/#emc) well I haven't seen that stuff in eons anyway... (jmkasunich/#emc) what stuff, I seem to have forgotten all about it ;-) * jmkasunich thinks about interaction between backlash comp and homing (les/#emc) some car stuff still has a spring preload against a stop for encoder home (jmkasunich/#emc) switch is on the table, and thus immune to backlash/screw wear (les/#emc) ah...backlash comp... (jmkasunich/#emc) index pulse is on the screw, and is affected by backlash (jmkasunich/#emc) not just backlash - but compensation for screw errors (jmkasunich/#emc) (I'm planning on doing them both in the same place) (jmkasunich/#emc) oh well... this has been a good discussion... thanks! (les/#emc) Well I map screw errors...but we don't do backlash. It's lost motion and can't really be compensated in software in the general sense dur to a rectangilar probability density of position (les/#emc) blah what spelling (les/#emc) but...I can't type haha (jmkasunich/#emc) you can compensate if you assume friction is greater than cutting forces (or if cutting forces always oppose table motion) (les/#emc) I will argue that one... (jmkasunich/#emc) if friction is greater than cutting forces, table will never move unless screw moves it (jmkasunich/#emc) so you don't have uncertainty (les/#emc) in the most general sense in a vibrating dynamic machine lost motion is not predictable as to exact position (les/#emc) in special cases it is rectangular hysteresis (jmkasunich/#emc) agreed in the general case - my statement about friction > cutting force isn't complete enough (jmkasunich/#emc) inertia forces also count - if table is moving and screw stops, the nut and screw might separate, and again you don't know where you are (les/#emc) I got in to that as I was modelling stick slip for my external cutting force monitor (jmkasunich/#emc) you are definitely out of the range where comp can work, you have both cutting and inertial forces that exceed friction (jmkasunich/#emc) so you need $$ nuts instead (jmkasunich/#emc) ;-) (les/#emc) This separates inertia and cutting forces just by measuring servo current and back emf (jmkasunich/#emc) backlash comp only works in the special cases where it is rectangular hystersis