FYI, this was my preferred route, but the CNCjs maintainer is indisposed. No PRs have been upstreamed in months. The project isn’t moving at all right onw.
I’ve calibrated 5 different machines now using this process. I’ve even intentionally started with a wrong zero position. I actually spent days confirming/debating this part and came to the realization that it is most important that the stock be centered between the motors As long as that is true, things work well regardless of original zeroing. I suppose if you were way off it might break down, but I did explicitly try to break it in this way
It actually already supports this, there just isn’t a UI for it. The “MaslowCalibration” class can be configured to cut holes of any depth, at any location. I’ve run calibration using the “Holey” approach, cutting holes 1/2" from the edges, to get extremely good results I plan to add a 3rd tab called “Precision Calibration” which will add this configurable, destructive approach.
I have makerverse loaded on both of my systems using the long slow way. It communicates with the mega, but the M2 and the duo systems don’t do anything yet.
Does one of the lists of instructions above work or is there still trouble shooting to be done? I wanted to get started on this tonight but I’m kind of unsure where to start (in addition to having nearly zero experience with Raspbian commands).
@Orob sorry but I still need the answers to my questions. That screenshot doesn’t tell me much. Specifically, what firmware version are you on? What happens if you type $ or $$ to print out the help / information?
Any problems are just a matter of installing the appropriate dependencies for your particular device… which will necessarily depend on the device you have. The problems you’ve seen described here have to do with installing multiple versions of nodeJS at the same time (which gets complicated fast). It sounds like you’re using a Raspberry Pi. I just copy-and-pasted the exact instructions from my last post on a fresh Raspbian installation. So if you haven’t made any other modifications, I’m quite certain that it will work.
I sent the other screen shot and it didn’t show mucht because that was all it did. There were no messages.
When you type anything in, there was no response. Turns out it was wrong usb port. I’ve read about that problem. When connecting to the programming port, then all this shows up as expected:
That looks good! Is it now recognizing the Due? The Maslow widget should show the firmware in the last fold-out section, like in my screenshot in the post.
edit actually it looks like that is old firmware. I’d expect to see many variables between $86 and $100. Please refer to the original post re: the required Due firmware.
My only issue was with NPM not installing. I googled it and found something called aptitude that fixed my issues.
My next question is about remote access. Can I get to CNCjs from a different browser or should I just use VNC* and do remote control? I really liked the remote access aspect of Webcontrol.
Yep! You’re looking for the allowRemoteAccess setting from the README, which defaults to false. Simply adding it to your .cncrc file should be sufficient. Then, just load the IP address + port for your Raspberry Pi in a web browser http://192.168.0.100:8000 (or similar).
You’ll notice I also used aptitude in my instructions (sudo apt ...). This is the default Debian package manager, and the most common way to install/update any software from the terminal. In fact, your “install software” UI in Raspbian is just a UI for aptitude.
Zaneclaes,
Excelent work, very easy to install and run.
Just a couple of doubts… when i see the Maslow parameters, things like sled width…where it read this vslues from? And how csn i change them?
And other thing, when i run the calibration process, it have sny order where to go? I ask because i clik the left up corner and the sled whent to the right bottom… Anyway, it whent to the six point but no where i told it to go…
… for those following along at home, the Precision Calibration tab adds the ability to cut holes for even greater accuracy. It’s recommended only as an “optional” step, since I’ve actually had good luck with the Edge Calibration only.
You’ll need to get a tape measure and measure the sled’s width. Most default values should match the standard kits, though. And then use Grbl commands to change values. For example, $90=5 would change setting number 90 to the value 5. However, if you refer to the above screenshots, the “input fields” in the UI are basically just a cleaner, easier way to achieve the same thing.
Can you explain more (possibly again) about how the calibration and homing works. If I have a new machine and use the jog buttons to position the sled as closely at the center of the board as possible and then press “define home”, I assume it calculates the chain lengths based upon the current calibration values (which are likely to be incorrect). Is this correct?
If so, the user then moves the sled around the board doing edge measurements and develops a set of measurements that will be used to optimize the calibration. Once optimized, the calibration values are updated. Now, when the user issues a move to 0,0 (i.e., G00 X0 Y0) is he going to be back at the original 0, 0 or some place else because the calibration values changed? If not, does the user then move to the center of the board and press define home (or something else) to fix this, or does it not matter at that point?
Tab 2 (Define Home):
takes user input for grbl motorOffsetY and distBetweenMotors. Uses inverse kinematics built as a Javascript class “MaslowKinematics” (ported from Kinematics.cpp) to translate the position of the sled into ideal chain lengths. Sets this ideal chain length in the Maslow firmware and re-homes. Subsequent “Set Home” actually invokes the reset chain lengths (B08 on the Mega), just like WebControl does.
… there is an “advanced” feature where the “define home” position can actually be any Y coordinate you desire. I use the sled touching the top of the stock, aka, y=15". This makes it very easy to re-home X/Y (since I also have a 12 o’clock mark on my sled, and one on my spillboard). All I have to do is align the two marks, with the sled flush to the top of a piece of stock, and I’m home. But the old “paint the chain link on the sprocket” trick still works, too. Anything that gets you back to that original Y position, when the chain lengths were saved, and ensures that the sled is centered between the motors. Note, others have worried that centering is hard. I do not find this to be the case. With the mark on the spillboard, it’s impossible to miss.
Tab 3 (Edge Calibration):
I re-engineered Holey calibration and found I was able to improve upon its efficiency with a slightly different approach toward calculating error margins. tl;dr, I simplified some math and brute-forced a recursive algorithm (I wanted to make it a genetic algorithm, but meh). I adjusted this step so that it attempts to make the sled exactly even with the edge of the stock.
As others have pointed out, you need to be sure of the stock size. But I find it very easy to measure when the “ideal” is merely that the sled is flush with the stock. Even if the sled is slightly outside the stock, I can simply use a ruler at this short distance to measure the negative value, accurate to mm.
Tab 4: Precision Calibration
This one re-adds the cutting into the calibration. It defaults to place the holes just 1" from the edge of the stock. By using a 1/8" bit, I’ve gotten insanely good results here. I’m seeing < 2mm maximum error at any point throughout my stock.
So that’s my main question. When the ‘ideal chain lengths’ were first calculated, they were based upon the calibration values in the machine at that time. Let’s say it comes up with 1521 mm but in reality, the chain length was 1523 mm because no calibration has been done. The user does the calibration and then sends the machine to 0,0 but ends up, say, 1 mm below the previous mark because the calibration has changed. So the user should jog the machine back to center and press define home to reset the chain lengths to values calculated using the new calibration values, correct?
That’s one option. I find a better approach is to repeat the entire calibration flow. Treat the dialogue as a session, from left to right. You can restart at any time. With this approach, you do in fact end up modifying the originalChainLengths several times. But it produces better results, faster.
edit part of the reason for this was division of responsibilities. Tab3/4 does not edit the origChainLengths. Only motor offsets and leftChainTolerance/rightChainTolerance. Only tab2 edits the origChainLengths.
I’m about to try calibrating again. Assuming I don’t run in to any more UI errors to deal with, I’ll time myself to see how long it takes to get to that same 2mm level accuracy.
Thinking this out, the controller effectively only stores the encoder value for 0,0 on an M2. If a command was sent to have the controller move the motors to that encoder value outside of any kinematics (like the maslow’s singleAxisMove command) it will return to 0,0 precisely. But if you issue a G00 X0 Y0 after a calibration (which uses kinematics), it will end up some place differently. If after calibration you then move the sled to 0,0 via a set of G00 jogs and then define home, it will store the new encoder values. If you then repeat the calibration multiple times at that point, then you’ll get more accurate results eventually to a point of diminishing returns.
So, it seems likely to solve itself if you do it multiple times … just like you need to do for any of the maslow’s calibration.
