Advanced Search

Hi Automata,

andrew2085 was very helpfull. It was hard to get his code to work properly.

We have a robust clothoid 2-dimensional library.  
For now it lack's the 3-dimensional clothoid implementation.
github.com/ebertolazzi/Clothoids/issues/45
I am unable to create the 3d clothoid from his comments.

A clothoid needs a iteration ~20  to find optimal fit. This is also the case at a runtime interpolation when u
use the clothoid library in a standard way.

The new approach is time optimal. By this i mean the "arc-strip" method for curves of any type.
The new planner's infrastructure makes it easy to add new trajectory smooth algo's. So almost anyone can
add a algo to it. Sinds it also has a algo template.

Using a clothoid is a very good approach, i agree 100% with that.

Downside is that the real deviation is hard to find. Then 2 attached clothoids could do exact deviation.

When optimizing the path at load time, the clothoid is constructed (~20 clothoid iterations are done) and clothoid is
saved as arc_strip to be interpolated as fast as can be later on.
Soon i wil test a clothoid this way.

Julian made a test environment to test multiple cnc files in a loop. The velocity's are extreme.
We had scurve hang's in certain cases early'er this week. After figuring out, we had some isnan values coming up so now and then.
Isnan = is not a number. This can happen when dividing to zero for example.

We decided that the planner has to first pass test bench, before going any further writing smooth algo's on top.

Let's run the test environement for a few more hours.


 

Another (somewhat random) thing that came to my mind is that we can also change the 'ferror' values from gcode.
That might come in handy.

Good luck.

Hi Grotius,
maybe the biclothoid library stuff you and andrew2085 developed in a previos thread is awesome.
forum.linuxcnc.org/38-general-linuxcnc-q...ruckig-lib?start=350

Maybe that can be used for filleting. And since we can calculate the length of a clothoid given its start and end curvature, maybe it can be used for the S curve trajectory generator more easily and without approximating the arc length.

Thanks for working on this hard problem.
-automata

slowpoke wrote:

I had the link for that one. Perhaps I wandered off this thread when I found it. It was a compilation of I think all of the macros showing the actual operation on a lathe much like the video you referenced, just for all the different operations quite a good video, no idea where I found it and can't seem to find it.

Thanks

I think this video does a good job of going through the macros but I don't know if it's the one you had in mind:

Great news. Just some clarification: is this planner based on your work or it is based on Ruckig Lib with user @Beef : "That's why Grotius and I have decided to start this new project ...." ?

2.4 with round rods on Y and Z, and 10mm belts, not the usual 6mm.

Appreciate the effort.

I've had a think, and I've got one more config attempt left in me before I quit trying to have a working C-axis.

Plan is essentially what PCW suggested in my other 'freewheeling' thread.  I'm going to abandon caxis.comp, and instead use orient as a 'bridge' between velocity spindle and position-axis modes so the c-axis doesn't error out upon reconnection.

Flipping between spindle & axis will use M-codes, and I think it can be done without any halui stuff so I can do everything within the same g-code program.

I'll start a new thread when I run in to problems with this attempt.

I  guess riju didn't need one that badly.

Thanks for getting back to me.  I am away from the workshop at the moment but I will do this test as soon as I return. 
Since my post I have adopted the default eeprom address 10.10.10.10  I have also set the PC to 10.10.10.11

If I type
mesaflash --addr 10.10.10.10 --device=ETHER --readhmid
The result is
Unsupported ethernet device 7i97T at 10.10.10.10

Thanks for your help

Wait is your big one set up as a 2.4 or a Trident? Eventually I am looking to build a 2.4 version with a 600mm cubed
work envelope (or bigger). Just not this round. LOL

Well, I had a good look and compared it to NoJo's config but I'm afraid I can't wrap my head around the problem.
If i understand spindle synchronized motion correctly then it really only depends on the encoder signals connected to the 'spindle.0.' pins.
I think the most likely way figure this out is to diagnose things with hal scope on the machine and find out what is happening to the index-enable signal and z-axis motion.
I'd love to help more but I have no hardware to test any of this.

You are absolutely right. I was extremely happy to see it run successfully
Now I need only connect the right PIN's since between hal_pi_gpio and hal_gpio the pin numbering is physical / BMC.

Anyway I appreciate your effort to help out
JAiro

Well that was embarrassingly simple not really why it worked previously without it but it seems to have fixed it.

Thanks

On the loadrt line you are trying to assign GPIO12 twice
loadrt hal_gpio inputs=GPIO3,GPIO5,GPIO6,GPIO4
outputs=GPIO12,GPIO23,GPIO16,GPIO11,GPIO20,GPIO10,GPIO24,GPIO19,GPIO21,GPIO12,GPIO26,GPIO13

The you have done this, trying to use GOIO12 twiceYou need to fix these issues
You may need to increase your base period over 10000, I tried 15000.
And as you did not supply your postgui_call_list.hal I had to comment out that line, to get everything to load.

These are my HAL and INI files:

drive.google.com/drive/folders/1ZyTfg1zN...FlzQlUXC?usp=sharing