Advanced Search

@rodw

Agreed that the planner should be true to the physics, but the physics here has two valid outcomes depending on the machine. A small bounded jerk spike on a 1ms grid at a sharp corner is absorbed transparently by any drive with internal interpolation, the part comes out correct, no stop needed. On a drive without internal interpolation, the spike is real and a stop is the right answer. Both are physically correct responses to the same situation on different hardware.

The point is not to hide the problem but to give the integrator the right tool to handle it. A blind stop at every corner where the jerk limit cannot be met on the 1ms grid would significantly hurt cycle time on complex CAM toolpaths for no benefit on machines where the drive handles it anyway.

The proposal on the table is a new modal G64.1 P Q
jerk-aware continuous path mode that behaves like G64 P Q but adds automatic full stop fallback when the jerk-constrained cornering velocity rounds to zero. Off by default to preserve existing behavior, opt-in for integrators who need provably clean command streams or are running drives without internal interpolation. That seems like the right balance between being true to the physics and being useful across the wide range of hardware LinuxCNC runs on.

Yes, I was aware of the issues. Blind workflows where you have little control over the inputs is always a problem compared with a closed workflow.
My thought is you should be true to the physics. If a blind stop is required, do it. If the outcome is undesirable, its up to the user and his client to resolve.

Just because a part can be designed in paper or computer, does not mean it is machinable.

@endian
Exactly right, the cycle time is a fundamental constraint that belongs in the tolerance budget, not something to fight against. G-code level control of spike tolerance makes a lot of sense and aligns well with what I have been discussing as a TP option.

@rodw
Fair point in an ideal world, but LinuxCNC has to interface with a very wide range of CAM outputs, many of which the end user has no control over. We should strive for maximum compatibility. Yes, some G-code will be genuinely nonsense and will need fixing at the source, but for cases where the geometry is valid and the only issue is a parameter mismatch between the toolpath and the machine limits, an INI or G-code option that lets the integrator choose the behavior is the right balance rather than rejecting the job outright.

andypugh wrote:

I have a need for some Pico hardware to validate some updates to the driver (github.com/LinuxCNC/linuxcnc/issues/2331)

Could I persuade you to send the cards to the UK (and maybe reduce the price even more, as this is for the project, not for me, and the project has exactly zero money)
 

How much does the project need me to send the OP?

I can't code my way out of a paper bag, but I know how to solve this problem.

Thank you for reporting back.

I just wanted to register that this solved the same issue for me on 2.9.7. There are older solutions on the forum, for example " Automatic pause when spindle is started " from 2015, but they don't reflect current pin/signal names. Modified default spindle control HAL section below, two lines commented out and six more required.

My spindle VFD is connected as follows for simple "run" operation with no feedback:

Hi, just wanted to give an update. The problem was annoyingly trivial: The chinese board was faulty.... They are of astonishingly poor quality. I ordered two to new ones, one came already dead, they soldered the diode (on the 24v input) in the wrong way. Anyway thank you for troubleshooting with me. All the best, Marc

All this talk about exact stop mode and angles to me seems to be an academic exercise in mathematics. In the real world it can be solved by simply sacking the part designer. A few minutes at the design phase to account for the physical constraints of the manufacturing process can save many hours of work on the shop floor. This does not just apply to the machining world, there are many other work environments where this rule applies. In my case, it applied in the printing industry and I made sure wherever possible my graphic artists designed for our capabilities.

Reject the design, and send it back for rework would solve most issues when this hits the real world...
 

I have a need for some Pico hardware to validate some updates to the driver (github.com/LinuxCNC/linuxcnc/issues/2331)

Could I persuade you to send the cards to the UK (and maybe reduce the price even more, as this is for the project, not for me, and the project has exactly zero money)

Aciera wrote:

Sounds correct. Famous last words

Yea, that was backwards

Makes sense in hindsight: I want the V-DRO to move at twice the speed of the joint, not half.

But everything's working now: switchkins, subspindle synch to main with CSS and the parting slide programmed as "X".

I couldn't compress a GIF small enough to embed, but I've attached a short video as a ZIP file.

parting_slide.comp and the four M-codes are all commented pretty heavily for future reference.

I think this is nearly the last hurdle on the DIY lathe.  Only big challenge I can think of is mounting tools for subspindle work.

Thanks again @Aciera, couldn't have done it without you.

I suspect that the problem is getting hold of the actual hardware?

I suspect that the problem is getting hold of the actual hardware?

endian wrote:

 
I saw at my own eyes synchronization of 120 seconds with beckhoff SoE AX5125 driver with older firmware ... its not odd behaviour 

beckhoff IPCs have sometime very similar behaviour with their own hardware from my close experiences...

[/quote]
The more i read here about ethercat = the less i like it.
Thank you for pointing out the quirks, not only the good stuff.

I tried Googling the RRW lab board and all found was this thread.

Can you link to a product page or give is more to go on?

Do you have a driver for it?

Hakan wrote:

Synchronization of slave clocks can sometimes take a long time at start.
There is a warning in syslog if it takes more than 5 seconds, or is it 30?
Don't know how to fix it, more than hope the slaves' clocks run more equal
when not being nudged by the master.
Add pll-err to the halscope plot. 
 

I saw at my own eyes synchronization of 120 seconds with beckhoff SoE AX5125 driver with older firmware ... its not odd behaviour 

beckhoff IPCs have sometime very similar behaviour with their own hardware from my close experiences...