I have had my maslow up and running for a couple of months now, but have had the same accuracy issues as most have seen. Most cuts are within 1/16" of where they are supposed to be, so I haven’t fiddled with anything to try an improve beyond that. Yet.
I lightly deal with custom CNC in my daily job and am of the opinion that in order to improve the accuracy of the maslow system, it will be necessary to provide real-time position feedback from the sled. I would like to do this by adding two encoders to the existing system that will provide a true X-Y feedback. In looking at the specs of the Mega 2560, it seems like the board is tapped out in terms of available external interrupts which are needed for the system to keep track of the encoder pulses.
The Arduino Due, on the other hand seems to offer an external interrupt on every digital IO pin and has the same layout as the Mega 2560. I am curious if I can swap in the Arduino Due and get what I am looking for.
I have already seen that one challenge I might face is that the Due will only take a 3.3v max signal on any of the digital inputs. Does anyone know what voltage signal the current motor encoders pass to the DI’s? Is is the full 5V signal from the USB?
note that if you can get accurate position measurement of where the sled is,
there is no need for the motor encoders, just use the actual position instead
I believe that there is also a lack of eeprom on the due
Thanks. I was hoping to keep the original encoders intact so i could keep track of the lag between the feedback position and the commanded position. I had considered simply replacing as you suggest, but I haven’t worked through the code enough to know what long term ramifications there might be.
The lack of the eeprom is certainly a problem. Do you know what other folks have considered for a long term solution to include more encoders?
The encoders would work with the 3V3 power that the Due provides, however on the present PowerControl boards (all versions) the encoders get their power from the 5V supply of whatever Arduino board they’re plugged into.
The lack of EEPROM is a real problem, though. Some versions of the PowerControl board use some of the SPI pins for board ID, so an SD card would need special routines with those. I fear that the SD libraries wouldn’t coexist well with the real-time needs of the encoder routines.
The position and velocity are handled by PID controller loops for each motor, so I think that only one set of encoders would be needed or useful.
I’ve started experimenting with these absolute encoders. They have plenty of resolution, and communicate 14 bit turn count plus 14 bit absolute rotation over RS485 at 2Mb. The present versions of PowerControl board leave TX1/RX1 and TX2/RX2 free, and those have hardware UARTs that work at that rate. I really haven’t a clue how to rig them to sense the sled position, but if they could be set up to measure using something that doesn’t have as much weight/sag/stretch/wear as the chains I think they could improve the accuracy significantly, replacing the motor-mounted encoders which could be ignored.
I think I saw that in the post regarding the use of string pots to track the actual position of the tool. I liked the approach but wanted to provide a Cartesian response because that would provide the most accurate long cuts across the work surface. I will try to make a sketch of my plans and upload for your consideration, but it basically involves the use of a vertical GT3 (or similar) timing belt that runs around an upper encoder. The encoder is locked to the sled position via a fairly simple linkage so that it follows, but maintains a constant height above the part. A side benefit of this approach is that it will keep the sled from rotating. Again, I will upload more details.
I was planning to use an incremental encoder that gives a response of 2000 counts per rev. With a 60mm circumference. This should give a resolution of about 0.0012-in. I like the idea of the absolute encoders, but I couldn’t find any in my price range. I ordered two knock-off Omron E6B2-CWZ1X encoders from China, which will take awhile to get here, but the $25 price point was worth it. That will give me a chance to get the hardware installed anyway.
Okay, I have had a chance to think this over and I have a few questions.
What are the reasons that eeprom is needed? I would think that the calibrations could be hard coded and a simple homing sequence could replace the need to store position data. The encoders that I was looking at have a z track in addition to the standard a and b. This would give the ability for the encoders to know where they are relative to a single rotation. This would relate back to real world position of about 2 inches which could be identified visually. Are there other things the eeprom does that I am not aware of?
I do not doubt you when you say that the motor encoders could be disregarded entirely, but with the kinematics, do the calculations converge more quickly if the machine knows the current chain lengths? I suppose the inverse kinematics could play a role here.
The EEPROM stores the present location and device settings. The Due could save that to flash using the right library, but will lose it all when reprogrammed. That means that the chain calibration process would be needed when upgrading the firmware. That’s more an inconvenience than a showstopper, you’ve been through it with your Maslow setup.
The z track signals revolutions of the encoder so those would do absolute position sensing.
The calculations in present form adjust the chain lengths to achieve an XY location. If the XY location were sensed directly instead of the chain length, the inaccuracy due to chain sag, stretch and wear would be eliminated. Those routines would need some deep overhaul, its true.
That doesn’t answer the question of is it necessary to upgrade the hardware.
Floating point of any arbitrary precision can be handled by any micro. If speed is an issue then yes, a 64-bit processor is faster than an 8-bit processor, but ‘faster’ is a relative term, and ‘adequate’ is always adequate.
Well, there are several thousand Maslows running on the Arduino Mega platform, so I guess ‘necessary’ would be ‘no’ . The platform is running near its maximum capacity though, and is limited by the floating point implementation in terms of accuracy and speed. The encoders are handled by inline assembly language for speed.
Take a look at Kinematics.cpp and Motion.cpp, those are the places that have most of the calculations. Fixed point routines would need to handle the trig functions there.
Ok. So a cursory glance would indicate a lot of places where integers of a suitable scale would work. If the unit of measure was the micrometre (or micron) instead of millimetres then that would allow a reasonable representation of expected resolution to be recorded without decimals. 32-bit ints should allow enough headroom for most of the calculations.
I need some more envelopes to do calculations on the back of. Or napkins.
I became interested in the Due because it has more external interrupts that can be used for additional encoders while maintaining the pin layout of the Mega. I am not 100% on this, but I am also thinking that it could be used with the existing motor control board with some modifications to shift the 5v bus to the 3.3v bus?
It’s technically possible, but hard to do on the various boards for various reasons.
The stock Maslow board (and I think the other boards based on that one) don’t have a connector that reaches the 3V3 pin on the Arduino Mega or Due. That would make it harder to do a clean modification.
The boards based on the TLE5206 do connect to 3V3 but would need a few trace cuts and jumpers to switch over. I started looking at a new 3V3 version of the TLE5206 board last night and it looks like it wouldn’t be too hard to do. PM me if you’re interested…
one thing that I think should be done is that internal chain lenths should be
kept in terms of encoder steps, not mm of chain released. This is inherently
integer (and maintained by the encoder routines)
as for the restof the math, tracking to 0.1mm should be good enough for our
target accuracy of 0.4mm, but if you wantto be ultra cautions, go ahead and
track to 0.01mm
Early on someoen did do a version with fixed point math, looking to try and
improve the speed. It was dropped because it wasn’t faster.
There have been a lot of changes to the calculations since in any case.
When you re-do the math, it would be good to try and document it better (with
links to diagrams as needed) to help others understand what’s happening in the
future.
. The platform is running near its maximum capacity though, and is limited by the floating point implementation in terms of accuracy and speed. The encoders are handled by inline assembly language for speed.