I second 3dsteve’s sentiment!
Thanks Rob for the great support and involvement in the community.
I second 3dsteve’s sentiment!
Thanks Rob for the great support and involvement in the community.
Thanks for your vote of support. It would not be possible for us to react to problems without users posting clear bug reports and feature requests. (You’d be shocked at how many emails that say only “It doesn’t work” over the 10 years of MeshCAM).
I’m working through the Fusion 360/HSMWorks changes now. G28 and G53 are in the code. I/J do not need to be defined on each line. I’m looking into G18 and 19 right now. If all goes well we’ll have a release today or tomorrow.
You should probably uncheck the “Use G28” too since it just adds more delay but it will not error out anymore.
Let me know what you think.
I’m stoked to try it, will have to wait until tomorrow though, don’t want to wake the wife
I’ve got a file ready to try, so I’m excited to see some helix tool-paths run!
I ran a helical boring op as a test and it worked well. Good luck.
I have to say Rob, you’ve made improvements quite quickly and the milling from HSMxpress was a success! Here’s the result of a 2d pocketing pass path. I’m posting this also in the green-foam/pink-foam thread to show the two different results. I would add that this isn’t with a proper end-mill, but rather a shaped-tooth 1/16" tile-grout cutting carbide tool, so I’m betting I could get better results once the rest of my smaller-diameter tooling comes in
That’s great news- thanks for the update. Let me know if anything strange happens as you continue testing.
tying the beta for the first time today. so far, so good. Miss the 10mm setting but love the fast and slow and lack of error messages.
Rob, I really appreciate the regular software updates and communications, I hope business is going well for you guys.
Still getting machine parameters error in latest beta …
Your machine got the parameters deleted somehow (based on the log above). If you can tell us your serial number, we’ll look them up and then give you the commands to reload them.
serial number is 00061
Carbide motion wish list item:
Add a feature where you can save a waypoint while machining and then allow the user to start from any waypoint on a future run. this would come in handy when all of the silly things that screw up a run happen and you can save the part but you have to start over but you have not lost your zero reference. . Rather than start over, i would like to start from my last known good spot in the g code… For example, when doing aluminum and the bit stalls or when the nomad loses contact and just stops.
I like this in concept, but see a few problems with execution:
You must watch your file like a hawk as your Nomad runs, and have trigger-reflexes to stop the file as soon as the problem stall or contact-break or whatever occurs. I know I’m just not that vigilant, and my configuration doesn’t really facilitate that kind of reflex response; and as far as the distance/angle between my control PC and Nomad for viewing + mouse-clicking things like that, it just isn’t ideal.
Remember, the controller may be going through hundreds of lines of g-code every few seconds for a complicated contouring pass, so even if you do manage to catch your machine mid-error, the likelihood is that you’ll be off by a few lines at minimum, and more likely a lot of lines. You’d need some way to re-wind a bit, AND you’d need it to add the appropriate pre-operation moves to check the tool and lead-in before it picks up cutting where you stopped it (say you stopped it because your bit broke, for example).
The Nomad has no idea of knowing if it’s “good” or not, so there’s no feedback to Carbide Motion for what is the “last known good spot in the g-code”. Unless you have CutViewer or another CAM package with simulation you can “rewind” your operation to find where your good spot to start the cut in is, such as the HSMworks/HSMxpress integrated CAM in SolidWorks or the integrated CAM in Fusion360, you’re shooting in the dark on where to pick up when looking at the g-code itself, without a line-number reference.
Therefore I’d offer this adjustment to the feature request in the interest of clarity/specificity in terms of achievable functionality, if I may:
Would it be possible to have Carbide Motion output the line a program stops on, either due to an E-stop, a fault, or a “Pause”? That would help you get in the ball-park when working with the program at the very least. Then advanced users could go in and edit g-code to remove preceding operation lines up to ~50-100 lines before that point, from after the tool-check and initial configuration moves are made.
Would it be possible to have Carbide Motion have a “start at line X” option, which would still read the file start-up routines, tool details, etc. and insert a G0 move to the correct pre-cutting XY position, do an appropriate plunge to the start point on Z, and ramp-up the feed-rate into the material from that line? This would allow for the resume functionality you’re looking for, and would remove the requirement for users to adjust the g-code at all. It would be very helpful if you were also able to look at where you stopped (from request part 1 earlier) and have it go back either an arbitrary specified number of lines, or perhaps enter a period of time to rewind, which it could then use to approximate how many lines to rewind based on the feed-rate from that line and any prior operations encompassed in that period of time. That would be a very powerful “resume” feature.
Since the motors on the X/Y/Z axis are all steppers, they don’t really know if they fail to make a step. However, since the spindle is on a closed-loop control circuit it may be possible to watch it’s amperage/voltage draw over time to look for any extreme changes which might indicate the tool stalling or breaking. I don’t know what GRBL-driven software/hardware combos like this can do, but if it’d be possible to monitor the applied load on non-rapid G0 moves by monitoring the spindle for spikes or sustains in a load condition that might be really useful data, as that would allow you to know exactly when that kind of thing went wrong. That kind of data could be used in part to inform the data coming back from part 1/2 of the suggestions here. It could perhaps just log the events and continue until it actually receives an E-stop or pause in Carbide Motion, and then provide the log data of those spikes so the user knows the last preceding line options that they might want to back up to.
I hope those are helpful thoughts on the topic!
I was a bit brief in my request so I suspect we are on the same page, more or less. what i was trying to describe was a button that I could click in CM to save way points along the way. I get that i will not catch the mistake in real time but If i am paying attention in my lazy style, I may click the save this spot button when I am happy with the progress that has been made after 30 minutes or so and again after a hour out of a 1.5 to 2 hour job. The idea being I could start again from there rather than start over. I think this deals with your issues with my original description.
This waypoint feature would not have to nab that exact line of code but rather find the appropriate spot within recent history that would make a good stop/start point.
Adding to that idea. It would be nice as you say to know where in the process CM is bot in terms of process and in terms of line of gcode. I know this is a tall order on the process side but it might be possible to generate some sort of text string in the gcode on the meshcam side that CM could display as a means of giving status. What line of g code would be good as well.
While paused, it would be great to be able to check the zero location as well, then go back to where you paused. This would be extra helpful to check to see if the nomad is only slightly confused or completely lost before resuming operation after a fault.
The process you describe is a kind of checkpointing for hardware. Unless it’s a loss of communication between CM and the GRBL controller,if something goes wrong, the part will probably be damaged.
It’s probably possible to display the current gcode line, so if the communication stops you know where you are in the file. It may be possible to restart from this line assuming there is no dependency, skipping the portion that is already done.
More often than not (thus far) when something goes wrong it is one of the following: loss of connection between the pc and the nomad (thus the part is fine) or occasionally a stalled bit ( the part may or may not be fine). I have been lucky and the part was not damaged in all but 1 case. I have been able to recover but had to start the run from the start. So a more robust connection between pc and the nomad would be welcome ( thus solving this issue by eliminating the root cause). When it is a stalled bit ( typically in aluminum and when making a hole) i would really like the ability to recover without having to start over. It seems like there is a > 0% chance of every run failing for some reason and the longer the run the higher the chance of an issue. a waypoint feature would make the odds of completing a long run considerably higher.
Mark, something you may want to consider is putting some cutting fluid on the material when you’re trying to “drill” like that, and also slowing your plunge-rate to prevent overloading the bit. If you’re experiencing this as specific drilling operations as opposed to on the lead-in plunges, then you may want to run the drilling separately to allow you to keep lead-in plunges at a reasonable speed while slowing the drilling plunges down.
When you say the bit stalls, does the spindle stall out (the whole thing stops) or does the spindle keep spinning but the bit itself is not turning?
I have been using cutting fluid. The binding is of the entire spindle. typically when the bit reaches the far side of the part and breaks through. I am not so much drilling as machining a large round opening (5/8ths inch ) in a thick block of aluminum. Plunge is slow and step is small. As the bit breaks through the far side, something grabs and it stalls. Thus, at ~90% or more of the way done, the spindle has stopped but the nomad has moved on for the few seconds before I can pause the code. I can typically finish with the part intact once I clean out what ever snagged the bit. Unfortunately, I have to restart from the beginning.
some examples of the sort of work where this happens is over in the gallery.
I’m still hoping for some way to address bit fouling during a run.