This discussion might have happened before (and it seems familiar to me but I suffer from CRS), but it’s real hard to find something specific when the keyword is error… So sorry for restarting this conversation…
It appears to me that the positional error reported by the controller are the encoder value errors… meaning the motors were told to operate to get the encoders to a certain number of steps, but in the end it didn’t get there and so there’s an error value. This value is reported to Ground Control and this is what’s used to move the error indicator on the screen. I never incorporated this into WebControl and am looking at doing so.
The “problem” I have is that the error reported are in essence chain lengths and they aren’t used to calculate position based upon the kinematics, but rather a simple equation that assumes the chains are at 45 degrees:
This might be a reasonable approach and Good Enough™.
However, I could implement it in different ways and instead of a indicator, I could do something like a gauge, which I personally think might be a better indicator. I could put two bar gauges on the screen and show percentage of error to the error tolerance (the one that defaults to 2mm)… the image below is just to clarify what I am describing. By doing this, you can watch how the machine behaves and know more readily if error is getting close to the limits. Thoughts?
especially on mobile devices, a gauge would be far better than the red position
indicator.
I also like this in that it potentially eliminates the need for the kinematics
calculation in GC (which changes over time and with what calibration type you
are using)
It shows the percent of the positional error limit (defaults to 2mm). I think this is the most meaningful value (more so than an absolute value) because it gives in indication of how close you are to reach what you, as the user, define as your limit for error. If you are ok with more error and you changed your positional error limit to 4 mm, then this still shows how close to your limit you are.
I like this idea. However, there may be some failure modes. The only one I can think of right now is: what do you do when the error is huge, e.g. 4 ft, because the machine is not moving correctly.
I do like the idea of using the kinematics equations to calculate the actual error. I didn’t realize this wasn’t currently happening. I just never thought about it. I have made cuts on my machine where it looks like this error has caused a visible deviation in the cut.
If error exceeds the positional limit, it displays an error message (sled not keeping up) and stops. I believe the gauge stays pegged at 100%.
Error will cause a deviation in your cut, you just can’t trust the indicator being shown on the screen as being accurate. To get better, you have to run the iterative forward kinematics function. I don’t know performance-wise how an PC/rpi could handle that as well as all the other things it has to do since error messages come in at a fast rate.
