These commands seem to all be in absolute mode rather than in relative mode
B09 L5 ( move the left motor a little bit to release tension )
B09 L95 R-100 ( move to the right about 4 inches )
will leave the left encoder at 95mm, the right one at 100mm instead of both at 100mm. Is that the intention?
The G91 gcode sets relative mode, G90 sets absolute mode.
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 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.
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.
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.
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.
Good question. We will need to be able to pass all the calibrated parameters. Right now, they are rightChainTolerance, leftChainTolerance, rotationDiskRadius, motorOffsetY, and D.
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?
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.