As someone who has written a CNC machine controller software from scratch. That reads, writes, and sends gcide to the machine. As well as has some preprogrammed cycles that it can run without needing the CAD layer/cam layer for specific tasks like drilling, slotting, and pocketing at the click of a button on a work piece. I can with all honesty say, I know how complex that firmware must be to write and must say you have done a very fine job of it! I wish more CNC machines had some preprogrammed cycles like this directly written into their firmware. In fact the lack of preprogrammed cycles was the inspiration for the software I wrote. You put something together in CAD and send it. But after you get the part out, if you realize it needs another hole or slot for a wire or something that you didn't realize until you have the part in the real world already produced, you can go to CAD and add it but you really only have the option to reproduce the part unless you have the same exact mounting points. So I wrote simple routines to resolve this. It skips the CAD and CAM steps and you just align the machine, click the point to record the machine coordinates and then tell it which routine to run and it saves a ton of time trying to fix a 99% good part that was just missing a small feature that you didn't think about until you had it in hamd. You have done an awesome job. Its great you include your mistakes and thats how we all learn.
Amazing work, few recommendations: 1) dedicated E Stop relay. 2) I'm 99% sure most machine tools have the same issue, where it cuts power to the drivers. Most machines have a couple of hardware timers inside of them, and I'm pretty sure that's what they're for. 3) Having your Y lag behind like that makes me super nervous. The way most machine tools do this is if you're doing under a certain number of clicks per second on the MPG, it'll be direct read(1 click=1thou or whatever). Once the rate exceeds what the axis can do, it'll move to a velocity mode, where it just looks at the direction the MPG is turning, and travel at the max speed allowed(max travel speed of that axis, or less as set by parameters)
I agree on point 3 make the Y mpg velocity based when traveling above direct reading speed. I work at an automation equipment builder and I have seen too many crashes due to controls not stopping as soon as the operator stops their input.
@@Clough42 Lots of the time if you look at people jogging a large cnc, we'll just spin the outside of the wheel with a finger to kind of freewheel it. Thankyou for producing amazing content for us all to watch.
Yeah nr. 3 made me nervous too, way too easy to crash the wheel. To put it simple, for those who don't understand: Turning the crank changes the target for the Y axis (height). Because the Y axis is pretty slow, you can change the target of the axis faster than the axis itself can reach that target, so it will have to keep moving after you've stopped cranking to reach that target. The suggested fix: Basically just stop the movement of the Y axis when the crank stops / limit the rate of change of the target to the maximum speed of the Y axis, so the target can never exceed the actual location of the axis by much. Obviously, this has to be done for all axes. X and Z seem pretty fast, but it's still just better to implement it for all.
The intro was excellent as it shows your honesty and humility. "if everything goes well we'll actually grind something, and if everything doesn't go well we'll learn something"
Suggestion on E-Stop: Stop the spindle too. Right now, E-Stop kills the motion motors so that the table can move freely and unconstrained. Assume you dig the wheel into the work and hit E-Stop. The friction contact is going to drag the table _quickly_ to the left, plowing the wheel across the work. Worst case, you have a feature on the work to the right and significantly above grinding height. The wheel will plow into it, probably shatter, and maybe squirt the workpiece (and big chunks of wheel) out the closed garage door. Less than optimal. IMHO, ideally E-Stop would apply a brake to X rather than letting it move freely. Short of that, doing something to either break wheel contact with the work, or else also brake or at least coast down the wheel, seems like the safest option.
After reading how common these estop issues are. I think maybe someone should build the PCB with a completely seperate microcontroller dedicated to estop. This way if the main controller firmware has an error or gets stuck the seperate controller would not be effected. It seems easy enough to accomplish. It just needs to interrupt the signals and fully break the motors as well as flip a relay to stop the spindle. I think more cnc and controller boards should implement this ASAP. We really need a seperate chip that ensures that everything goes to break situation to fully stop it. I'm honestly surprised they are not already built this way. It could be done with an fpga, or microcontroller with ease and would simply sit between the main controller and the driver chip. It has one task, read the pin from the estop signal and brake the motors and flip the relay. And then reset when needed. This should be mandatory on every machine to be honest.
@@newmonengineering That's not done because it is not a safe way to do it. A microcontroller can fail and software as well: that's not as easy as you may think. Of course, It depends on the safety level you need to reach but usually industrial motor drives have 2 (for redundancy) inputs for Safe Torque Off (STO) which is one of the many safety functions. Other advanced systems can bring other safety features such as SLS, SBC, SLT and much more. it would be good if the ClearCore implements the STO feature but I guess it would raise the price for a fair bit.
One more suggestion, if I may, would be to color in red the appropriate digit(s) when switching resolution and jogging. This would be an user friendly addition to help focus the attention and offload the brain activity. Although column/row markers are not bad the way they are now, a little UX improvement won't hurt the visuals.
Perhaps some sort of indicator when 'thing' is changing - like when going from 2-1 on the steps remaining, highlight that digit background while the rapid-to-home is happening. example rough 2 finish 1 spark 1 First dustoff pass, show rough 2, jog to start and highlight 2, start of first rough unhighlight and change to 1. end of first rough, while jogging travel end to start position, highlight the digit 1. At the start of second pass, decrement the number as the highlight extinguishes again. Lastly, progressbar to show how long each pass is taking, and total job expected. That way it's obvious when to expect the safe jog move.
From my own job as a PLC programmer I have seen several slimline relays that have failed. I think you have to install a dedicated 2 channel safety relay. By cutting off the power supply you are loosing the control of the ramping down of the machine. Use of STO (safe torque off) is the way to go. I love to see your videos and the work you put into your project. Best regards Michael
I've continued to be "old school" about e-stop circuits, always cutting power to motors as well as telling the automation about the situation. Good move!
Yeah, it's tricky for sure. In some machines like our tormach, the z brake doesn't work/exist - so estop killing the motors causes the head to guaranteed crash. Having the estop kill motors is the safest in most other cases. :)
@@frollard Well, there are some ways 1. Add a counterweight / gas spring 2. Three phase rectifier (or how many phases the motor has) into power resistor and a relay 3. Pneumatic actuator or solenoid deactivates on E-stop and lets a spring apply physical brakes
That's really well done. The touch-off cycle is a nice feature. I've never used a surface grinder, and I think Y being the vertical axis would break my brain.
Just think about the movement of the tool as a graph plotted on your monitor, instead of one drawn on paper on your desk. On a monitor, Z always goes towards you or away from you, and Y is up and down. Simple, eh?
The convention in machine tools is always that z is parallel to the spindle axis and the others follow the right hand rule. But it gives me a headache too
@@sblack48 But that's just that: A convention, and a rather silly one at that I think (since the "spindle axis" on many machine tools nowadays are reorientable and not even a fixed direction in space, or indeed may have multiple spindels, such as 3 in 1 machines). Coordinate systems are arbitrary so you are free to pick any reference. It would make a lot more sense that X,Y = the point of the tool in the horizontal plane (eg, the lathe carriage or mill table position) and Z the point of the tool in the vertical, where applicable. That way all machine tools would be treated equally.
Another benefit is that a safety relay will be able to latch the E-stop state, it's not OK for the hazardous power to be restored or the machine to resume just by releasing the mushroom button.
When working with servos an E-STOP is your best place for your hand when you push the start button. Years ago when you tuned servos by twisting the shaft by hand, run away servos were common. HI speed pick and place gantries will self destruct if they run away.
That is a very well made user interface. It should be in text books for budding engineers. The struggle I am having explaining the the antique user interfaces of the engineering ilk where you have to remember a multitude of codes is the reason for most failures is immense. One comment: please show that there is a dust off pass in the UI. Many thanks, Annie
I do like how the user interface is designed. Very clear and complete, + surrounding which decimal is selected and so on definitely enhances user experience.
Great job so far! One thing that would ve great: noticed it only grinds using the front of the wheel in rough and finish. If you use the front of the wheel in the rough, then the back edge for finishing, you'll keep the part nice and cool not using a broke down edge in finishing. When you graduate to harder materials like 62 Hrc tool steely things, you'll be very glad you did. They break the wheel edge down so fast and put a ton of heat in the part.
Very well done. As others have said, your ideas are great, backed up by logic and reason. Layed out clearly, easy to read and use. Safety is implemented in a reasonable and actually a good, safe feature, without being obnoxious and needed to be bypassed. Obviously implemented by someone who operates machinery and not a bean counter sitting at a desk all day and dictating what's safe and what's not, without experience. Love to see what additions you make if v1.0 is laid out this well.
Glad to see a hardware E-stop. A safety control relay designed for E-stops is an improvement to make, I'd probably spring for an Allen-Bradley/Rockwell Automation one because it's something that *must not fail*.
Rockwell isn't the bastion of quality it once was, they discontinued the old Minotaur relays and the new ones are white-labeled Sick and Weidmuller. But any safety relay from any brand will have redundant, fault monitoring and failsafe parallel input channels, redundant, fault monitoring and failsafe series output switches, and the performance of those elements will be tested and certified. Whatever variety you like - AB, Euchner, Banner, Dold, whatever - will be orders of magnitude more reliable than that single-channel reed relay and contactor. Heck, I'd never use it on a machine that an employee of one of my customers would be asked to trust, but I bet you can get import junk that would be reliable for personal use.
That is a pretty impressive first run. I hadn't realized what a comprehensive control system you were aiming for, and I'd say you really knocked it out of the park. the glitches are minimal, you're on top of them already, and it looks like you're just down to squashing a few bugs at this point. I don't know if you're planning to market this control system, given the much smaller user base than the ELS, but it looks like you're building a solid product. Cheers!
A couple of suggestions. The whole machine probably should be inside of an enclosure. At least, a shield in between the operator and the wheel is necessary. If that wheel breaks apart, you don't want to get by shrapnel. A part can also get flung off. You also don't want dust and coolant on that nice touch screen. The control panel also is connected to the table, which isn't ideal. That would annoy me if the controls moved all over the place. You really want that emergency stop button to always be in the same place. Overall, it works well so far.
I'm in the medical equipment filed, and the times I've tested something on a toy model are numerous. The real world comes to bite me when all that's in the tube of a MRI machine, never really damaged one, but everything has a some special characteristics in 3T magnetic field.
Very cool system. A thought for a safety upgrade based on my personal experience manually controlling my surface grinder. It would seem to me that there should be no situation, at least that I can think of at this moment, that you would want to randomly drive down in the "Y" direction more than a roughing increment if you are manually turning the jog wheel but are already at work height. Or work height resulting from last grind. I can visualize you having for some reason stopped the servos with the wheel over the workpiece and then intending to manually withdraw the grinding wheel up in the "Y" direction but in the confusion actually turning the jog dial in the wrong direction and thus ruining the workpice. Perhaps you have already done something to prevent this from happening but I didn't hear anything in your discussion. There may be reasons to enter this zone such as for wheel dressing or something else so it should be enableable but not without explicitly making the decision to enter the danger zone. Hope this might be of some help and I hope my quick description is clear enough to get across my concern.
In Auto how do you know what cycle the machine is in at the moment? If the roughing count is zero, is it doing the last roughing pass or is it doing the first finishing pass. I suggest adding a red indicator like you have for the active axis. This could be useful if you've stopped or paused the machine and intend to continue, you'll know what it will continue with.
I learned my lesson on software e-stops with some hardware at work. On a rate table (Put DUT on the table and it spins it at the programmed rate) there was an e-stop, that would command a max rate deceleration. Well thats cool, but if you opened the chamber (triggering the e-stop with an interlock) grab the table and force it to stop (smooth aluminum table, not that much inertia with no workpiece on it ) and then let go, the machine would apply max torque to accelerate it back up to the programmed deceleration ramp rate. Very cool safety mechanism, capable of applying max torque to a stopped table, love it. Dedicated hardware for e-stop (Like you pulling power to the servos) is the way to go.
Interesting video, as always. I watch a lot of @EdgePrecision videos. In one of his recent videos, he was describing how he doesn't like the controller on his smaller "home shop" CNC, compared to the one on his bigger machine, in his "main shop". Specifically, the way the jog wheel functions. His home shop CNC (and it looks like your grinder works the same way) stores up the destination position of a jog, and moves to it unless you e-stop to cancel it. Whereas his "big" machine (I forget the manufacturers of each) only continues jogging while the jog wheel is physically turning. In his opinion, this is much safer and reduces the risk of the machine crashing into end stops, work pieces or operators (especially if the wrong rapid speed is selected by mistake). You could also do a hybrid version, I suppose, that detected the operator turning the jog wheel "back" to immediately override any "in flight" jog. It's just something that may be worth considering. Thanks for the videos. Stay safe out there.
Many years ago i was working on the data display part of a shock absorber tester. Arrived onsite one day to observe a flurry of rewiring. Turns out the microconttoller froze with the main motor running resulting in some 4 tons of machine bouncing around. Yup, estop was wired to the uC only. It was rewired to drive a big contactor to cut power. Lesson, estop must cut power first and tell the controller about it a distant second
So a few things I see (sorry this is my first post to TH-cam but I feel like I should say something, and other comments seam to back this up) - Use a two channel safety relay for e-stop function, they are more expensive but recommended for PLd or PLe (Which I think this falls into) - See comments on STO functionality, and yes, spindle should stop on e-stop - You probably want a fuse or circuit breaker on the output of your 24V supply. I've used this exact supply before and it does not fold over on an over-current, it can exceed rated output current on a short because it is a power converter, so if output voltage is low(like in a short situation), input current may not be sufficient to trip AC breaker, but output current could exceed rating of wiring. - (minor) for CE, Earth ground is Yellow with green stripe (like the enclosure came with) - (somewhat minor, this is a CE requirement, but you're not necessarily CE) De-engaging the E-Stop should not automatically re-enable movement. There should be some operator action required (such as pressing an enable button) to allow motion or other dangerous operation. In general, very cool, there is a lot more depth and effort then you lead on in the video (You'd never be able to cover it all without making 10 hour videos) so very impressive. You've almost turned this into a product...
I've been blessed with another Clough42 video. YT only recommended your videos to me recently and I've been thoroughly enjoying them. I like how you're so organised, thoughtful and knowledgeable, and manage to deliver information it in such a casual, down to eath way. Looking forwards to getting through your backlog of videos and more to come. Happy holidays!
This is You tube gold. Unknown home creators doing amazing things! This would be a game changer or My business making coin dies where the finish must be really nice. the finish and rough settings are really nice
Congratulations James! That is a piece of art. A quick suggestion for ease of use would be to put lasers in the head to set the X and Z limits withouy any contorting. I was also thinking about a system to identify the highest spot on the workpiece to set the working Y but that might be very difficult. Anyway, fantastic job, thanks for sharing
Very nice, will have to get up the energy to tackle my old surface grinder. I can tell you spent many hours pounding out the code. I'll there were a bunch of times you looked back and thought what the hell was I smoking when I wrote that function. The UI looks really nice. While watching the cutting demo, I thought; bet he could add an IR sensor to detect the sparks for an auto touchoff cycle.
Very nicely done. I do you have a comment / recommendation for your flat grind cycle. Instead of specifying the number of rouging passes have the input for total stock removal and then let the software calculate the passes. Another handy option that we use on our chevelier is an input for additional stock removal. If you need to take off another .0002" input that value to follow that I'm out instead of the total amount.
This was probably the most detailed and enjoyable series I have ever watched. From the beginning to end, there isn’t a single episode that I haven’t found totally engrossing. Thanks James, what’s your next project going to be? I can’t wait.
Impressive bit of mechatronics and coding so far, with another nicely edited/narrated video too. Good implementation of the precision units/axis indicators on the display. Got U/X suggestions to enhance safety/usability: 1) Distinguish between status indicators (aka 'Homed' and 'Idle/Run/E-Stop') vs the touch screen's input buttons with a different style/colors to make them easier to identify at a glance. 2) Clustering all status indicators in a single region of the screen will make them readable in a single glance (instead of opposite corners). 3) Provide a redundant units indicator next to the coordinate readouts or change color for metric vs imperial to avoid crashes due to mistaken units. My inner graphic designer wishes the negative symbol doesn't jump around when the X-axis rolls over from 0-9 to 10+ (but this is just an aesthetic quibble).
On the E-stop; Make sure you know what will happen when you re-engage the power after using the e-stop. Don't ask me how I know but if axis has been manually moved to fix the crash/hide the evidence, and the controller has been correcting for it, but the motor drive is off, things can move very abruptly and surprisingly when power comes back on.
Flippin' awesome, James. Some of the programming stuff and the references to the different electronic hardware went a bit over my head (and I'm an engineer!), but I was able to understand most of it thanks to your clear and detailed explanations. I think I have mentioned it before on another video, but what makes your channel stand out is the commentary. You don't repeat yourself (a rarity on TH-cam) and you have clearly thought out in advance how best to let an audience with very varied knowledge and experience know what you are doing and why. Oh, and the engineering is pretty decent too.🙂 Right then, I'm off to continue building my 3kW plywood thickness sander. I'm going to feel like a caveman unless I manage to put this video out of my head for a couple of hours. Keep 'em coming, mate. Geoff in France.
It might be as simple as using > instead of >= for your bounds check. Meaning of the position is exactly equal to the boundary, it can't run another step because it would go out of bounds, but it can't advance to the next state because it hasn't hit > boundary yet.
I can see how end-of-pass detection would turn into a very interesting discrete math and logic problem even without the complexity of an interrupt handler and their limitations. It seems there are multiple scales so even restricting yourself to integer math won't eliminate roundoff. I won't second-guess code and hardware I've never seen - this is a tedious, subtle, and challenging problem and I wish you the best in sorting it out.
At 4:30, you had moved the table but the DRO position didn’t seem to update. Is this because of the means by which the position is determined, or because of the ESTOP state software routine? Yes, I am an engineer. 😂 Man, I really like the flow you have created. You put a lot of thought into this. Good work!
You shouldn't go to z=0 at each pass start. By this you cause uneven wheel wear. Right technique is start next pass where previous ends. Conventional grinders do that by moving back and forth between z endstops and advacing y at each endstop.
How sensitive is the touch screen to errant touches? I'd be worried that a drop off water/coolant or some chips/swarf falling on the screen accidentally pressing buttons during automatic operation. You might also consider adding a "reset" button to clear errors/alarms instead of cycling the e-stop switch.
The cycle should start with the wheel to the right of the part. This prevents the wheel riding over the part and shattering if the cut is too deep. With traditional hydraulic feed the part can be pulled under the wheel. It is also usual to stop the feed with the wheel on the left of the part at the traverse end. This keeps hands away from the wheel when loading or unloading. The cut can be added at each Y reverse to allow the X traverse to keep moving.
Neat, really really neat! 🤩 I see other people are mentioning dedicated e-stop relays and such, so I’m not gonna repeat that. However, I’m certain that one or two more videos down the line, the comments section will have nothing more to complain about 😅 Also, I love that you sprinkle in some metric measurements now and then. Both because it seems to annoy other viewers, but also because it helps my european/metric brain to think in terms of organic/grass fed fractional freedom units! 😂
Wow James great to see it work so well first up I look forward to see the total finished product. Here is a little something to think about why not cost it out including all labor and hardware and just see how expensive this upgrade cost. May be give your viewers a guessing competition.
The amount of thought you’ve put into the workflows is really impressive. It really shows through in the HMI you’ve developed. A truly Amazing result! 👌
I love this series of videos about this build! Congratulation James, you really do inspire me! While I was watching how you introduced the functions of the passes and the auto run, I was thinking it would be beneficial to sign on the GUI what cycle the machine is... the way how you mark the DRO display what will be moving with the red bars, that could be a matching solution for the passes... you can add a little red line mark beside the passes and the counter also signing what is left from the cycle...I've noticed that. It makes the GUI a bit more clear to understand what is going on, and it will create the system more fail proof and safe...
I left a comment last night from my tablet, but it disappeared, so I'm trying again this morning from my PC. TH-cam did give me an error, so maybe it was that. I really wish TH-cam would explain "why" a comment gets deleted, or ghosted... Regarding the position that can't be reached...It's probably more complicated than just this, but I'm just sharing the idea. Snap your internal positional values to the known position by using a snapping formula: Math.Round(value / snapDelta) * snapDelta In your use case, make snapDelta the step resolution of the stepper motors. Now do all your conditional checks on the snapped positions rather than your real positions. Good luck, and great job! This project is turning out awesome!
Fantastic! Has it occurred to you that with complete software control it can now do decorative grinding? Zig-zag across or a circular patterns. You could even grind concave or convex shapes, though touching off on an irregular height part would be, uh, challenging...
As others have said.... Awesome programming job. Everything just made sense. Does it display events during the multi pass auto mode, ie. Spark Pass, Brush Pass? Such a bang up job with the enclosure and your decision to go with this layout was spot on. I was surprised you did not go with a joystick config to speed up setup positions. I was just curious. Thanks so much for all you record and share. Have a happy holiday and prosperous New Year!
Amazing build. I want one! I’m picturing rev2 having a horizontal and vertical edge finder pair to locate the current state of the wheel for dressing, like the optical ruby edge finders for the mill.
Nice mate, I hope you put a lowpass filter error check on the windy wheel, they do fail, it happend to me once. Have the measured signal subtracted from a PT1 filtered signal. If the absolute subracted value is greater than some vaue then the windy wheel has lost track. Not even big dollar CNC machines have that feature.. This inch stuff is killing my brain.
Someone else was mentioning in another comment that this actually is standard for grinders and horizontal mills. Specifically, the standard (and there's an actual ISO standard about this) for any machine tool is that Z is along the axis of rotation, and then X and Y are determined by right-hand rule from there. That also applies to lathes as well, with X and Z as the primary directions of motion.
You might want to add hardware that will sense the actual load on the grinding wheel by measuring the actual power that's being expended. If the power increase exceeds some threshold, your initial cut might be too great. If the "power-trip" activates the safe thing is to stop the positioning servos and get the operator involved.
your starting the pass from the left side of the table. Given the direction the wheel turns If the first contact is too deep it will try pull the work into the stone. If you start the pass from the right side it will try push the part out which is much safer Don't ask me how I know that 😨
Hello, This is the only right way to connect a E-stop. The hardware diconnect circuit is more important then the "status" input on the micro controller
With an interrupt driven system, I would pass a value into the interrupt routine. A tiny bit of code to quickly determine a value for *number-of-passes would be very simple. This provides a sanity check to make certain all passes have been completed and gives a break out of routine point. This also provides a much simpler method than relying on odd (sometimes) values derived from the motors. Especially if there is a value in a decimal place that you are not checking. One other method is to use the derived number-of-passes to check then add 0.0001 to your routine break command to remove afore mentioned minor error in motor position calculations. Adding the 0.0001 will break it out of its loop, but only after number-of-passes has been completed. Sort of like - If passes is greater than or equal to X ---- add 0.0001 to calculated position Additional logic might need to be changed to - if current position is greater than or equal to calculated position - break out of routine Keeping the bulk of this inside a routine also does not affect any global calculations or variables. Nothing really changes besides One other thing that I've done for motion value checks is to multiply the number by the precision and convert to absolute value . You want 10 thousandths precision, then multiply the values by 10,000. Int temp_pos = abs(position * 10000) Int temp_calc_pos = Abs(read_value * 10000) Run the check on the temp values instead or skip the variable assignation and do the conversion in the check. This gets you the precision that you want and deletes hanging decimal values. Plus, you can still add 1 whole number to the calculated value after number of passes completes and run the check on that. Of course I am just guessing, because I have not seen your code and I might be out in left field here. I've delt with motion based calculations before and have seen this problem. I've also had to deal with drift (complete nightmare I must say) but anyhow.... Drift is not a problem you will likely have to adjust for, with this motion system. Just some thoughts, take it as you like.
@30:09 The DRO is reading -0.00108, but according the settings (2 rough passes at 0.00050 and 1 finish at 0.00010), the DRO should read -0.00110 on Y Or am I wrong?
As to the bug…Michael Bolton: “I must've put a decimal point in the wrong place or something. ----, I always do that. I always mess up some mundane detail."
26:04 If you had a red and green laser on pointing down on the bed on the x/z axis, you wouldn’t need to look around the machine to see if it’s past the work piece to set the start and end points. Reducing the amount of travel (and thus time) that the bed moves.
Suggestion for the touch off, let the wheel only rise after the touch off. Or don't allow the touch off until safe height is set and after touch off make it move to safe plane automatically.
You may have answered this before, but why did you choose the Y axis for vertical travel instead of Z? As a long time CNC programmer it seems counterintuitive. I get that conventional practice is to have Z parallel to the spindle axis, but in milling the Z direction relates to depth of cut which is why it seems odd using the Y axis.
Someone else was mentioning in another comment that this is standard for grinders and horizontal mills -- and, specifically, having Z parallel to the rotating axis isn't just the conventional practice; there's an actual ISO standard about it. But, yes, it feels odd to me, too! I would probably put some labels on the machine indicating which axis is which.
I think the e-stop circuit should have a reset button. I know the slim relay is not very reliable. The contact in the relay is not very substantial. If its wired NO then the e-stop circuit will not engage when the relay fails. If you decide to use this relay in the future get a dozen. Outstanding job converting the grinder to cnc. The controller, the programing and the control cabinet look great.
(2:03) I'm looking at the ClearCore controller, and remembering it had a DE-9 connector, and that you had... very strong opinions about their use (aka don't use em). I'm wondering why you dislike these connectors and what issues you've had with them? I've never come across this before and wanting to learn. Thanks always for the videos, they are very entertaining & educational
Cool project, been following it from the beginning. Your display is excellent and the logic you built into this is really well thought out (obviously a developer!)! I love how the coordinate system works that you can re-reference the zero point without moving the start/end/safe values. Some thoughts? I do wonder about your Y axis control, and whether you should be buffering in wheel input since the travel speed is so slow compared to how fast you can spin that wheel. I realize you can hit the Estop, but I think you can probably prevent this in the first place. Did you consider that? I'm wondering if the bug where it doesn't detect the end is if the travel from start/end is under some certain amount that you have set, or some sort of rounding issue. At 23:30, I think it would be helpful to have an on-screen indicator of which pass it's running. Since you have live controls for rough/finish/spark, what happens if it's in a finish pass, and then you add another rough pass, does it go back to the beginning? Another software enhancement would to have system presets for rough/finish/spark, (maybe by material type?), or perhaps even user-saved values. Sorry, just thinking out loud as a fellow developer! Certainly not taking away anything from this amazing work.
Maybe an indicator on the feed buttons to indicate if a run has been performed since feed has been pushed, or some other uix to prevent accidentaly pressing then multiple times?
As someone who has written a CNC machine controller software from scratch. That reads, writes, and sends gcide to the machine. As well as has some preprogrammed cycles that it can run without needing the CAD layer/cam layer for specific tasks like drilling, slotting, and pocketing at the click of a button on a work piece. I can with all honesty say, I know how complex that firmware must be to write and must say you have done a very fine job of it! I wish more CNC machines had some preprogrammed cycles like this directly written into their firmware. In fact the lack of preprogrammed cycles was the inspiration for the software I wrote. You put something together in CAD and send it. But after you get the part out, if you realize it needs another hole or slot for a wire or something that you didn't realize until you have the part in the real world already produced, you can go to CAD and add it but you really only have the option to reproduce the part unless you have the same exact mounting points. So I wrote simple routines to resolve this. It skips the CAD and CAM steps and you just align the machine, click the point to record the machine coordinates and then tell it which routine to run and it saves a ton of time trying to fix a 99% good part that was just missing a small feature that you didn't think about until you had it in hamd. You have done an awesome job. Its great you include your mistakes and thats how we all learn.
Does sending "gcide" to the machine eliminate bugs from the gcode?
Ditto former real time sw engineer.
Amazing work, few recommendations:
1) dedicated E Stop relay.
2) I'm 99% sure most machine tools have the same issue, where it cuts power to the drivers. Most machines have a couple of hardware timers inside of them, and I'm pretty sure that's what they're for.
3) Having your Y lag behind like that makes me super nervous. The way most machine tools do this is if you're doing under a certain number of clicks per second on the MPG, it'll be direct read(1 click=1thou or whatever). Once the rate exceeds what the axis can do, it'll move to a velocity mode, where it just looks at the direction the MPG is turning, and travel at the max speed allowed(max travel speed of that axis, or less as set by parameters)
I agree on point 3 make the Y mpg velocity based when traveling above direct reading speed. I work at an automation equipment builder and I have seen too many crashes due to controls not stopping as soon as the operator stops their input.
This is an excellent idea. I was already planning to reduce the resolution on Y to prevent that, but switching to velocity mode would also be good.
@@Clough42 Lots of the time if you look at people jogging a large cnc, we'll just spin the outside of the wheel with a finger to kind of freewheel it. Thankyou for producing amazing content for us all to watch.
I wonder if you can also add a logarithmic scale to the velocity input so faster you spin - progressively faster it goes.
Yeah nr. 3 made me nervous too, way too easy to crash the wheel. To put it simple, for those who don't understand: Turning the crank changes the target for the Y axis (height). Because the Y axis is pretty slow, you can change the target of the axis faster than the axis itself can reach that target, so it will have to keep moving after you've stopped cranking to reach that target.
The suggested fix: Basically just stop the movement of the Y axis when the crank stops / limit the rate of change of the target to the maximum speed of the Y axis, so the target can never exceed the actual location of the axis by much.
Obviously, this has to be done for all axes. X and Z seem pretty fast, but it's still just better to implement it for all.
The intro was excellent as it shows your honesty and humility.
"if everything goes well we'll actually grind something, and if everything doesn't go well we'll learn something"
Suggestion on E-Stop: Stop the spindle too. Right now, E-Stop kills the motion motors so that the table can move freely and unconstrained. Assume you dig the wheel into the work and hit E-Stop. The friction contact is going to drag the table _quickly_ to the left, plowing the wheel across the work. Worst case, you have a feature on the work to the right and significantly above grinding height. The wheel will plow into it, probably shatter, and maybe squirt the workpiece (and big chunks of wheel) out the closed garage door. Less than optimal.
IMHO, ideally E-Stop would apply a brake to X rather than letting it move freely. Short of that, doing something to either break wheel contact with the work, or else also brake or at least coast down the wheel, seems like the safest option.
The spindle contactor state should also be on the E stop circuit to avoid running grinding programs without the spindle running
After reading how common these estop issues are. I think maybe someone should build the PCB with a completely seperate microcontroller dedicated to estop. This way if the main controller firmware has an error or gets stuck the seperate controller would not be effected. It seems easy enough to accomplish. It just needs to interrupt the signals and fully break the motors as well as flip a relay to stop the spindle. I think more cnc and controller boards should implement this ASAP. We really need a seperate chip that ensures that everything goes to break situation to fully stop it. I'm honestly surprised they are not already built this way. It could be done with an fpga, or microcontroller with ease and would simply sit between the main controller and the driver chip. It has one task, read the pin from the estop signal and brake the motors and flip the relay. And then reset when needed. This should be mandatory on every machine to be honest.
@@newmonengineering I wouldn't want a microcontroller in the estop loop. There are multi-input safety relays for this.
@@newmonengineering That's not done because it is not a safe way to do it. A microcontroller can fail and software as well: that's not as easy as you may think. Of course, It depends on the safety level you need to reach but usually industrial motor drives have 2 (for redundancy) inputs for Safe Torque Off (STO) which is one of the many safety functions. Other advanced systems can bring other safety features such as SLS, SBC, SLT and much more.
it would be good if the ClearCore implements the STO feature but I guess it would raise the price for a fair bit.
@@Clough42 For advanced logic Estop I have started using the BANNER safety PLCs, SC10 is the small one.
The UI is excellently designed. Maybe add some indicators next to "Rough" "Finish" and "Spark" to show what kind of pass it is taking?
One more suggestion, if I may, would be to color in red the appropriate digit(s) when switching resolution and jogging. This would be an user friendly addition to help focus the attention and offload the brain activity. Although column/row markers are not bad the way they are now, a little UX improvement won't hurt the visuals.
Perhaps some sort of indicator when 'thing' is changing - like when going from 2-1 on the steps remaining, highlight that digit background while the rapid-to-home is happening.
example rough 2 finish 1 spark 1
First dustoff pass, show rough 2,
jog to start and highlight 2, start of first rough unhighlight and change to 1.
end of first rough, while jogging travel end to start position, highlight the digit 1. At the start of second pass, decrement the number as the highlight extinguishes again.
Lastly, progressbar to show how long each pass is taking, and total job expected. That way it's obvious when to expect the safe jog move.
Wow, I have run CNC grinders before and this is the most intuitive interface I have seen!
Maybe because it was programed by a machinist?
Me too.
Reminds me of the HAAS controllers.
From my own job as a PLC programmer I have seen several slimline relays that have failed. I think you have to install a dedicated 2 channel safety relay.
By cutting off the power supply you are loosing the control of the ramping down of the machine. Use of STO (safe torque off) is the way to go.
I love to see your videos and the work you put into your project.
Best regards
Michael
I've continued to be "old school" about e-stop circuits, always cutting power to motors as well as telling the automation about the situation. Good move!
Yeah, it's tricky for sure. In some machines like our tormach, the z brake doesn't work/exist - so estop killing the motors causes the head to guaranteed crash. Having the estop kill motors is the safest in most other cases. :)
as someone who has seen wheels come apart from that, stopping the spindle should be a priority
@@frollard Well, there are some ways
1. Add a counterweight / gas spring
2. Three phase rectifier (or how many phases the motor has) into power resistor and a relay
3. Pneumatic actuator or solenoid deactivates on E-stop and lets a spring apply physical brakes
That's really well done. The touch-off cycle is a nice feature. I've never used a surface grinder, and I think Y being the vertical axis would break my brain.
It does hurt sometimes.
Just think about the movement of the tool as a graph plotted on your monitor, instead of one drawn on paper on your desk. On a monitor, Z always goes towards you or away from you, and Y is up and down. Simple, eh?
I know technically what he is using is correct, but I think I would still call the vertical axis "Z" anyway. It makes no difference.
The convention in machine tools is always that z is parallel to the spindle axis and the others follow the right hand rule. But it gives me a headache too
@@sblack48 But that's just that: A convention, and a rather silly one at that I think (since the "spindle axis" on many machine tools nowadays are reorientable and not even a fixed direction in space, or indeed may have multiple spindels, such as 3 in 1 machines). Coordinate systems are arbitrary so you are free to pick any reference. It would make a lot more sense that X,Y = the point of the tool in the horizontal plane (eg, the lathe carriage or mill table position) and Z the point of the tool in the vertical, where applicable. That way all machine tools would be treated equally.
This is the result of the end user being the programmer. Oh ya, and a LOT of hard work!
You may want to consider a dedicated safety relay in your E-stop circuit. They are readily available
Another benefit is that a safety relay will be able to latch the E-stop state, it's not OK for the hazardous power to be restored or the machine to resume just by releasing the mushroom button.
26:50 Would added guide laser make it easier to setup?
It just looks awkward to have to look behind the grinding wheel to setup the work envelope.
When working with servos an E-STOP is your best place for your hand when you push the start button. Years ago when you tuned servos by twisting the shaft by hand, run away servos were common. HI speed pick and place gantries will self destruct if they run away.
In the industrial world, after an estop you have to hit the power on button, or in your case the green button.
That is a very well made user interface. It should be in text books for budding engineers. The struggle I am having explaining the the antique user interfaces of the engineering ilk where you have to remember a multitude of codes is the reason for most failures is immense. One comment: please show that there is a dust off pass in the UI. Many thanks, Annie
I do like how the user interface is designed. Very clear and complete, + surrounding which decimal is selected and so on definitely enhances user experience.
Great job so far! One thing that would ve great: noticed it only grinds using the front of the wheel in rough and finish. If you use the front of the wheel in the rough, then the back edge for finishing, you'll keep the part nice and cool not using a broke down edge in finishing.
When you graduate to harder materials like 62 Hrc tool steely things, you'll be very glad you did. They break the wheel edge down so fast and put a ton of heat in the part.
Very well done. As others have said, your ideas are great, backed up by logic and reason. Layed out clearly, easy to read and use.
Safety is implemented in a reasonable and actually a good, safe feature, without being obnoxious and needed to be bypassed. Obviously implemented by someone who operates machinery and not a bean counter sitting at a desk all day and dictating what's safe and what's not, without experience.
Love to see what additions you make if v1.0 is laid out this well.
Glad to see a hardware E-stop. A safety control relay designed for E-stops is an improvement to make, I'd probably spring for an Allen-Bradley/Rockwell Automation one because it's something that *must not fail*.
Rockwell isn't the bastion of quality it once was, they discontinued the old Minotaur relays and the new ones are white-labeled Sick and Weidmuller. But any safety relay from any brand will have redundant, fault monitoring and failsafe parallel input channels, redundant, fault monitoring and failsafe series output switches, and the performance of those elements will be tested and certified. Whatever variety you like - AB, Euchner, Banner, Dold, whatever - will be orders of magnitude more reliable than that single-channel reed relay and contactor. Heck, I'd never use it on a machine that an employee of one of my customers would be asked to trust, but I bet you can get import junk that would be reliable for personal use.
A lesson I've learned is to always buy an HMI that is a little larger than you think you need.
You're not wrong. I bought the biggest one they had.
That is a pretty impressive first run. I hadn't realized what a comprehensive control system you were aiming for, and I'd say you really knocked it out of the park. the glitches are minimal, you're on top of them already, and it looks like you're just down to squashing a few bugs at this point. I don't know if you're planning to market this control system, given the much smaller user base than the ELS, but it looks like you're building a solid product. Cheers!
A couple of suggestions. The whole machine probably should be inside of an enclosure. At least, a shield in between the operator and the wheel is necessary. If that wheel breaks apart, you don't want to get by shrapnel. A part can also get flung off. You also don't want dust and coolant on that nice touch screen. The control panel also is connected to the table, which isn't ideal. That would annoy me if the controls moved all over the place. You really want that emergency stop button to always be in the same place. Overall, it works well so far.
I'm in the medical equipment filed, and the times I've tested something on a toy model are numerous. The real world comes to bite me when all that's in the tube of a MRI machine, never really damaged one, but everything has a some special characteristics in 3T magnetic field.
Very cool system. A thought for a safety upgrade based on my personal experience manually controlling my surface grinder. It would seem to me that there should be no situation, at least that I can think of at this moment, that you would want to randomly drive down in the "Y" direction more than a roughing increment if you are manually turning the jog wheel but are already at work height. Or work height resulting from last grind.
I can visualize you having for some reason stopped the servos with the wheel over the workpiece and then intending to manually withdraw the grinding wheel up in the "Y" direction but in the confusion actually turning the jog dial in the wrong direction and thus ruining the workpice. Perhaps you have already done something to prevent this from happening but I didn't hear anything in your discussion.
There may be reasons to enter this zone such as for wheel dressing or something else so it should be enableable but not without explicitly making the decision to enter the danger zone.
Hope this might be of some help and I hope my quick description is clear enough to get across my concern.
In Auto how do you know what cycle the machine is in at the moment? If the roughing count is zero, is it doing the last roughing pass or is it doing the first finishing pass. I suggest adding a red indicator like you have for the active axis. This could be useful if you've stopped or paused the machine and intend to continue, you'll know what it will continue with.
I learned my lesson on software e-stops with some hardware at work. On a rate table (Put DUT on the table and it spins it at the programmed rate) there was an e-stop, that would command a max rate deceleration. Well thats cool, but if you opened the chamber (triggering the e-stop with an interlock) grab the table and force it to stop (smooth aluminum table, not that much inertia with no workpiece on it ) and then let go, the machine would apply max torque to accelerate it back up to the programmed deceleration ramp rate. Very cool safety mechanism, capable of applying max torque to a stopped table, love it. Dedicated hardware for e-stop (Like you pulling power to the servos) is the way to go.
Interesting video, as always. I watch a lot of @EdgePrecision videos. In one of his recent videos, he was describing how he doesn't like the controller on his smaller "home shop" CNC, compared to the one on his bigger machine, in his "main shop". Specifically, the way the jog wheel functions. His home shop CNC (and it looks like your grinder works the same way) stores up the destination position of a jog, and moves to it unless you e-stop to cancel it. Whereas his "big" machine (I forget the manufacturers of each) only continues jogging while the jog wheel is physically turning. In his opinion, this is much safer and reduces the risk of the machine crashing into end stops, work pieces or operators (especially if the wrong rapid speed is selected by mistake). You could also do a hybrid version, I suppose, that detected the operator turning the jog wheel "back" to immediately override any "in flight" jog. It's just something that may be worth considering. Thanks for the videos. Stay safe out there.
Incredible work sir. You are a modern Renaissance man. Software, hardware, electrical and mechanical. Well done and congrats it's an epic achievement.
Many years ago i was working on the data display part of a shock absorber tester. Arrived onsite one day to observe a flurry of rewiring. Turns out the microconttoller froze with the main motor running resulting in some 4 tons of machine bouncing around. Yup, estop was wired to the uC only. It was rewired to drive a big contactor to cut power. Lesson, estop must cut power first and tell the controller about it a distant second
So a few things I see (sorry this is my first post to TH-cam but I feel like I should say something, and other comments seam to back this up)
- Use a two channel safety relay for e-stop function, they are more expensive but recommended for PLd or PLe (Which I think this falls into)
- See comments on STO functionality, and yes, spindle should stop on e-stop
- You probably want a fuse or circuit breaker on the output of your 24V supply. I've used this exact supply before and it does not fold over on an over-current, it can exceed rated output current on a short because it is a power converter, so if output voltage is low(like in a short situation), input current may not be sufficient to trip AC breaker, but output current could exceed rating of wiring.
- (minor) for CE, Earth ground is Yellow with green stripe (like the enclosure came with)
- (somewhat minor, this is a CE requirement, but you're not necessarily CE) De-engaging the E-Stop should not automatically re-enable movement. There should be some operator action required (such as pressing an enable button) to allow motion or other dangerous operation.
In general, very cool, there is a lot more depth and effort then you lead on in the video (You'd never be able to cover it all without making 10 hour videos) so very impressive. You've almost turned this into a product...
I've been blessed with another Clough42 video. YT only recommended your videos to me recently and I've been thoroughly enjoying them. I like how you're so organised, thoughtful and knowledgeable, and manage to deliver information it in such a casual, down to eath way. Looking forwards to getting through your backlog of videos and more to come. Happy holidays!
This is You tube gold. Unknown home creators doing amazing things! This would be a game changer or My business making coin dies where the finish must be really nice. the finish and rough settings are really nice
Congratulations James! That is a piece of art. A quick suggestion for ease of use would be to put lasers in the head to set the X and Z limits withouy any contorting. I was also thinking about a system to identify the highest spot on the workpiece to set the working Y but that might be very difficult. Anyway, fantastic job, thanks for sharing
Very nice, will have to get up the energy to tackle my old surface grinder. I can tell you spent many hours pounding out the code. I'll there were a bunch of times you looked back and thought what the hell was I smoking when I wrote that function. The UI looks really nice.
While watching the cutting demo, I thought; bet he could add an IR sensor to detect the sparks for an auto touchoff cycle.
Wow…what an elegant piece of work - well done James.
Very nicely done.
I do you have a comment / recommendation for your flat grind cycle.
Instead of specifying the number of rouging passes have the input for total stock removal and then let the software calculate the passes.
Another handy option that we use on our chevelier is an input for additional stock removal. If you need to take off another .0002" input that value to follow that I'm out instead of the total amount.
Thanks!
You're welcome. Thank you!
This was probably the most detailed and enjoyable series I have ever watched. From the beginning to end, there isn’t a single episode that I haven’t found totally engrossing. Thanks James, what’s your next project going to be? I can’t wait.
Impressive bit of mechatronics and coding so far, with another nicely edited/narrated video too. Good implementation of the precision units/axis indicators on the display.
Got U/X suggestions to enhance safety/usability:
1) Distinguish between status indicators (aka 'Homed' and 'Idle/Run/E-Stop') vs the touch screen's input buttons with a different style/colors to make them easier to identify at a glance.
2) Clustering all status indicators in a single region of the screen will make them readable in a single glance (instead of opposite corners).
3) Provide a redundant units indicator next to the coordinate readouts or change color for metric vs imperial to avoid crashes due to mistaken units.
My inner graphic designer wishes the negative symbol doesn't jump around when the X-axis rolls over from 0-9 to 10+ (but this is just an aesthetic quibble).
On the E-stop; Make sure you know what will happen when you re-engage the power after using the e-stop. Don't ask me how I know but if axis has been manually moved to fix the crash/hide the evidence, and the controller has been correcting for it, but the motor drive is off, things can move very abruptly and surprisingly when power comes back on.
Facinating to see the issues and how you have dealt with them James. Excellent.
Flippin' awesome, James. Some of the programming stuff and the references to the different electronic hardware went a bit over my head (and I'm an engineer!), but I was able to understand most of it thanks to your clear and detailed explanations. I think I have mentioned it before on another video, but what makes your channel stand out is the commentary. You don't repeat yourself (a rarity on TH-cam) and you have clearly thought out in advance how best to let an audience with very varied knowledge and experience know what you are doing and why. Oh, and the engineering is pretty decent too.🙂 Right then, I'm off to continue building my 3kW plywood thickness sander. I'm going to feel like a caveman unless I manage to put this video out of my head for a couple of hours. Keep 'em coming, mate. Geoff in France.
This is a remarkable accomplishment, James. I look forward to seeing it go from first steps to practical tool.
It might be as simple as using > instead of >= for your bounds check. Meaning of the position is exactly equal to the boundary, it can't run another step because it would go out of bounds, but it can't advance to the next state because it hasn't hit > boundary yet.
I can see how end-of-pass detection would turn into a very interesting discrete math and logic problem even without the complexity of an interrupt handler and their limitations. It seems there are multiple scales so even restricting yourself to integer math won't eliminate roundoff. I won't second-guess code and hardware I've never seen - this is a tedious, subtle, and challenging problem and I wish you the best in sorting it out.
At 4:30, you had moved the table but the DRO position didn’t seem to update. Is this because of the means by which the position is determined, or because of the ESTOP state software routine?
Yes, I am an engineer. 😂
Man, I really like the flow you have created. You put a lot of thought into this. Good work!
I wish you and your family a Happy New Year. Greetings from Germany.
You shouldn't go to z=0 at each pass start. By this you cause uneven wheel wear. Right technique is start next pass where previous ends. Conventional grinders do that by moving back and forth between z endstops and advacing y at each endstop.
How sensitive is the touch screen to errant touches? I'd be worried that a drop off water/coolant or some chips/swarf falling on the screen accidentally pressing buttons during automatic operation. You might also consider adding a "reset" button to clear errors/alarms instead of cycling the e-stop switch.
Wow! That’s a “real deal” motion system. I think I have to go find the discord to get caught up. _Really_ impressive, James.
The cycle should start with the wheel to the right of the part. This prevents the wheel riding over the part and shattering if the cut is too deep. With traditional hydraulic feed the part can be pulled under the wheel.
It is also usual to stop the feed with the wheel on the left of the part at the traverse end. This keeps hands away from the wheel when loading or unloading.
The cut can be added at each Y reverse to allow the X traverse to keep moving.
Neat, really really neat! 🤩
I see other people are mentioning dedicated e-stop relays and such, so I’m not gonna repeat that. However, I’m certain that one or two more videos down the line, the comments section will have nothing more to complain about 😅
Also, I love that you sprinkle in some metric measurements now and then. Both because it seems to annoy other viewers, but also because it helps my european/metric brain to think in terms of organic/grass fed fractional freedom units! 😂
Wow James great to see it work so well first up I look forward to see the total finished product. Here is a little something to think about why not cost it out including all labor and hardware and just see how expensive this upgrade cost. May be give your viewers a guessing competition.
As someone who works in industrial automation, I'd like to see an actual safety relay (pilz, guard master etc) on that estop.
The amount of thought you’ve put into the workflows is really impressive. It really shows through in the HMI you’ve developed. A truly Amazing result! 👌
Big props on the UI work James!
May i suggest connecting the coolant mister on/off to the controller as well
It is almost show time. Thanks for the video keep on keeping on.
I love this series of videos about this build! Congratulation James, you really do inspire me! While I was watching how you introduced the functions of the passes and the auto run, I was thinking it would be beneficial to sign on the GUI what cycle the machine is... the way how you mark the DRO display what will be moving with the red bars, that could be a matching solution for the passes... you can add a little red line mark beside the passes and the counter also signing what is left from the cycle...I've noticed that. It makes the GUI a bit more clear to understand what is going on, and it will create the system more fail proof and safe...
I left a comment last night from my tablet, but it disappeared, so I'm trying again this morning from my PC. TH-cam did give me an error, so maybe it was that. I really wish TH-cam would explain "why" a comment gets deleted, or ghosted...
Regarding the position that can't be reached...It's probably more complicated than just this, but I'm just sharing the idea. Snap your internal positional values to the known position by using a snapping formula:
Math.Round(value / snapDelta) * snapDelta
In your use case, make snapDelta the step resolution of the stepper motors. Now do all your conditional checks on the snapped positions rather than your real positions.
Good luck, and great job! This project is turning out awesome!
Fantastic! Has it occurred to you that with complete software control it can now do decorative grinding? Zig-zag across or a circular patterns. You could even grind concave or convex shapes, though touching off on an irregular height part would be, uh, challenging...
As others have said.... Awesome programming job. Everything just made sense.
Does it display events during the multi pass auto mode, ie. Spark Pass, Brush Pass?
Such a bang up job with the enclosure and your decision to go with this layout was spot on.
I was surprised you did not go with a joystick config to speed up setup positions. I was just curious.
Thanks so much for all you record and share. Have a happy holiday and prosperous New Year!
That interface is mind blowing good ❤
Amazing build. I want one! I’m picturing rev2 having a horizontal and vertical edge finder pair to locate the current state of the wheel for dressing, like the optical ruby edge finders for the mill.
Nice mate, I hope you put a lowpass filter error check on the windy wheel, they do fail, it happend to me once. Have the measured signal subtracted from a PT1 filtered signal. If the absolute subracted value is greater than some vaue then the windy wheel has lost track. Not even big dollar CNC machines have that feature.. This inch stuff is killing my brain.
always nice when projects come to the end
Looks like you hit homerun. Happy and Prosperous New Year 2025!
Why did you swap the Y and Z axes?
On machine tools, Z is always the tool, i.e. up/down on the turret, in your case the grindstone.
Someone else was mentioning in another comment that this actually is standard for grinders and horizontal mills. Specifically, the standard (and there's an actual ISO standard about this) for any machine tool is that Z is along the axis of rotation, and then X and Y are determined by right-hand rule from there. That also applies to lathes as well, with X and Z as the primary directions of motion.
Congrats! I'm sure that It is gratifying to see the fruit of your labors in action
Amazing result! Great job, James!
You might want to add hardware that will sense the actual load on the grinding wheel by measuring the actual power that's being expended. If the power increase exceeds some threshold, your initial cut might be too great. If the "power-trip" activates the safe thing is to stop the positioning servos and get the operator involved.
Congratulation on all the hard work!
your starting the pass from the left side of the table. Given the direction the wheel turns
If the first contact is too deep it will try pull the work into the stone.
If you start the pass from the right side it will try push the part out which is much safer
Don't ask me how I know that 😨
It’s clever, it’s well made, nice to look at and it makes sparks. Nice!
Very inspiring and fun to follow along. Thanks for sharing.
... good show James, as always ... all those hours, paying off ... well done mate ...
Awesome! Just and idea - you could add some laser indicator, so you wouldn’t have to lean over the machine to check the positions.
Hello,
This is the only right way to connect a E-stop. The hardware diconnect circuit is more important then the "status" input on the micro controller
With an interrupt driven system, I would pass a value into the interrupt routine. A tiny bit of code to quickly determine a value for *number-of-passes would be very simple. This provides a sanity check to make certain all passes have been completed and gives a break out of routine point. This also provides a much simpler method than relying on odd (sometimes) values derived from the motors. Especially if there is a value in a decimal place that you are not checking.
One other method is to use the derived number-of-passes to check then add 0.0001 to your routine break command to remove afore mentioned minor error in motor position calculations. Adding the 0.0001 will break it out of its loop, but only after number-of-passes has been completed.
Sort of like - If passes is greater than or equal to X ---- add 0.0001 to calculated position
Additional logic might need to be changed to - if current position is greater than or equal to calculated position - break out of routine
Keeping the bulk of this inside a routine also does not affect any global calculations or variables. Nothing really changes besides
One other thing that I've done for motion value checks is to multiply the number by the precision and convert to absolute value . You want 10 thousandths precision, then multiply the values by 10,000.
Int temp_pos = abs(position * 10000)
Int temp_calc_pos = Abs(read_value * 10000)
Run the check on the temp values instead or skip the variable assignation and do the conversion in the check. This gets you the precision that you want and deletes hanging decimal values. Plus, you can still add 1 whole number to the calculated value after number of passes completes and run the check on that.
Of course I am just guessing, because I have not seen your code and I might be out in left field here. I've delt with motion based calculations before and have seen this problem. I've also had to deal with drift (complete nightmare I must say) but anyhow.... Drift is not a problem you will likely have to adjust for, with this motion system. Just some thoughts, take it as you like.
Great job James, and well explained regarding the process of why and how.
@30:09 The DRO is reading -0.00108, but according the settings (2 rough passes at 0.00050 and 1 finish at 0.00010), the DRO should read -0.00110 on Y
Or am I wrong?
Correct.
FYI, the e-switch is great, but when you release it, add another button (real or virtual) to restart the machine status.
As to the bug…Michael Bolton: “I must've put a decimal point in the wrong place or something. ----, I always do that. I always mess up some mundane detail."
26:04 If you had a red and green laser on pointing down on the bed on the x/z axis, you wouldn’t need to look around the machine to see if it’s past the work piece to set the start and end points. Reducing the amount of travel (and thus time) that the bed moves.
You can surface grind non-ferrous materials by sticking it down with double-sided tape.
Looks great! Congrats on a project well done.
Suggestion for the touch off, let the wheel only rise after the touch off. Or don't allow the touch off until safe height is set and after touch off make it move to safe plane automatically.
Incredible work.
You may have answered this before, but why did you choose the Y axis for vertical travel instead of Z? As a long time CNC programmer it seems counterintuitive. I get that conventional practice is to have Z parallel to the spindle axis, but in milling the Z direction relates to depth of cut which is why it seems odd using the Y axis.
Someone else was mentioning in another comment that this is standard for grinders and horizontal mills -- and, specifically, having Z parallel to the rotating axis isn't just the conventional practice; there's an actual ISO standard about it.
But, yes, it feels odd to me, too! I would probably put some labels on the machine indicating which axis is which.
Do you think you might benefit from a mirror to more easily set Z start/stop positions?
I really wish that James was my neighbor! But having him as a TH-cam personality is not bad either.
I think the e-stop circuit should have a reset button.
I know the slim relay is not very reliable. The contact in the relay is not very substantial. If its wired NO then the e-stop circuit will not engage when the relay fails. If you decide to use this relay in the future get a dozen.
Outstanding job converting the grinder to cnc. The controller, the programing and the control cabinet look great.
Nice setup! Does the E-stop also kill power to the grinder?
Not at the moment. There is an estop on the grinder that kills everything, including the control.
Maybe you could add 2 laser lines to project the sides of the grinding wheel on your workpiece for setup.
@Clough42:James, great UI. Very well thought out within the physical size limits you set for yourself.
(2:03) I'm looking at the ClearCore controller, and remembering it had a DE-9 connector, and that you had... very strong opinions about their use (aka don't use em).
I'm wondering why you dislike these connectors and what issues you've had with them? I've never come across this before and wanting to learn.
Thanks always for the videos, they are very entertaining & educational
Congratulations. Another awesome project.
Happy Holidays!
Cool project, been following it from the beginning. Your display is excellent and the logic you built into this is really well thought out (obviously a developer!)! I love how the coordinate system works that you can re-reference the zero point without moving the start/end/safe values. Some thoughts?
I do wonder about your Y axis control, and whether you should be buffering in wheel input since the travel speed is so slow compared to how fast you can spin that wheel. I realize you can hit the Estop, but I think you can probably prevent this in the first place. Did you consider that?
I'm wondering if the bug where it doesn't detect the end is if the travel from start/end is under some certain amount that you have set, or some sort of rounding issue.
At 23:30, I think it would be helpful to have an on-screen indicator of which pass it's running. Since you have live controls for rough/finish/spark, what happens if it's in a finish pass, and then you add another rough pass, does it go back to the beginning? Another software enhancement would to have system presets for rough/finish/spark, (maybe by material type?), or perhaps even user-saved values.
Sorry, just thinking out loud as a fellow developer! Certainly not taking away anything from this amazing work.
Maybe an indicator on the feed buttons to indicate if a run has been performed since feed has been pushed, or some other uix to prevent accidentaly pressing then multiple times?
Very cool project! You are a terrific communicator, James, thanks for your efforts, and thanks for your patrons for funding it.