# Holey Triangular Calibration

Is absolute default? A G91 for relative at the start would do, right?

1 Like

G21 G91 at the start would put you in metric relative mode.

1 Like

So I don’t need to break the chain.

Correct

Connect 2 together, make sure the chain is fairly tight on top

right, the first action takes up the slack (1/4 power for 5 seconds), if that
isn’t enough, just repeat this line until it does pull tight

(edit: set at 12?) of the sprockets

it does not matter.

before start and somehow take care that
the slack I have does not interfere?

correct, with stock chains, it will sag about 2 feet down in the center if I’ve
done the math right.

It my help the chain to feed if you can tilt the machine forward so that the
sprockets and chain are vertical.

David Lang

Thanks, yes, add G91 up at the beginning.

The intent is to move the left motor to give you a little slack, then move both
motors. I need to change the R-100 to R-95 so that there’s a little slack to
take up (and we don’t get in trouble if the chain for this segment is a little
short)

I’ll update the post

David Lang

I realized I ended up migrating to a different forum topic for several posts. I should do a better job keeping this stuff organized.

Here is another status update.

• I put the catenary (chain-sag) equations into GC kinematics.py. I spent some time validating it, and I believe everything to be correct. I created a script to plot how much the chain-sag displaces the sled across the work surface. Below is the plot. I still need to post the machine parameters that produced this result.
• I put the elasticity equations into GC kinematics.py. Everything appears correct here, as well. However, I haven’t validated it as substantially.

Here are some future activities:

• I would like to create the same displacement surface-plot for the elasticity effect. We may find this is as significant as chain-sag, maybe more.
• I am still thinking it makes sense to change the hole-pattern. I have thought about it for a while, and am considering a six-hole pattern. My thought is: there should be a point in the top-center of the work-surface, since this point is most sensitive to calibration changes.
• It still makes sense to simulate all the updates, before trying anything on hardware.
• We need to get these calculations into a firmware branch. It has been a while since I have written code in any C language, so doing the work will require some learning on my part.
• Physical calibration and test.
• Some have requested these simulations be put into the GC simulator: chain-sag displacement, chain-elasticity displacement, and calibration evaluation.

## Question

I would like to ask the community for feedback regarding the ability to put the Catenary and Chain Elasticity equations into the firmware. Does it seem reasonable for the arduino to computationally support the additional calculations? Does anyone know how much additional bandwidth, in terms of processing power, is left on the Arduino, to support these additional operations?

## Update

Here is the result of Chain Elasticity displacement vs. position on worksurface, and total displacement vs. position on worksurface.

Machine Parameters:

• Distance Between Motors=3048
• motorOffsetY=711
• sledWeight=20

## Developments

I would like to update the hole locations for the calibration to be a six-hole arrangement. Below is a figure, where “Pt #” are the point numbers, and “M #” are the measurement numbers. This is mostly for my own organization, but I am open to feedback. The primary reason for the update is I feel it is important to have a hole at the top-center of the work piece. The top-center of the work piece is most sensitive, in terms of vertical position, to changes in calibration.

I can’t quantify it, but I don’t think your calculations are overly taxing. Best way to know for certain is put them in and use them.

1 Like

No guarantees since I haven’t compiled it, but you (hopefully) should be able to replace the triangularInverse function in kinematics.cpp with this one and it’ll compile and upload fine.

It uses the chainSagCorrection value as the sledWeight. Give it a shot and let me know if you get any errors on compilation.

2 Likes

That is awesome! Thanks a bunch!

## Update

• The modified hole pattern for Holey Calibration has been implemented, and I was able to run a test as a simulation. I was able to do a simulated error=>calibration to see that the calibration corrects the machine parameters. The process is like: first, set parameters in the kinematics model and calculate chain-lengths corresponding to the points in the calibration; second, modify the parameters and calculate positions on the workpiece from the original chain-lengths; third, calculate the distances between the points as a simulated measurement; fourth, run the calibration to return to the original machine parameters.
• The firmware in the local github repository reflect the changes made to the GC kinematics.py function. These changes are rough, and have not been validated.

## Questions

• In order to run a physical test, I will need to be able to push parameters from the workstation, GC, to the firmware. I am thinking the easiest way to do this is to integrate back into GC, and leverage the existing communication mechanisms. Could someone provide a very high-level description of where to start; explain how parameters are moved from GC, into the firmware? This would save me some digging.
• Additionally, GC is based upon Kivy. I have read a little about how it is structured, but it is still beyond my grasp. Any information or guidance that anyone could provide to help with integrating into Kivy, and the GC GUI environment, would be great.

What specific parameters are you trying to send to the controller?

Good question. We will need to be able to pass all the calibrated parameters. Right now, they are rightChainTolerance, leftChainTolerance, rotationDiskRadius, motorOffsetY, and D.

Not sure what D is but these are already communicated between the firmware and the GC settings:

\$41 is rightChainTolerance
\$40 is leftChainTolerance
\$3 is motorOffsetY

1 Like

I’m not sure what D is, but to test out the process, why don’t you transfer them manually from the calibration routine into GC…it’ll sync from there.

2 Likes

D is distance between motors in kinematics.py.

One thing I would like to do is validate the firmware implementation of triangularInverse against the GC implementation. I have a few questions. I apologize if some of this information is already available on the wiki, or somewhere else. I have looked, but I thought it would be faster to just ask. Here are a few questions:

• I have read there is a “Simulation Mode” for the Arduino. Could someone provide some guidance about how to set that up?
• I would like to command a few (x,y) positions on the workpiece, and then request the calculated chain-lengths from the firmware, so that I can confirm the calculated chain-lengths in the firmware are equivalent to the calculated chain-lengths in GC. Could someone help by providing some information on how to do that?

Thanks

I am running a spare arduino with no motor shield in my home office.

~ ln 28 // #define FAKE_SERVO // Uncomment this line to cause the Firmware to mimic

Notice that the arduino IDE will save without asking, so take care in the productive environment.

2 Likes

I don’t know what groundcontrol will report to the screen, but issuing a “B10 L” and “B10 R” will request a measurement read from the controller. I don’t know if the resulting measurement prints to the screen and/or terminal window, but I’m sure it shows up in the log (among all the other messages). Assign “B10 L” to Macro 1 and give it a shot.

No function has requested a measurement is the response I had with
-> DL's loop chains and run a series of motor position reporting

Edit: the commands in a gcode (.nc)

Does it show up in the log?