Did you also get the M19 and axis-to-spindle switch to work as you said there were some issues?
My first thought there was to just verify the drive is actually switching modes, you have the 
opmode-display from lcec you can watch.

Published error traversal methods based on wrapping a signal through a digital input cause g38.5 to fail and be replaced by G0 or G1 - an erroneous path due to poor accuracy and surface finish speed. I experimented and compared the smoothness of the result with G38.5 versus G0\G1. To use G0\G1 for rebound, you need to set an excessively large amount of upward rebound, which radically reduces the speed of surface treatment and just as significantly increases the noise of the operation.
Conclusion: we must fight to correct the error.

Good morning everyone.
Rodw, yes, indeed, the pin for freewheeling will be managed by a GUI.
The idea is good, but in practice, we wouldn't solve anything, because when the operator selects mechanical movement and the pin switch is executed, we disable the drive.
In this case, for example, pos.command is 200 mm.
Now the operator can move the axis mechanically.
Let's imagine that it has reached -1000 mm in the feedback position.
Now the operator disables the mechanical handwheel, we execute the switch, and re-enable the axis, but LinuxCNC will issue a ferror alarm because the commanded position is 200 mm and the feedback is -1000.
Clearly, increasing the ferror parameter to 1000 mm is not feasible.
In reality, the only way to adjust the command position value to the feedback is to turn off the auxiliaries so that LinuxCNC copies the feedback position to the command position, and then turn the machine back on.
This axis parking feature is useful in many situations, even on mechanically indexed axis tables.
We need to find a way to modify the LinuxCNC code so that it switches a pin and the command position follows the feedback, just like when LinuxCNC is disabled with an emergency.
In this case, if you rotate the encoder or move the scale, the command position follows the feedback.
There should be a pin for each axis, which can be enabled on the fly.

i tried with the ethtool but no change
 
after reading some more i disable AMT setting from bios but the value remain the same

I have a cnc machine with a carousel atc (24 pockets, 10bit encoder), using gray scale absolute encoder and my intention is to use the carousel module to control it.

In initial tests with the module got me getting questions so I have looked into the code at since i did not understand the position value:
github.com/LinuxCNC/linuxcnc/blob/master...onents/carousel.comp

The value I am getting is the raw value as current-position from the carousel component, this is not wrong but I got curious so I looked into the code and now I got more questions regarding when calculating the target position.
In all places in the state machine where the target position is calculated the current_position is used without scaled to the same "size" as the target pocket.
I do not know if I have understood the code correctly or missed something. Maybe I would need to update the component to my specific case.
I think I in my case needs to scale the wanted pocket value to bit value to calculate how far the ATC needs to travel.

Have i understood this correctly or am I missing anything? 
 

The theoretical limit of the Pokeys57CNC is 125'000 steps per second. Whatever this might translate to, depends on the machine.
My minimill has just standard screws and also smallish steppers, so I keep it on the slow side: 360mm/min => 6mm/s => 4'800 pulses/s
The problem with steppers is, for some smooth operation, you'll want microstepping, but then you loose torque. I added a belt reduction to "help" with the torque loss, but sacrifice speed again...

Very interesting. I have a Pokeys here so am going to give it a whirl!

Any idea of the maximum velocities you achieved?

Das war das Problem. Habe mich wohl zu sehr auf G33 beschränkt, dass ich den darauffolgsen Befehl übersehen habe.
Aber komisch das das so aus Fusion gekommen ist.

Vielen Dank

Now we are among the hardware providers.
www.egerobotics.com

Sekai wrote:

I dont think i have a realtek ethernet
Its a intel i217LM and i have already the latest kernel e1000e

With Intel, be sure to set up the coalescing settings. Type man hm2_eth and follow the instructions

I dont think i have a realtek ethernet
 
Its a intel i217LM and i have already the latest kernel e1000e

having fun, haha

If you could do the motion via a handwheel rather than a direct mechanical connection,
you could probably use external offsets to accomplish this motion without disabling the
drive.

papagno-source wrote:

But I don't understand where to connect: pos_fb_out

Looks like from your hal it should be connected to pid.2.feedback You want the component to sit between the motor feedback and the pid

As far as the enable input, I wasn't sure. I thought it might be connected to a button on your GUI.

Another left field but more work idea would be to add a 100 ppr MPG wheel and manually jog the axis by hand. There are hale examples in the docs

 

for the isolcpus, where would it show up? (the histogram or the text version)
I'll have to look at what I did in the grub there, I thought I had it right for a change...
NOPE, I screwed it up, TYPO in the grub section on my part
M


All fixed now that I spelled it right.
I'll run some testing tomorrow to see if the error is still there, not currently hooked to a machine so I can run on the bench without much fear
Thanks again
M