Makermade M2 - CNCjs calibration issue

Troubleshooting MakerMade
21

Lol… I know… was trying to be funny.

22

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?

23

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.

24

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
25

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.

26

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…

27

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
28

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?

29

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?

30

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
31

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:

32

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

33

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.

34

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.

35

Interesting… grbl has the ability to set the x,y,z coordinates through G92 but nothing for setting chain lengths, obviously. I haven’t looked through it enough to know, but I think if you add the length chain gets extended as a setting, like maslow currently does, then you could modify this line to just use it. No need to do an inverse calculation, but will need to do the forward to calculate the x,y position and then update that.

I think the issue with eyeballing it is that the kinematics formulas depend upon knowing how long the chains are. The best way to know that is to “dole” them out. But perfect is the enemy of the good and I don’t know how much it really affects performance overall. How accurate can someone set a sprocket vertical might be equivalent to how accurate someone can center the sled. And as you said suggested, just because its centered on your 4x8 board, doesn’t mean it’s centered between the motors.

Personally, I think setting sprocket vertical and marking the top link (for future resetting of the chains) is the likely to produce the best results.

36

I’ve successfully flashed my M2 with new firmware.

I’ve added the following new GRBL settings:

    case 87: settings.chainSagCorrection = (float)value ; break;
    case 88: settings.leftChainTolerance = (float)value ; break;
    case 89: settings.rightChainTolerance = (float)value ; break;
    case 90: settings.rotationDiskRadius = (float)value ; break;

    case 91: settings.chainLength = (float)value ; break;

… and have introduced forwardKinematics() as an alternative to triangular(), as well as updated the triangularInverse() function. Wiring everything back up now to see how it goes… I’m expecting lag on the forward, but we’ll see.

edit theoretically, the DUE has a 84 Mhz clock (compared to 16 Mhz on Uno). That does give us a lot more headroom for computation…

2 Likes
37

I looked through the code and so far haven’t seen anywhere that the forward would be called all too often… maybe just on the reporting interval… and if the current position is the guess, then it should solve within a few iterations.

38

I tested out how much an error in setting the 0,0 would affect the accuracy of machine. All of this was just simulated with math, not actually tested on a machine. My assumption is that a user runs the calibration and gets perfect results, sets the 0,0 point, then at some time in the future things crash and the user has to reset the 0,0 point but does so with some error.

As we all know there are two types of error accuracy and precision. The accuracy is off nearly everywhere, but in some cases it is primarily a translation, so the precision isn’t too bad.

X axis off by 3mm
X Error
If in resetting the origin there is a 3mm (1/8 inch) error left or right, the resulting X coordinates shift about 3mm, but they are very consistent, the highest X error is 3.84mm at the bottom corners and the lowest X error is 2.56mm at top dead center. So about a 1.3mm hit to precision (completely reasonable).

Y Error
Most of the error in precision shows up in the Y axis. The error is worst at one bottom -1.799mm and the opposite top corner 1.789mm. So about 3.4mm across a large area. (not ideal, but not awful)

Y axis off by 3mm
X Error
If in resetting the origin there is a 3mm (1/8 inch) error up or down, the highest X error is in a top corner at 1.256mm and the lowest X error is -1.25mm the other top corner. So about a 2.5mm hit to precision (again not bad).

Y Error
The error is highest at top dead center 5.00mm and lowest in the bottom corners at 1.914mm. So about 3.1mm total. (again not bad.)

So What did I Learn
I dunno, it seems a 1/8 inch error in lining up with the last home position is probably quite high depending on how one keeps track of the home position. I bet many users could do better than this. I think this might be an acceptable solution, if one can accurately mark the origin after the first calibration.

Some thoughts for keeping track of the home position:

  • Drill a deep hole at the center
    • Cons:
      • risk of losing the hole on a deep cut
      • unable to improve the home position through future calibration).
    • Pros
      • Pretty easy to hit the mark again in the future
  • Mark the center with ink
    • Cons
      • Probably less accurate than a hole
      • Not sure how a user gets a marker in there with the sled in place
      • Could still easily get lost
    • Pros
      • Can easily remove the mark and reccalibrate
  • Use a vbit for greater accuracy
    • Cons
      • Pretty much all of the above depending on method
      • Another thing to buy
    • Pros
      • probably the most accurate given the fine needle like point
  • Mark the chains
    • Cons
      • No way to individually rotate the motors in grbl
    • Pros
      • Tried and true
      • easy to remove and repeat

Any other ideas I am missing?

Next Steps
What does an error setting the initial origin do to the holey calibration? I believe an error in Y falls out completely as part of the motorOffsetY. Any error in X is just a case of the leftChain and the rightChain being different lengths. So in the initial setting of home, we could ask users to measure from the ring or the linkage to some point on both motors (this would be a substitute for counting links, which sounds tedious). Users would be told to ensure that both lengths are the same and that Y is approximately the middle of their workspace.

Again, I would estimate the resulting accuracy of a user’s measurement of this to be about 1/8 of an inch, maybe 1/4 of an inch given the length.

I suspect that an error like this shows up in chainTolerance. This is probably not good, as chainTolerance is an error that is proportional to the length of the chain, where an error in setting the origin is just a fixed offset. I don’t know if it is possible to add yet another variable to the least_squares calculation, something like chainLengthDifference that describes an imbalance in the chain length at 0,0. If this works, it would correct the user error, but may degrade the calculation of the other variables.

39

Sorry you lost me here. What is your thought?

My understanding is that the chain lengths are set by setting the origin or home. When home is set an inverse calculation is done to determine the proper chain lengths for 0,0 and then those lengths are saved to the eeprom.

40

In maslowdue, there was a code segment that set the position to 0,0, calls triangularinverse to calculate chain lengths, and saves those lengths in the PID structure. I assume that’s what’s ultimately called to zero the machine. What I was saying is that if you stored the “extend chain length” (i.e., the distance the chain is extended during calibration to connect the sled) as a settings variable then you run that code segment, make it so it justs set the chain lengths to that value and then runs fowardTriangular to calculate the x,y position and saves them.