Advanced Search

It works for me:
halcmd -kf
halcmd: loadrt hostmot2
Note: Using POSIX realtime
hm2: loading Mesa HostMot2 driver version 0.15
halcmd: loadrt hm2_eth board_ip=10.10.10.10

---

halcmd: loadrt threads
halcmd: addf hm2_7i92.0.read thread1
halcmd: addf hm2_7i92.0.write thread1
halcmd: setp hm2_7i92.0.pwmgen.00.enable true
halcmd: setp hm2_7i92.0.pwmgen.01.enable true
halcmd: setp hm2_7i92.0.pwmgen.02.enable true
setp hm2_7i92.0.pwmgen.00.value .5
setp hm2_7i92.0.pwmgen.01.value .5
setp hm2_7i92.0.pwmgen.02.value .5

And I get square waves on all three PWM pins


Is its a PWM scale issue? (default scale is 1.0)

Ooops, you also need to add grotius-tp  here too
github.com/LinuxCNC/linuxcnc/blob/master/src/Makefile#L1330

Looking at my chromebook with 2.10 installed from a .Deb, tpmod.so is installed in
/usr/lib/linuxcnc/modules

My thinking is that you could just deploy your new files in the right location in a stand alone deb.

But I think you also do more than just create a new tpmod version because you change some other files. I think that results in a new motmod.so
If that's the case, its loaded in the hal file so the modular approach of Linuxcnc still lets you keep it compartmentalised and add everything to the core Linuxcnc build just by adding some new folders under /src/emc

The trajectory planner is in
src/emc/tp
So if you made a new folder
src/emc/grotius-tp 
for your planner and included a Submakefile in that folder, you  just need to edit the main make file to include the new folder.
Here is the main tpmod makefile entry
github.com/LinuxCNC/linuxcnc/blob/master/src/Makefile#L1230

You could also use the same approach for changes to motion
github.com/LinuxCNC/linuxcnc/blob/master/src/Makefile#L1215

I suspect the Debian .deb build will include all .so files built, so it may not need changing.

I tested this methodology once by building a new module plasmatask because Andy thought that might be a good approach for plasma. I copied the  /src/emc/task folder to /src/emc/plasmatask and updated the main make file as I describe. Everything built perfectly and I could load plasmatask in the ini file no problems.

If you could do this, grotius-tp would be super simple to include in the main distribution.
 

PCW, any idea why I'm missing all of the PWM output pins? None of the 3 pwmgens have been usable with the new firmware. The pwmgens have no output and the gpio pins that correspond have no output pin either.


 

Routerworks wrote:

Are you saying I can use 1 stepgen and connect it to 2 drivers in the HAL file?  This is different that physically wiring the one output to two drivers. 

Yes, exactly, sorry if i was not clear enough.
Glad you got things working.

Grotius wrote:

What could be the reason  the business is quiet?

From last year we can travel visa free through EU, so nearly 10% of the population moved to Europe due to much better pay.
In a country with a total of 1.7 million people,that is noticeable. Add to that we do not manufacture or produce anything at all, the price hike, huge unemployment, extremely lazy people, "experts" with absolutely no knowledge, etc etc... and we are f@ked, properly.

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.