Pretty cool machine for somebody who had never seen one. Good for the OP to see there are other solutions.
I was envisaging much more gradual arcs. Maybe that was because I used to get 2mm rubber sheet cut with a tangential knife machine including 6mm dia holes.

When I started this, I wanted the arc radius and Andy asked me to add the tangential heading as by the time I had the radius, the heading was trivial. (so we thought anyway). It will be quite handy.

Some Yaskawa servo drivers support LRW. Check syslog for this message to know if it does

Das klingt gut. Ich melde mich, sobald ich das ausprobieren könnte. Danke.

Yes. VFR input works well. It's output for actual spindle speed

PCW wrote:

I guess my question now would be: Why are there relatively huge steps in the commanded position?
 

That's exactly the issue I can't get rid of. This is just with G0Cxx commands. I'm suspecting if I zoomed in the second plot enough it would look the same just at higher frequency. For example when homing it acts fine but that's probably because the commanded position is instantly much different and the PID loop takes care of reaching it. But here the commanded position supposed to trail ahead by some degree to let the PID do it's thing I suppose and it just doesn't seem to work with the joint either reaching the position and output going to 0 and then falling behind and shooting up, rinse and repeat... If I lower the P ratio to where it trails just behind, the commanded position slows down aswell eventually leading to coarse steps like before.

I finally checked your drive manual.  Your drive can handle 4mhz pulse input when using differential signals.

If your drive is set to the default input of 10,000ppr (parameter P0.22), and you want ~4100rpm (motor) for 6000rpm (spindle), that means your maximum pulse frequency will be ~680khz.

Tuning or inertia issues aside, it also results in a fairly coarse positioning resolution of 19 pulses per degree.

You could increase the drive positioning resolution by a factor of 4 without running in to the drive's (or Mesa's) input frequency limit. 

I'm aware that the motor is not exactly right for this, however it was already on there before me. It's the same one from the manual with 1500rpm rated speed, making for a pretty slow spindle. The 4MHz value is what I had in mind when figuring out the pulse widths and so on, I admit though I forgot about the motor rating, but for now in spindle mode I only had it in the hundreds range and in axis mode it's even slower. I will try increasing the resolution and see, thanks.

why not just align the C axis with the last segment of the trajectory? with trajectory blending on that worked okish for me on a leather cutting machine.

github.com/yur7aev/linuxcnc/blob/nyx2.8/...ponents/tangent.comp

dear sir , i hope i can explain my idea in accurately , and hope it is usefull, what if we index the code data vector sent from the interpreter to the motion controler , like a sequence segment to force the motion controller to attach and trigger the heeding calculations to the segment without override , sure ther might be some data or technic in the strcure would be helpfull without adding a new data field

I have not been able to review this further today but
In the interpreter I have added a couple of procedures here that calculate the headings
github.com/rodw-au/linuxcnc/blob/state-t...erp_convert.cc#L7080

tag_straight has a debugging print line that is correct. There is a simple gcode file here that draws a square
github.com/rodw-au/linuxcnc/blob/state-t.../nc_files/testg2.ngc
and the output in the print statement is perfect.
But the values are altered before it gets to the pins so I wanted to repeat the debugs with these files.

But look at that, I am not calling 
write_canon_state_tag(block,&_setup);
in tag_straight. Hopefully that is what's missing. I've hacked into this procedure so much, I had a clean up that went too far...

the block is written to state tags in
github.com/rodw-au/linuxcnc/blob/state-t...4ngc/interp_write.cc
both the block and the tags

the heading for the arc is calculated in motion at
github.com/rodw-au/linuxcnc/blob/state-t...tion/control.c#L2230
We need to do that because the interpreter tags are static for the life of the segment but on an arc, we need to calculate the heading at the point on the circle at every call of the servo-thread. It seems to be working but I have not validated the data.


Good luck!
 

mclien wrote:

ballscrews ar primary because the original threads in brass nuts have quite some deadway.

Just so you know, LinuxCNC has backlash compensation parameters. That said, I'm not real sure milling dies would go well with backlash. I used to have a diy CNC router with cheap ACME screws, running LinuxCNC + parport + microsteppers. I did more drilling than routering with it, drilling the thru-holes in home-brew PCBs. On that machine, backlash compensation was the ticket.

The drive is at 10000 PPR and around 1.45:1 spindle:motor overdrive, from my calculations 6k rpm spindle speed is around the limit.

I finally checked your drive manual.  Your drive can handle 4mhz pulse input when using differential signals.

If your drive is set to the default input of 10,000ppr (parameter P0.22), and you want ~4100rpm (motor) for 6000rpm (spindle), that means your maximum pulse frequency will be ~680khz.

Tuning or inertia issues aside, it also results in a fairly coarse positioning resolution of 19 pulses per degree.

You could increase the drive positioning resolution by a factor of 4 without running in to the drive's (or Mesa's) input frequency limit.

However...unless I'm looking at the wrong manual - or you have an unlisted motor - the 5.5kw servo is advertised as having a max speed of 2000rpm.

Do you have a different motor/drive than is listed in the manual?  If not, I'm not sure that motor is going to do what you want in spindle mode.

sir , i am sure of hoe good teacher you are that i follow your work
i see that you are doing very well in your path and sure you will solve the problem , i am trying to think systematically when i say that the loss of the data may be because deffirent time frams between the sender and reciever or the sequencing -sorry about the terms are not accurate , i am a beginner- hope this might help , it is enough to me now to run a customed component to do the job , i am struggling to make it , its performance like mach3 feature is great now , i hope you help me to do such component , i have just made one and compield it but it crashed because of syntax error , i used a c code with primary approach
angle = atan2(y-vel, x-vel)
y-vel = y-vel + y-acc * dt // dt = fperiod
x-vel = x-vel + x-acc * dt // dt = fperiod
for open loop machine - stepper motors

I guess my question now would be: Why are there relatively huge steps in the commanded position?

Die 2 files liefen in meiner Simulation fehlerfrei. Sogar bei Radius Toleranz auf null gesetzt.

[RS274NGC]
#CENTER_ARC_RADIUS_TOLERANCE_MM = 0.00127
CENTER_ARC_RADIUS_TOLERANCE_MM = 0


Bezüglich den % am Anfang/Ende ist noch diese Info verfügbar:

Using % to wrap a G-code file will not do the same thing as using a program end. The machine will be in what ever state the program left it in using %, the spindle and coolant may still be on and things like G90/91 are left as the last program set them. If you don’t use a proper preamble the next program could start in a dangerous condition.
 

Some people run the pi4b with a slower servo thread eg 2 ms or 1.5 Ms with mesa cards
run:
latency-histogram  --nobase --nobase 1000 --show
and share the screenshot here. the 4b is marginally OK but 126us is fine for a Mesa card at 1 ms servo thread.

No. The tool change position has to be commanded in the Gcode. The tool change on this mill is manual.

Thank You!
-Steve