Spindle sync: Error 41 #116
Comments
|
The
SPINDLE_PULSE is "wired" as a clock input to a timer - I have to check if it is possible to enable pullup for such an input.
Eventually yes - but the spindle sync code has to be verified first. I have recently switched to a F411 (from a MSP432) in my lathe - need some time in the workshop to run tests. |
|
I will try $SD and $SR later today.
It is definitely possible: |
Try with changing this line: Line 2086 in 0b4e6c2 to: GPIO_Init.Pull = GPIO_PULLUP;
|
|
This line in spindleGetData() function can stay as is: Line 1297 in 0b4e6c2 but in order to work last_pulse should be also reset here(just compare with iMXRT1062 driver): Line 1349 in 0b4e6c2 Also spindleDataReset() call still should be commented out in function spindle_on() Line 1109 in 0b4e6c2 Otherwise function spindleGetData() gets pulse_length as 0 and it is fails. |
A typo - I'll fix that.
I do not think so... It fails with error 41 if not? |
|
My lathe doesn't have spindle control. I set it manually to around 300 RPM - I can see it in RPM window in ioSender. It spins whole time. But when I run threading program generated by ioSender it throw Error:41 on G76 command. I will try investigate further. |
|
G4 didn't help. Also looks like P is in seconds, no milliseconds. RepRap.org says it should be P for milliseconds and S for seconds, ioSender doesn't know S parameter, it says "P is missing". Anyway what happens when G76 executes:
At this point pulse_length set to 0. Then(sorry, I don't want go step-by step trough whole sequence, I placed breakpoint into spindleGetData()):
And pulse_length is 0 at this point because it was previously set to 0 by spindleDataReset(). It returns 0 RPM and G76 fails with Error:41. Commenting out spindleDataReset() call in spindle_on() helps exactly with that - without this call pulse_length is valid. Obviously it isn't solution. It is quick and dirty temporary fix. G76 should not call spindle_on() I guess. Spindle should be on earlier by M3 command. |
RepRap is 3D printer frimware - all 3D printer firmware I've seen often divert from standard gcodes/parameters. G4 takes a P parameter in seconds according to section 3.5.4. grblHAL implements many linuxCNC extensions though - and I use their documentation as a reference, most of which is copied from more or less verbatim the NIST standard. G4 is documented here as well, Did you set $340 to a non null value (tolerance is in percent of RPM)? And use S300 in the gcode to match the actual spindle speed? |
This seems to work. Still don't understand why it works if spindleDataReset() commented out. Anyway, it works now. Could you add "Spindle Sync" into "Advanced" portion of Web Builder? I attached zipped driver.c - I made some minor changes by comparing it with other drivers. |
It does. However, if commanding spindle on and starting spindle synced motion immediately before it has had a chance to rotate enough to allow RPM to be calculated error 41 is returned. There is also a check for feed rate, which is dependent on the RPM, beeing less than the max Z rate configured (minus some headroom). Your best option to ensure that the spindle is running at the correct RPM is to set $340 to a reasonable value.
Yes, I'll do so when I am confident that it works as it should. |
You can make a tab "Experimental" with a big red warning "THIS FEATURES DOES NOT WELL TESTED. USE ON YOUR OWN RISK!". |
|
Now I have weird RPM values in ioSender. I using version built by Web Builder. This is the log: 3661293 / 1832 = 1998.52 Sounds about right - my encoder is 2000 PPR. Only two errors. But RPM definitely is wrong. |
|
I committed a fix last night but a misplaced space in the commit comment caused it to not show up here. |
|
Another question about sync: why is the timer used in external clock mode, not in encoder mode? It required two lines, but encoder mode is more robust: if noise is picked up by the direction line it is just ignored, if noise is picked up by the clock line it will count up on one edge and count down on another, as a result this noise will be cancelled out. Noise will affect counting only if noise is picked by both lines simultaneously. And Encoder mode also allows to check the rotation direction. |
I was not aware of that. Having had issues with interrupt driven quadrature encoder input before I assumed that the hardware implementations also would prefer relatively clean inputs. But then you are talking about a type of encoders that outputs a pulse and direction signal? The one you have is like that? Does it have differential outputs as well? |
This image from ST documentation show how jitter on one line affects counter:
Any quadrature encoder can be considered as pulse/dir output: |
|
I have to look into the use of timers as quadrature decoders later on. An issue might be that the timers capable of this is only 16 bit wide, they will quickly overflow with a 2000 PPR encoder. BTW I have now fixed a regression related to spindle sync and added a bit of documentation. |
|
Yes, I have looked at this a bit though not really done the software work at this point. But using the quadrature counters does rely on managing the overflow so this will limit the ultimate counting speed. From what I could gather from various STM32 examples and discussion rates up to about 5 MHz should be possible. That would be around 150K RPM with a 2000 PPR encoder so I think that ultimately the platform is capable of supporting this based on the above napkin calculations. But it is a big change in GRBLHAL from the existing implementation. |
Nice! However latest version doesn't work. Steps:
Firmware build using WebBuilder, BlackPill Alt. 2(STM32F411), biggest EEPROM setting, EEPROM is FRAM, and Spindle sync option enabled. Log for tunning option doesn't affect this behavior. If I try to run threading or test program using ioSender it just stuck on G33/G76 command, |
|
I figured it out: there some code is missing. EXTI4_IRQHandler() should be modified, this piece of code should be added(I copied it from EXTI3_IRQHandler): @terjeio could you commit it? |
Soon, I am currently reworking the IRQ handlers to support all possible pin assignments. |
When I tried to make a thread using ioSender, I got Error:41 on G76 command.
To make it work I have to do couple things:
Another thing I noticed: SPINDLE_INDEX pin is pulled up, but SPINDLE_PULSE is not. This does not sense for me. To use NPN(open drain) encoder both pins should be pulled up. I think external pull-up is preferable, but still make sense to configure both pins same way.
I use Nucleo-F401, BOARD_MORPHO_CNC and SPINDLE_SYNC_ENABLE.
Is there a plan to add SPINDLE_SYNC_ENABLE into Web Builder?
The text was updated successfully, but these errors were encountered: