it is kinda quiet in here, isn't it so far we've only discussed software guys doing hardware, and hardware guys doing software. was that earlier? Yeah, earlier. Mostly , "which is more frightening".. software guys doing hardware, definitely did anyone ever hear back from the guy that wrote the parallel port pin configuration patch for emc1? I offered in private mail to commit his changes, but never heard back I didn't - I don't know what happened, did we scare him off well I remember he had to ask twice; there didn't seem to be a strong interest so maybe he just got frustrated and decided to keep it for himself possibly - that's a shame though... yeah, especially since it was a patch I wanted, but don't want to do myself his particular change wasn't too exciting to me because emc2 will handle that, but I really want to attract new developers I also want to specify -1 pins to bridgeportio to make it emulate those signals (like minimillio does) those were the two reasons I had to hack emc to make my machine work I needed the step/dir signals on different pins I also needed spindle control on the same port and nothing else that kind of thing is exactly what emc2 is all about... but I'm getting bogged down trying to integrate it it will sure be nice I've been watching your checkins but haven't even tried to build it yet guys, I asked a question last night when no one was at their computer, if you don't mind, I'm just going to copy and paste the same question go right ahead Is there anything that is in the near price/performance ranger as the ShopBot that can accept emc commands etc? don't know exactly how to phrase what I'm asking, but it basically boils down to "I need a CNC router in the low price range that can be run from linux" or at least I would like to, if such a machine exists how big, how fast? if Les is still here, I'm sure he'd like to bend your ear ehh, don't really know, like I said, I'm a noob at CNC, just trying to get info on what's available, but for reference this is what I'm comparing it to http://www.shopbottools.com/PRTalpha.htm do you want to build one, or are you looking for a turnkey machine? I'm open to either, I'm exploring my options way ahead of actually needing one I'm currently an Industrial Design grad student (mainly focused on furniture) I won't need a machine for another 2 years you could build a moderate size moderate speed one for ~$1000, or buy a big fast one turnkey for $100K, or anything in between heh, so pretty open definitely looking at something that can handle a 4x8 sheet minimum you should look at les's site - he made his router to do furniture http://www.lmwatts.com/cnc.html I seem to recall he spent about $20K, but his machine is first class all the way < hi GEMorris I'm running the machine today to do optics just ran in to punch some data in Exel Do you need to cut metal? mainly wood, the ability to do some metal would be nice I guess, but It's not necessary your machine is very nice, however I don't think I have anywhere close to the engineering experience to pull something like that off :) Mine is large and expensive, but it's an industrial machine Wood only machines can be built much lighter I guess Shopbot is the other extreme It works, but I think it is too slow for any kind of reasonable production have you seen the new one? http://www.shopbottools.com/PRTalpha.htm it's much faster The 2004 IWF show in Atlanta coming up soon will have preety much every cnc router model on the planet (we have one of the old model here at NCSU, but I hear we are upgrading it) The alpha looks much better...I'm sure it will be at the show so I will have a look at it running the real "advantage" I guess of the shop bot for me, besides price, is that I can spend the next 2.5 years messing around with one at school before I would have to buy one for myself meaning I'd probably know it inside out but it bugs me that they aren't open source another way to look at it: you have 2.5 years to examine theirs and decide if/how you want to build yours take the best ideas from their machine, and build your own... probably save several thousand $ Well Myself and a couple others are considering offering an open source cnc router platform EMC is key for this I would be very interested in hearing more about that les. Good thing I don't have to buy anything for awhile :) les: by "open source router" do you mean you publish the design and let people build their own, or would you sell kits, or complete machines only needing computer, or all of the above just the software/firmware Mechanical stuff is kinda always open source unless it is patented Perhaps all of the above...It's just an economic issue not true - it's the details that are important, and unless you can examine a machine up close, they are not really open source I seem to be stuck at about 10k minimum with pricing so far to me, an open source machine would be a complete set of drawings, so someone with limited design skills (but good fab skills) could build it. very hard to get much below that for a light industrial rated machine to make money, you would offer some pre-fabbed parts, folks can make a time/money tradeoff I can imagine. Are you guys looking at an indexer option? (wood lathe, whatever it would be called) I have condidered kits/plans like Bob Campbell I may need a rotary axis one of these days Anyway I will be really taking a close look at how the cnc router market is doing at the show It has been a tough business the past several years KOMO just about went under everything has been a tough business in the last several years that 10K is a ballscrew machine? I would expect that rack/pinion could be cheaper Ballscrew yes The unhardened Browning type racks are economical But the Hardened anti backlash racks actually cost more than many ballscrews I certainly wasn't thinking about anti-backlash racks my basic intent is to do small-run studio furniture so light production I guess I have a question about home and limit switches: some machines have switches that close (or open) when hit, and remain closed even after you pass them other machines have switches that close when you hit them, and open again once you move past them I've been trying to make emc2's homing algorithm work with both types of switches the problem: during homing you approach the switch, possibly moving fairly fast. you hit the switch, and emc stops as soon as possible. However if you coast past the switch before stopping, and it opens again, the homing code can get confused anybody willing to help me talk thru this problem and figure out the right thing to do? half-baked idea: make a virtual switch which turns on when the real switch turns on, and stays on until an on-to-off transition with the axis moving in the opposite direction. I do that at work.. with the plc's, when switches bounce.. software toggle's :) seems like a good idea sorry, I was away for a bit actually I did something along those lines I didn't use direction of motion, instead I used position - when the switch comes on, I latch the current position, then don't let it go off again until the position is lower (that was a week ago - then today I realized that screws up things if you intend to home coming off the switch) but in general I like the virtual switch idea hm, how do you home usually? what do you mean? how is it coded in emc2? or what I do on my machine? oh, how it is usually coded.. or how does the real machines do dunno about "usually", seems everybody does it a little differently I think you shoud go over the switch then back up slowly until the you pass it.. that must be a pretty accurate way.. depending on your switch type.. I'd use optical switches.. or magneto sensors.. the fundamentals are pretty much the same, its the little details that differ, like how (or if) you handle switches that you can "pass up" emc2 already gives several options there are two velocity parameters, search_vel and latch_vel it first looks for the switch moving at search_vel (sign of vel tells it which way to move) then it latches the final position at "latch_vel" if latch_vel is the same sign as search_vel, it searches, then backs up and approaches from the same direction at latch_vel if latch_vel is the opposite sign as search_vel, it searches, then backs up slowly and latches when it comes off the switch what's wrong with that approach? it sounds sensible :) it gets complicated if the search_vel is fast enough that you go past the switch before you begin backing up oh.. cant you add a latch for that? or well, make it pass the switch then back up.. which doesn't work for the other kind of switch, the one that closes and remains closed too many variations :-( add a condition.. I did add a latch, something like your virtual switch idea but it was position based "when switch turns on, remember that position, then ignore switch off unless current position < remembered position" that woudnt be that hard.. (an0n_) jmkasunich: how about contact bounce? (jmkasunich) yep, more fun ;-) ((an0n_) the joy never ends around here (jmkasunich) actually I have a debounce block in the HAL (an0n_) nevermind then :D (jmkasunich) the idea is that you would route the bouncy switch signal thru the debouncer before sending it to emc proper (jmkasunich) there was debounce code inside emc, that I originally kept for emc2, but a couple people recommended moving the debounce out of the motion controller (an0n_) yeah, that's probably a good idea (an0n_) debouncing is such a pain :) (jmkasunich) hmmm... the debounce block makes a "virtual switch" that doesn't bounce. maybe I should design the homing controller to expect a "perfect" switch that neither bounces, nor opens back up if you move too far, then let something in the HAL emulate the perfect switch if the real switch doesn't do the job? (an0n_) yeah that sounds even better (jmkasunich) all that really does is move the problem from the motion controller to an external block (an0n_) isn't it wise to keep the more code out of the motion controller (an0n_) since you can re-use the code more efficiently (jmkasunich) perhaps (an0n_) and optimize the actual homing instead of how the switch works :) (jmkasunich) but I've also heard from someone who thinks moving things into the HAL is daft (an0n_) hm, why? (jmkasunich) philosophical differences, I believe (jmkasunich) a HAL block that emulates a "perfect" switch would be kind of weird... it would need an input for the imperfect switch and an output that goes to the motion controller, those are fine. But it would also need to know position and/or velocity (an0n_) but cant you account for that in the algorithm? (jmkasunich) putting such logic inside the homing code might be better in that the homing code knows what is going on - are we searching for the switch, or trying to move off of it, etc. (an0n_) hm, yeah (jmkasunich) one thought that occurred to me was to make the homing edge sensitive (an0n_) edge sensitive? (jmkasunich) IOW, when looking for the switch, it would look for a rising edge, not just switch on state (jmkasunich) and when moving back off the switch, it would look for a falling edge, not just "switch off" state (an0n_) dosent that require external logic? (an0n_) to get a perfect 1 or a perfect 0 without bounce (jmkasunich) you would have to use the debounce module (jmkasunich) the parport or other digital input HAL driver will sample the switch input every servo cycle (jmkasunich) the debounce HAL block will generate a debounced (and therefore somewhat delayed) version, also every servo cycle (jmkasunich) the homing code currently looks at the state of the switch every cycle (an0n_) yeah (jmkasunich) for example, if it's trying to back off the switch, it does: (jmkasunich) if (!switch) then goto next state, else keep waiting (an0n_) but you can count how much time it takes.. (an0n_) in the debounce code.. (an0n_) clock the time it takes until the switch stabilizes and return it.. (an0n_) and count how far you've moved according the velocity (an0n_) what do you think of that idea? (an0n_) that coud be useful for other stuff that has to be accurate aswell (jmkasunich) I'm not sure I follow (an0n_) oh, you take time for how long the switch takes to debounce (an0n_) from the first 1 until it stabilizes.. (an0n_) and return it to the function, in this case the homing algorithm.. (jmkasunich) that gets complicated - define "stabilizes" ;-) (an0n_) 1 0 11 0 11111 (jmkasunich) 101101111111111101111111111111111111 (an0n_) yeah.. (an0n_) when you have a clean 1 (an0n_) for enough cycles (jmkasunich) is that last 0 a bounce? how long do you wait until you decide it is stable? (an0n_) make that as a user settable parameter since it depends on what kind of switch they use (an0n_) but it's unimportant.. (an0n_) just make sure it's really a 1.. and then return the time, to the homing algorithm (jmkasunich) the existing debounce block does use a user settable delay, but that delay is inside the debounce block and not available to the homing logic (an0n_) my idea was that you take into account how long debouncing takes and calculate your position off that (jmkasunich) assume the switch first changes state at time = 10, and finishes bouncing at time = 20 (jmkasunich) so at time = 21, we're telling the homing algorithm "wherever you where at time = 10, that's home" (an0n_) yeah (jmkasunich) so we require the homing code to remember where it was 10, or 20 or ? periods ago (an0n_) isnt the homing velocity constant? (an0n_) until you decide to stop? (jmkasunich) more or less - the servo loop, or discrete step sizes, and other things, can cause some changes (jmkasunich) velocity also changes during accel and decel from the homing velocity, and the switch might trip while accelling (an0n_) either that or you have to have it remember where it were (jmkasunich) or you make the final pass so slowly that the error due to the delay is acceptable (jmkasunich) less than one encoder count (or stepper step) is acceptable (an0n_) that causes a bit of memory overhead.. but I dont think you can avoid that if you are going to debounce anyway (jmkasunich) the debounce logic I use has only 1 int of memory, regardless of the delay (jmkasunich) debounce logic: (jmkasunich) if (input = 1 ) { (jmkasunich) increment counter; (jmkasunich) if ( counter >= DELAY ) { (jmkasunich) output = 1; (jmkasunich) counter = DELAY (jmkasunich) } (jmkasunich) } else /* switch = 0 */ { (jmkasunich) decrement counter; (jmkasunich) if ( counter <= 0 ) { (jmkasunich) output = 0; (jmkasunich) counter = 0; (jmkasunich) } (jmkasunich) } (an0n_) hm how do you keep count of the time it takes for it to debounce? ((an0n_) I usually check the input and then wait a few cycles and if input still is 0 then continue (an0n_) :) (jmkasunich) heres an example, assuming DELAY = 4 (jmkasunich) first line is the input, second is the counter, third is output (an0n_) ok (jmkasunich) 0000101100011111001111111111111111 (jmkasunich) 0000101210012344323444444444444444 (jmkasunich) 0000000000000001111111111111111111 (jmkasunich) last one didn't quite line up right (jmkasunich) but you can see that it ignored the 1 sample and 2 sample positive going glitches, then turned on 4 samples after a steady stream of 111, and finally rejected a 2 sample low going glitch (an0n_) yeah (jmkasunich) if you set DELAY to zero, input = output, as you increase DELAY, you reject larger and larger glitches, but response time increases to match (jmkasunich) I'm trying to avoid as much inter-module coupling as possible... having the homing logic assume that 1) there is a debounce module, and 2) you can ask it the debounce time, is something I'd like to avoid.... for example, if your home switch is an optical pickup, you might not bother debouncing it at all (an0n_) yeah, but then the time would be 0 (an0n_) because if you have a optical pickup you set DELAY to 0 (an0n_) or write the debouncing logic in the algorithm.. (jmkasunich) true, but then you'd always need to use the debounce module - if that's the case, then might as well build the debounce into the homing code (jmkasunich) the upside of debounce built into the homing code is that the code would know DELAY (an0n_) yeah, and without adding delay when calling another module (an0n_) you could make the debounce code keep track of the velocity at the same time (jmkasunich) the downside is that means yet another config parameter for the motion controller - one of my pet peeves about emcmot is that it is a pain to add any config parameters... it takes more lines of code to add a config parameter than it does to use the param... spread throughout at least 5-6 files (jmkasunich) if DELAY is a parameter of a HAL debounce module, it is very easy (jmkasunich) if DELAY is a parameter of the motion controller it sucks bigtime (an0n_) hm, but is it really avoidable? (an0n_) if you are going to debounce and get it accurate (jmkasunich) I was counting on two things to make the error caused by DELAY acceptable: (jmkasunich) 1) if you are moving slow, the error is small (jmkasunich) 2) many machines use an index pulse for final homing (jmkasunich) the index pulse does not pass thru any debouncing delays * an0n_ nods (jmkasunich) anyway, thats why debounce is outside the homing/motion controller module (an0n_) but dont you have to account for switch and index pulse? (jmkasunich) if you have an index pulse, it works by finding the switch first (doesn't need to be perfect, just within one-half turn of the screw), then latching the final position when the index pulse arrives (an0n_) yeah, that's the simplest aproach :) (jmkasunich) wait for switch -> switch hit -> wait for index -> index hit -> latch position (jmkasunich) if you don't have an index pulse, then it is: (jmkasunich) wait for switch -> switch hit -> latch position (an0n_) hm, ok (jmkasunich) so you have to detect "switch hit" more accurately (an0n_) yeah (jmkasunich) in both cases, this is while moving at "latch_vel", which can be pretty darn slow (jmkasunich) the whole thing is more like: (jmkasunich) search for switch (fast) -> switch hit -> back off switch -> search for switch (slow) -> switch hit -> search for index (slow) -> index hit -> latch position (an0n_) yeah, that sounds good (jmkasunich) the "back off switch" part is what causes problems if the switch opens again once you pass it (an0n_) on, keeep in memory if you've moved back past it.. (jmkasunich) if the initial fast search passes the switch before it can stop and begin the "back off" step, the "back off" step will think it's already done, and the "slow search" phase will start, even tho it's on the wrong side of the switch (an0n_) hm, you have to add another latch as for that (an0n_) so it starts to search for the low when you pass it again.. (an0n_) like this: (an0n_) switch hit (rapid) > move back(slow) > switch(high)(start looking for low and latch position (jmkasunich) that's where edge triggered comes in... I was thinking of having the "back off" phase look for an on-to-off transition, not just an off state (an0n_) yeah that's what I mean :) (an0n_) making it work with switches that holds.. when you pass them isnt that hard either.. (jmkasunich) the trick is to make it work with both, without telling it which one it has (jmkasunich) (cause if you have switches that release when you pass them, you can't be sure you'll _always_ coast past them, so they might act like the other kind) (an0n_) is there really a way to make it adaptive like that without setting it anywhere? (jmkasunich) I hope so (an0n_) well look for a rising edge and if you are moving back look for a falling edge (an0n_) and if you get a falling edge when moving away then back up.. (an0n_) you can always start backing up in whichever case.. (jmkasunich) yeah, edge plus direction of motion lets you figure out where you are, edge alone doesn't (jmkasunich) you said "look for a rising edge and if you are moving back look for a falling edge", I think that's the key (jmkasunich) each phase of the homing operation is moving in a particular direction, and should be looking for a particular edge, not just a state (an0n_) yeah then it dosent matter if you pass it (an0n_) just keep track of direction and it will work (jmkasunich) an additional refinement is to pause between phases, enough to ensure that the table stops completely, so when you start moving again, you _know_ which direction you are going (an0n_) yeah (jmkasunich) (right now, as soon as the first fast search hits the switch, the code moves to the backoff state, even though the table hasn't decelled yet... if it came off the switch during decel, the backoff state would end when it shouldnt (an0n_) yeah (an0n_) move over switch(rapid) and keep track of direction > stop table > switch direction and back off switch(slowly) > latch position > if you have a index switch move until you hit it (jmkasunich) yep (an0n_) if you move very slowly when backing up you dont have to debounce it.. (jmkasunich) the mechanical switch contacts can still bounce (jmkasunich) but if moving very slowly, the error is small (an0n_) yeah (jmkasunich) error = DELAY * velocity (jmkasunich) it will be more-or-less constant, so it's not really an issue - the key with home is repeatibility, not absolute position (an0n_) yeah, if you need that precision you should use the index pulse anyway (an0n_) err if you want it to be 100% accurate every time (jmkasunich) those two things are key - look for edges, not states, and stop between phases....Thanks! being able to talk something thru like this is incredibly helpfull (an0n_) np, I enjoy discussing algorithms (jmkasunich) how to handle the index pulse is another thorny issue... so far I've taken the simple but potentially limiting approach (jmkasunich) some hardware devices (encoder counters) have the ability to reset the counter to zero on an index pulse (jmkasunich) others don't (jmkasunich) I assume none of them can do that... the hardware position counters simply count position relative to wherever the machine powered up (jmkasunich) that is called "motor_pos" in the code (jmkasunich) then an offset is added to that to produce "joint_position" which is what EMC uses (jmkasunich) when you hit the home switch (or index pulse) and want to set "joint_pos" to zero, I change the offset number, and leave motor_pos alone (jmkasunich) the advantage is that it works with virtually anything that you can imagine that generates "motor_pos", since there is no need to ever change motor_pos (an0n) hm, how do you distinguish if you are at 0 (an0n) or if the hardware resets the counter? (jmkasunich) the hardware would never reset the counter (an0n) some hardware devices (encoder counters) have the ability to reset the counter to zero on an index pulse (jmkasunich) in those cases where the hardware supports reseting it, that function can be enabled or disabled by software because you don't want to reset on every index pulse, just on the first one after hitting the home switch (an0n) oh ok (jmkasunich) so basically, my approach was "Not all hardware has this capability, so I'll assume no hardware has it, and do it myself" (jmkasunich) what I gain is simplicity (jmkasunich) what I lose is the ability to take advantage of that special hardware (an0n) cant you see if you get index pulses then your doing the rapid move's ? (an0n) when you do your move over the switch first.. (an0n) look for switch(fast) (an0n) if you do get index pulses, then assume hardware has index capability and use it (an0n) otherwise ignore it and just use the switch (jmkasunich) having index pulses is a feature of the encoder, begin able to reset the counter on an index pulse is a feature of the counter card, you can have one without the other (an0n) well, cant you get the pulse without reseting the counter card? (jmkasunich) yes (an0n) that's the most compatible aproach to it (jmkasunich) compatible is what I was aiming for... (jmkasunich) but.... (jmkasunich) the way I did it, your speed when latching the index pulse must be less than one encoder count per servo period, if you want to latch the index pulse to exactly one count (jmkasunich) the cards with the hardware latch can reset the counter to zero exactly on the index pulse, even at high speeds (jmkasunich) that is what my approach gives up, in the name of simplicity (an0n) yeah