Bingo. We’ve never been able to avoid a recursive approach, IMO. So I’m focusing on making tabs 2/3 fast and easy, and basically treat Precision Calibration as the “it should be really good already” step.
I guess the holes would help if you aren’t sure about the diameter of the sled… maybe the sled isn’t perfectly circular or something.
Yep. Precision is always an option. And each of the tabs are fully configurable. You can specify the distance from the edge for the holes, as well as the hole depth with the Precision tab. So it’s your prerogative; you can jump right to that if it makes sense.
I got a newbie question. What are the main advantages of this CNCjs over webcontrol? I’ve been recommending webcontrol to all the new people. but should I be telling them to wait for the CNCjs because it’s that much better?
1 Like
The UI/UX is good: it’s simple to start, but has a lot of powerful widgets etc. you can enable. The main screen has full 3D rendering of the cuts in real-time, with visualization of the material being removed. And there are widgets that let you run, say, a tablet-specific UI plugin that works on the shopfloor. It really does a clean job with managing the machine state, tool changes, etc. It has built-in widgets for advanced features like Z-probes. It shows neat things like stats about the GCode. The ability to have a separate MPos from WPos is very convenient IMO. It has features like user-authentication, which a security minded person like me cares a lot about. It will be cross-deployed as a Mac app, Windows app, Linux service, and Docker image.
</ramble>
… and I’m building a lot more features …
2 Likes
That is interesting if that is the case for the Holey calibration. That process nearly completely ignores where the holes are made in the XY coordinate system. Instead it takes the chain lengths for each hole and tries to find a calibration that results in the spacing between the holes matching what the user initially measured.
I say nearly, because it uses one Y point in the XY coordinate system (not even the corresponding x point) to perform measurement M12.
The initial settings shouldn’t matter and therefore performing the Holey Calibration repeatedly shouldn’t result in better or different calibrations. If it does it is because of 1) the limited precision in user’s measuring distances (aka user error) or 2) I suppose a significant error in imputing the initial yOffset may cause an error.
My rewrite obviated a lot of this, instead doing a brute force attempt to get the actual hole locations to match the ideals. But first, it optimizes out things like X error (detecting if the stock was not centered). By re-running the “Define Home” step as well, my approach at least does converge quite quickly, I think.
This matches my experience, to some extent. I’m embarrassed to say I’ve spent many, many hours and have dozens of pages of calibration notes. I agree with (1) and find that I get better results by measuring the short distance to the edge of the stock. For (2), however, I found what is perhaps a bug with Holey. Especially as I got closer to high accuracy, I’d see some “thrashing.” Holey would start changing the motor measurements each round, sometimes simply back and forth, and I would never actually converge below ~2% error. Instead, I attempted to engineer out this problem in how I implemented the recursion, and I haven’t seen any of the same thrashing so far.
I know what you are saying, but in practice two times is better than one. I think with a perfect model and perfect measurements, one would be enough… but we don’t have either.
That is perplexing. I will have to think about that some more.
@zaneclaes would love to be a tester. I just picked up an original maslow. I’m going through the initial set up now. i’m running a mac book pro. I can see that 1.0.6 works on ios but does not support original maslow configurations. Is 1.1.0 ready for ios? thanks in advance.
2 Likes
Do you mean OSX? There are not dedicated [beta] branch executables for the different platforms yet. I’d expect that to happen in the next ~week. Right now, you need to launch the beta from the command line using node itself. Or you could use the Docker image, if you’re comfortable with that.
I have a question for the firmware folks…
The one thing I haven’t been able to port from the Mega to Due firmware is the positional errors. I find it quite useful that the Maslow aborts if a wire is loose, for example. Looking at the Mega source, I see that Axis.cpp handles reading from the motor. TBH, I’ve never even worked with motors before at the source code level. I’ve been treating them as an abstraction. I believe stepper.cpp is equivalent in the Due firmware, but I don’t see any attempts to .read() from the motors. I vaguely understand how it’s setting stepper bits, but don’t quite grok how that’s sent down the wire… and therefore how I would implement reading to calculate positional errors.
Steppers typically are open-loop (i.e., not closed-loop with encoders providing positional feedback). As long as a stepper doesn’t ‘miss’ a step (running too fast, bumping into something, etc.), it’s position will be known with great accuracy. As far as I know, GRBL doesn’t support closed-loop systems like the Maslow / M2 and I’m pretty sure that’s why you don’t see any read() commands … no encoders so nothing to read. It just assumes when it tells the stepper to move x steps, it moves x steps.
1 Like
Thanks for the explanation! So what I’ve done is to translate the Mega’s ALARM: Sled not keeping up... into a the GRBL Alarm: 3 (Abort during cycle). This is in keeping with my general philosophy to use the backend controller to “translate” and make the Mega appear as though it were a standard GRBL device. The Mega doesn’t really have a firmware locking mechanism. I debated adding it on the controller level for consistency, but it felt like an unnecessary burden on the user TBH.
I’d have to dig into it, but I though the mega locks under certain situations where you would have to issue a stop, ( “!” ) to unlock it. I could be wrong though.
Ah. Well, that’s what the Unlock button in the UI does anyways. The only confusion would be if the Mega fails to report an alarm, but that seems unlikely.
When you say GRBL, you mean the CNCjs side of the equation reading data back from the controller? The firmware has the encoder interrupts for keeping track of position. Are you saying it just isn’t reported to the user interface?
Maslow firmware does that (out of necessity) but I didn’t think that GRBL does because most CNC machines with steppers run open-loop without encoders. I could be wrong, but that’s my understanding.
I think the nuance here is: what is GRBL, really? IMO, it’s a protocol. Anything that conforms to the correct syntax is technically “GRBL.” So a machine which uses appropriate alarm codes based upon feedback is still technically compliant with the protocol. How it detects / generates those alarm codes is an “implementation detail.” If steppers don’t have feedback mechanisms, that’d explain why most firmware doesn’t use this approach toward detecting alert states.
I guess it’s both. As far as I know, grbl firmware doesn’t generate positional error messages and grbl-compatible gcode senders (i.e., cncjs) don’t read them when configured to talk to grbl (because they aren’t sent). I think you would have to add something to the grbl plugin to read a custom output of the M2 firmware that is modified to output the error messages. But then that might break compatibility with other gcode senders. For the most part, all of @ldocull’s magic is in the MaslowDue.ino file. You’ll find there is where the encoder reads are done and then the PID routines there as well use them.
1 Like