Makermade M2 - CNCjs calibration issue

For MaslowDue, from what I can tell, it just does simple trig from the center of the motor sprocket to the target coordinate., with the target coordinates getting altered by the scale value. So if you have x-scale of 1.01 and tell it to go to x=100 mm, it’ll calculate chain length based upon x=101 mm. It doesn’t seem to consider that the chain originates from a tooth of a sprocket, and not the center, and that the chain wraps around the sprocket for a portion of its length. It also doesn’t consider catenary effects and chain tolerance. It appears the intent is for it all to be handled by x-scale/y-scale values.

I don’t know if makermade has made any adjustments to it though that’s not reflected in their github repo.

3 Likes

Oh, I see from the video that they don’t really use the x-scale and y-scale and modify the steps/mm instead (as @zaneclaes pointed out). The effect is the same.

Is the ‘official’ M2 firmware the MaslowDue from their github page or is there something else? If it is, for someone inclined, it wouldn’t be a huge challenge to incorporate the holey calibration kinematics if the performance of the current methodology doesn’t meet their desired level. You could also, fairly easily, create a standalone program to do the calibration calculations.

1 Like

could you make a cnc.js plugin for calibration?

Me, probably not. Someone, probably so.

Sorry unclear question. Of course, your work speaks for itself, so while ‘you’ could, I was not meaning to ask you if you would.

Should have been: Would it be possible and reasonable to make a plug-in for that system?

I believe they have a pendant script option that could be tied into, so it may not even require a communication library to talk directly to the due. Just go through the cncjs.

Success! … kind of. Holes are good, but not low corner cuts (due to chain sag). It’s better than most machines, I suspect, but not anywhere as good as I had my Classic.

I’ve been doing calibration for the past ~6h nonstop. I had to invent a calibration approach in order to achieve the same accuracy I had with the classic. My “success criteria” is being able to cut a 1" border off a 4x8 with 1/16in tolerance. I was able to place holes more or less accurately, but they drifted by about 1/4" in the low corners.

I’m planning to make a calibration widget out of this, as I’ve already been investigating CNCjs in anticipation.

@madgrizzle I downloaded their Makerverse software and discovered than in the latest version, they are indeed changing $84 and $85 (not $100 and $101).

Also, the hint about the trig was great. I ended up measuring from the last gear on the bottom of the sprocket before the chain becomes straight (for the motor height & motor width measurements). AFAICT, this creates the appropriate triangular shape.

The hard part is dialing in the motor offset “just right.” If it is wrong, it causes bowing in the Y-axis, so the middle part is higher/lower than the sides. If the center bows upwards, the motor height is too large (and vice versa). I basically used the same 6 holes cut by the Holey calibration, but instead placed them 1" from the border of the stock (as I explained here, with the idea of “overclocking”). Simply diving the expected vs. measured distances between the holes was enough to zero in on the correct scale factors. My early mistake was being off by ~5mm in the motor height and trying to dial in scale first.

My sled is at 26 lbs… I am getting a tiny bit of rounding (chain sag) in the lowest 1" corners when cutting (and therefore dragging) right on the corner, but nothing too bad (1/4" rounding at worst).

Time to try using the new 1/8" bit to cut something…

1 Like

Lol… I know… was trying to be funny.

I haven’t looked carefully at the kinematics functions in the MaslowDue firmware. First we would need to get all of the various settings included (chainsag, weight). But if those are in the firmware and settable using the $ settings, then you don’t really need a plugin to cncjs.

You would just need to:

  1. setup your machine
  2. load the holey.nc cut file and cut it
  3. do the measurements like normal
  4. run the calculations on a python script (I think google collab might work for this, it is like an online ipython notebook)
  5. when you get the results from the python script, you could then just update the $ settings.

One thing that I think still needs to be addressed on the MaslowDue, is setting the 0,0 point. This seems critical, the maslow firmware doles out the chains so it knows exactly where things are. The MaslowDue system relies on you eyeballing the center of the sheet. This might work okay, if you never lose the home position, but if it gets lost, your accuracy may suffer until you do another calibration.

I would like to have a better understanding of how much error is introduced by say miss-setting the home position by 1/6 or even 1/8 of an inch.

Maybe users could plunge a hole on the spillboard right in the center so they could go back to it if anything was ever lost?

Sled weight correction is (AFAICT) the only thing really missing from my execution of Holey Calibration with the M2, documented above. I believe we could achieve weight correction through the K values, but I don’t know much about that. I’m guessing my 26 lbs sled is close enough to whatever they’re shipping with the M2 full kit that my calibration seems to hold up.

So looking at MaslowDue - System.cpp it looks like it assumes straight chains. Unless I am missing something, this is lacking a few improvements done in the Maslow Firmware. 1. It ignores the chain around the sprocket which I think moves depending on the angle of the chain and 2. It ignores the chain sag or catenary curve that it forms.

MaslowDue has settings for:

  • ChainSag - this is an old method anyways. Even it isn’t used in the code.
  • ChainTolerance - This isn’t used in the code

As you point out, it would also at minimum need a setting for sledWeight and a chainElongation factor. Plus whatever else I am missing.

It is all doable, it just means the kinematics model has to be updated.

I am looking at the MaslowDue firmware and the idea is nice. I just wish they had actually forked grbl and not just copied the code. That kinda makes importing future grbl fixes into the code a bit harder.

Sorry, I have hijacked this thread enough.

1 Like

It is a calibration topic, so seems apropos. It doesn’t look hard at all to add in different kinematics.

