I’m brand new to Maslow. Is CNCjs something I should consider as an alternative to groundcontrol or webcontrol? I’m almost finished building the mechanical portion, but software is not my strong suit. I’m guessing from the beta and 560 posts that CNCjs is not quite problem free. I just don’t want to put all my effort into learning webcontrol only find it outdated in a few months time
It sounds like you have a Mega (not Due), since the Due doesn’t work with WC/GC.
I suppose that depends on your goals. If your goal is to get up and cutting with reliable software as fast as possible, I’d opt for WebControl (definitely not GroundControl). If your goal is an easier learning curve, I would argue that the calibration & usability of Makerverse (not CNCjs!!) is quickly becoming quite high. Another few days and I’d say I would feel more comfortable recommending it to newbies than WebControl.
But, then, I’m biased.
@Orob I noticed your gcode file used G00 instead of G0. Build #219 should be up in about 30 minutes, which will handle G00 the same as G0.
I didn’t notice that was a problem. The cut worked, it was just offset in the view window from the actual cut.
It’s related to the wpos offset problem, here. I’m basically creating a “virtual” wpos behind the scenes, since the Mega doesn’t have a real in-memory wpos (like the Due and other Grbl does). When the G00 command is issued, this virtual layer needs to know to translate work coordinates into machine coordinates. Doing this improperly (i.e., wrong units) can cause the cut to occur in the wrong location. Complicating the problem is the fact that the Mega does not report its values in the same way as Grbl machines (most Grbl always reports the current position in mm).
I played around with #214 over the weekend. A couple of observations and a couple of questions.
- I continued to run into the issue of the workspace height changing to 16 mm. It seems to happen when any setting is modified and updated.
- On the chain calibration routine, when moving the chains up and down with the Y control, the increment was fixed at .1mm and the dimension dropdown was not selectable.
- My initial calibration was well outside of what @zaneclaes has said was nominal ~25 mm. After multiple runs, I can get the New Accuracy number down in to ~20.2 mm.
- The New Accuracy field is great.
Questions:
- How does the optimization routine attempt to isolate the error? It seems that the incremental improvement decreased with every run.
- (Impossible question to answer) How many optimization runs would you expect to make to get the machine calibrated 5, 10, 20?
- The values that the optimization routine makes the largest change to are distance between motors and motor offset. After multiple runs, the value of those settings is wildly different than the actual measured values. Is this to be expected, or does this factor into the diminishing incremental improvement?
Very strange. I think I saw it happen to me yesterday too, but only on the Mega, and I missed what might have caused it. I’ll keep digging here.
Thanks, caught that one myself and fixed 
Hm, I’d like to see that value under 10mm at least personally. IME, if I start a new calibration over 20mm accuracy, and multiple runs haven’t converged the values much, then something else is wrong. Usually this is either:
- invalid initial measurements — I once entered a motor width more than 30mm off, it took like 10 calibration runs to get the accuracy below 10mm
- something wrong with the frame. I put together a 12’ metal beam and tried to calibrate this weekend, but didn’t notice sag in the beam from insufficient support on the ends. The chain sag values went all over the place, like up to
0.5(very big), and it was very… delicate.
It runs a brute-force optimization method against all possible values, within a range of proximate reasonable values. In other words, it tests the measurements against reality. What would have happened, hypothetically, if you had used a 1mm bigger or smaller value? What if we try some chain sag correction? And so on.
IME, first run might be ~20, but a good frame design should have it under that even before the first run. Second run should be in the 10s then, and third run into single digits. To get under 6mm, I generally need to use a 1/8" end-mill with precision calibration.
This sounds like the problem to me. How accurately were these measured? Do you have a millimeter tape measure? I’ve seen values change 5-10mm away from what I measured, but more than that seems abnormal.
I would hope it would only take 3 calibration iterations to get to less than 5 mm. the last time I ran it (saturday) was the third and it was 1.8 mm.
Agreed, as long as frame design is very good. As a novice woodworker myself, much of my failures to calibrate have been due to this. I’m also presently building on uneven dirt ground while the garage is torn up too 
edit not to say that Scott is a novice. Just my 2c in terms of what has caused this for me. However, I am finding more ways to improve calibration every day.
@Orob @scottfmosley I had some trouble with my new frame these last couple days, and ended up coding in some “detection” to the calibration, like if the stock is rotated. This helped me detect problems in my frame much faster.
Also added Z-axis calibration (more relevant to Due users):
And import/export for calibration:
… and a few other things.
4 Likes
That’s awesome. I just went to Home Depot to get some Doug Fir for my top beam. The 2x4 that was there was definitely starting to deflect. My guess is that the Doug Fir will be much more stable.
I’ll let you know how the calibration goes with the new set-up
1 Like
ok, I finally restarted makerverse and I’m seeing a couple things that are off.
- What happened to the sleep button? It was the only way I could stay sane when the system was on to keep the annoying hum off. when I was changing settings or trying to tune the pid for my crazy z axis.
- the reset and unlock buttons are in a good place.
- The 3d view is kind of hidden behind the reset chains button as is the other button / indicator in the red highlight.
Since behavior was inconsistent between Mega and Dur I hid it. But since it’s that useful I’ll bring it back!
Yay!
Ah, I think that happens when there’s no text on that line. I’ll get a fix for that.
Thinking it’s about time to push this out to more people. Curious to hear any thoughts on the readiness of the app. I’ve cut two projects in the last two days, both came out well. And I think at least a handful of people have calibrated and are cutting at this point. I just haven’t tested as much on the Mega personally, been focused on the Due.
I think the mega needs a code overhaul to be ported to makerverse and that will start with the path planner from the due. With the mega at 25% storage space and 25% ram usage as reported by flashing, I think I’ll try and see how it works out. There is a version of GRBL that runs on the mega, so maybe the thing to do would be to start with that and add in the kinematics like you did with the due rather than shoehorn the path planner into the existing firmware?
For features to add: Can you do the skip ahead in the gcode file feature or show what line it is on currently when cutting and if it fails, report the last run code line? Then if it crashes, we could delete between the header and that line and try again?
Thanks for your effort on this.
1 Like
Why? What’s the advantage to this? I’m highly skeptical it’d work at all, and the current approach works just fine with Makerverse. Why fix what’s not broken?
Hm? I did no such thing. I didn’t do anything with path planners at all, or even touch the firmware.
I very intentionally chose an approach which makes zero modifications to the mega firmware.
The advantage of the due over the mega is the path planning (acceleration). If the mega had it, it levels the field and the mega loses its herky jerky tendencies (100% power for movement in any direction - random sled not keeping up errors) so the up side is a higher top end feed rate because it gets there gradually. Looking at the due code,there are preprocesser command sets for the mega, which to me indicates it could be done. There would be 2 approaches to do it (due code modification or mega code modification). My comment not intended to suggest that you did either of them or to throw shade on any of your good work, just that if we are changing the look and feel, it might make sense to do the upgrade. If you don’t want it, no problem. I wasn’t looking to start a fight.
1 Like
Oh! I see. I thought you wanted to implement wpos at the firmware level. I didn’t mean to be rude, I just didn’t want you to waste your time doing that 
Acceleration stuff sounds very cool.
I was confused because the question I’m asking is: “does Makerverse meet the same usability bar as WebControl for Mega users?” Then focus on improvements, later, after the initial release In that context, your reply made me think you were saying this needed to be done for Makerverse to be ready. I don’t want to conflate “stuff we should do” vs. “stuff that would prevent someone from using Makerverse today.”
2 Likes
While for consistency sake it might be a nice (perhaps crazy) exercise to make the 2 firmware versions match setting for setting, that isn’t something I’m thinking will really matter at this point either, so I get your initial reaction.
Yeah… it’s a thought I had as well. It does tend to open up a can of worms, though. There are a lot of features that the Due has which the Mega does not (i.e., step inversion, soft limits, hard limits, etc.) At the same time, there are a lot of unique commands to the Mega. Plus, IIRC, the Mega can’t store all the EEPROM settings which the Due can. It seems like a challenging firmware rewrite to make them seem “identical” on the surface.
I love the idea, just pointing out the effort involved. So far, I’ve taken the approach of hiding the GRBL numbers all together (which IMHO makes it a better experience for newbies, who see Soft limits enabled? instead of $20=0). Once you zoom out, this actually makes sense for Makerverse. For example, TinyG and Marlin both have certain common settings like Grbl does, though they’re represented differently. So I’m trying to make it so that the Makerverse layer uses common names, like zAxisMax instead of $120 — a translation layer between the different controllers. Meaning that when you set the Z axis max, it will work on CNC and 3DP and whatever else.
Btw, did I mention that one of my Makerverse installs is driving my Prusa MK3S 3DP?
That said, I do still really like the Mega firmware improvements which would make the motion better.