Advanced Search

Yes, a missing power supply may be the issue
All 7I77 encoder circuitry is 5V, so you would
need a separate 12V supply.

Do you have the converter manual? it should show
the 12V connection.
 

I did check a few of the whc-whb04b-6 buttons with halscope and they look clean so I guess the answer is that the pendant buttons don't need debounce in the .hal file

Thanks for your reply, PCW.

I did some more measurements and I’m starting to learn a lot. It’s definitely a bit trickier working on a real machine compared to those nice clean test setups we often see on YouTube or datasheets

I noticed there’s a 12V pin on the board (right next to the white cable), but I originally assumed this was only used in other configurations. Now I’m starting to suspect it might actually be required for the board to function properly — possibly to power some signal conditioning or amplification circuitry.

 

Do you happen to know if this 12V input is normally used in setups with Mesa hardware? The 7i77 doesn’t provide 12V, so I’m wondering how this is usually handled. Is it common to add a separate 12V supply just for boards like this?

I haven’t applied 12V yet, since I don’t want to risk damaging anything.

Thanks again for the help!

Its certainly doable in hal, not sure if its a generally needed function
in the PID component.

I second this. Big thanks to Scott for figuring out the Pi5 stuff. I was able to get SPI running for my own project (very similar to Remora SPI) in just a few hours, the same day I acquired a Pi5 !

Many, Many, Many thanks.  Followed your instructions and it looks like everything is working.  The old acronim about keeping it simple applies.  I will say that all the work I went through to get to the point where I understood what you were talking about was worth it.  However I will say I read a awful lot of suggestions that were all over the field.  You hit the nail on the head.
Sure I have much more to learn.  The only thing I have left to do is calibrate the A axis.

Best Regards,

Routerworks

Hello Gentlmen, 

Have anybody knowledgement if pid.xxx.deaband should be variable depends at actual command speed over some component stuf ... with some linear character? I am thinking about it some time...

regards E....

It's 24v. ill have to dig for the pinout.

Fabian,
Yes, I agree that overfitting doesn't exactly describe what is happening.

I was meaning to post some additional info I found on this. It's one of Raph Levien's blog post on fitting cubic Bézier curves, (specifically in the section on the solutions for quartic polynominals):
raphlinus.github.io/curves/2021/03/11/bezier-fitting.html

My understanding is that in his case, the degree of the curve (in this example quartic) and the fact that there are two parameters (x-moment and signed area) leads to four minimal solutions that the solver could converge to (not infinite solutions, luckily!). I believe that in Raph's case, three of these will be local minima and only one will be the global minimum, so we cannot be certain of converging to the global minimum if we start at a random position in the parameter space, as you said.

Raph says that one of these solutions (when optimising for x-moment and signed area) may contain a loop. This is a valid solution to these parameters because the area inside the loop has the opposite sign to the outside, so the signed area is still minimised.

Raph says that you can generally reject this solution as the arm length is longer than the others. But my understanding is that you can only do this by calculating multiple solutions and rejecting the one with the extreme arm length. You can only do this if you obtain at least two solutions, and even then both may have issues.

What might be happening is that you're regularly converging to a non-global minimum, but normally it's so similar to the global minimum that it isn't evident in the result. It's only when you converge to the solution with the extreme arm length that you notice an issue.

Grotius,
I think your method of fixing this by applying a tiny offset worked because it meant that the the loop was no longer complete so its signed area was a lot larger. Although likewise, adding this offset could technically break a curve which would have worked without it? But that's most likely an edge case.

Also, slightly off-topic, but there might also be instances where this loop with the extreme arm length is the solution the user intended. For example, the intended path did have this loop, but under-sampling in the CAM software means that points are missing which should explicitly indicate the presence of the loop. But since this information is missing, it's probably better to treat this as a bug, and reaffirm that the trajectory planner may choose a solution which doesn't match the path you intended. The way to get around this is to increase your sampling frequency in your CAM software.

Back on topic, the way I see it is that the most rigorous way to solve this problem is to start from enough locations in the parameter space that you obtain all (or some) of the local minima, meaning you can be certain of having found the global minimum (or be sure enough of being close to it). But this is computationally expensive and harder to predict how long it will take to return its output.

So it's probably better to find shortcuts which make you more certain that if you converge to a single value, it's good enough even if not the global minimum. I think the idea you mentioned of initially fitting lower-order curves should help with this.
It also seems that using the gradient descent method along with the appropriate number of parameters will increase this probability of you finding the global minimum.
But I understand that some of these solutions are antagonistic to making the solver work fast, even if it is in a separate thread.

Hi Rod,

The packages up to 200mb can be uploaded to codeberg. No problem.
The scurve is 63mb, it will fit.

The thing is, i always use rip-installations. So my whole mindset is up to a git clone.
Before making a .deb for you all. I have to make a list where what to install.
As i understand your installation path is like /usr/local/ or /usr/
And also the lcnc source need to be recompiled. If files are spread around,
it will be hard to recompile the source.

But i have no oversight now. Maybe first unpack a linuxcnc .iso and look wherer the
files are stored.

It's also not easy to modify the lcnc original make file, because it will not accept .cpp files for compilation.
Otherwise i could just copy all in, and edit the original makefile, and done!

Rodw, what's your idea about this? I am still positive, no problem.

 

Hi Fabian.

In the mean time i experimented with clothoid used for motion. This includes 2 attached clothoids for example.
Now the problem is not the ceres solver, the iterations, or the initial guess value. All these are ok.
It takes about ~12 iterations to fit the clothoid.

There are certain gcode files that have very short segment attached to longer segments under 90 degree angle.
Then the trim algo trims both segments given the P value. But the very short segment is trimmed less then the longer segment.
The clothoid result is valid, however it path can be into the workpiece.

Soon i will show a picture how this looks like. I think the solution lies in even trimming to both segments in some cases, or in all cases.
The solution is therefore quite simple.



 

More photos ,this time the Heidenhain servos and the Creativtec.drives. 

Hi Grothus,

always impressive how fast you make progress here.
Did you have a closer look at the problem you called "overfitting"? It looks not like classical overfitting (this usually descibes if a fit follows the data much to closely and therefore follows statiscal fluctuations instead of the desired data trend).
In your case it just found a local minimum during fitting instead of the global minimum. Doing a 360 or creating this sort of step in the corner is a viable solution that is quite smooth etc. it is just not the solution we want.
One possibillity to avoid this would be to somehow create a better initial guess before the fitting starts. This could also reduce the iterations/time needed for fitting. Another possibillity might be to use a different solver.

Best regards,
Fabian

yeah the way it is setup at the moment The PC is on a hinge under the table of the CNC and swings down for service. This means I can use the space under the table to store things. The box with power supplies and breakouts also swings down.

However the pc and the power supply box are very close together on the IO side of the PC and as the CNC machine is half finished I cant lock the power supply box out of the way(I will be able to do this when its done). It impacts my ability to work on the PC . I can detach the PC but it is a massive pain and I theory I shouldn't need to. I have already done a motherboard swap with the PC in it's service position without issue.

Obviously It did impact my ability to troubleshoot. if I just swapped the cables all would have been solved. I swapped everything else I didn't expect that a cable that I had tested for continuity was an issue.