Good to see you back.

I’m actually very interested in understanding this math better. And if it can help me build a perfect calibration widget for CNCjs + Maslow, all the better.

Examining the chain on the left sprocket, it seems the chain link at ~8 o’clock serves as a pivot location. This pivot does not actually change more than a fraction of a mm, regardless of the angle of the chain. I think if you start the math from that point, the sprocket can be ignored, no?

This may be a weakness in M2 firmware execution right now (?). It explains the slight sag I’m getting in the far low corners, still, despite mostly high accuracy. The more I look at these extreme corners, the more I’m certain it’s not as good as I had the Maslow Classic working… wondering if I can somehow compensate…

We worked on this a while back… it’s dated, but does talk about some of your questions…

I think there’s a bit of a difference between the sprocket contact point between the lower-left corner and the upper-right corner (and same for lower-right and upper-left). Every little bit adds up when you are trying to improve accuracy.

With the model of the M2, I think the only way to overcome this is to modify the gcode to compensate for the errors, and I don’t know of any CAM software that will do this for you.

1 Like

I see. It doesn’t seem like more than a few mm, but yeah, that makes sense.

Yeah, it seems like this needs to be corrected at the firmware level. If I could get my hands on the M2 Arduino source code I’d be happy to give it a shot. Would the correct way to do this be to introduce some (3?) new GRBL variables? Are there variables that already exist in the GRBL definition we should use for (1) the sprocket size + (2) chain sag left + (3) chain sag right?

Would the correct way to do this be to introduce some (3?) new GRBL variables? Are there variables that already exist in the GRBL definition we should use for (1) the sprocket size + (2) chain sag left + (3) chain sag right?

Side question, but related… have you noticed that chain sag varies depending on which direction the sled is moving? Is the idea to have the sled move with essentially no resistance so it is perfectly accurate? I have observed there is typically more slack moving into the corner laterally compared with vertically. The assumption in the model is that the chain is a rod of some effective length, but that length changes with the cut. How do we fix that?

For settings, specifically look here…

Lines 79-95 seem to initialize the variables and lines 369 to 393 are where the variables are updated from the $ commands.

The kinematics are contained within:

you need to update both triangular() and triangularInverse(). The triangularInverse() is fairly easy, but the triangular() will be the biggest challenge. triangular() converts chain lengths to target values (i.e., what coordinates is the sled at if the chain lengths are such and such). Because the kinematics of MaslowDue is simple enough, there’s a formula that can be used to determine these values. However, Maslow’s kinematics is a bit complex and no PhD mathematician has created a function that can ‘inverse’ the inverse kinematics. Therefore, maslow firmware solves this through an iterative process in Kinematics::forward() where it takes a guess as to where it is, runs triangularInverse to compute the chain lengths based upon the guess, calculates the difference (error) between the result and the actual chain length, then adjusts the guess coordinates based upon that error and repeats until the chain length difference is small enough to be acceptable.

See here.

The forward function in maslow requires a “guess” to be sent to it, whereas the triangular function of MaslowDue does not (because it just solves for position because the math is so simple). So when you bring the code from forward() over to triangular(), you’ll need to create your own guess. Maslow uses the current sled position as the guess (logical choice) so if you use that, you should be fine. I think the position is contained within:

gc_state.position[X_AXIS]
gc_state.position[Y_AXIS]
gc_state.position[Z_AXIS]

but not 100% sure. It’s really this particular function that I worry about and whether or not the MaslowDue calls triangular too many times and whether incorporating Maslow’s approach takes too much time to complete. This may be why it wasn’t used by @ldocull when he wrote it MaslowDue… but I don’t know.

2 Likes

I’m pretty sure the MakerMade github repo is the latest version they shipped with, or close enough. Because I had my sled run off the side of the stock while shuttling. And the github repo shows that verifyValidTarget() is just commented out, leaving no guardrails around the machine.

Working on a firmware update now. The only question is, do I risk flashing the PCB in case they did make some mods I don’t know about :stuck_out_tongue:

email them to verify. I’m pretty sure you can backup the firmware using avrdude… don’t know how, but it can be done.

I think madgrizzle has it all covered. I have been looking at the MaslowDue code and it wouldn’t be hard to update the kinematics because you generally lift the work from the Maslow Firmware.

Whether or not the extra processing causes issues, I don’t know.

The other thing that slightly bothers me about the MaslowDue setup, is the initial setup. On a standard Maslow, we dole out the chains and know exactly the length of each chain from the start.

The MaslowDue takes an interesting tack and has the user move the sled to 0,0 by eyeballing it and then setting the chain lengths equal to what they should be at 0,0. The HoleyCalibration assumes the chain lengths reported are accurate. I want to explore what happens when they are not perfect because someone’s eyeball is defective.

Worst case scenario, we build in a routine to do the setup just like the Maslow and dole out the chain lengths. But ideally, if the Due setup can be made to be close enough, it is certainly a much more user friendly way to go. I don’t know if the HoleyCalibration can be modified to distill out the accurate chain lengths as well, that may be two too many variables to pull out.

I have been hoping and asking for this a long time. There has been releases where it was spot on and then it would be up or down (chain sag calc I guess). I can measure the centre of the sheet with a max error of 1mm (more like 0,5mm measuring from 4 sides). I would have loved to see the math take it from there, instead it insisted to know better then me where the centre of the sheet is. Assuming you can centre your sheet, I do not think of this as a bad approach.