- Posts: 109
- Thank you received: 2
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
SPI comms runs at the Servo Thread frequency and it passes the required step frequency. All steps are generated in the Base Thread, which is the limiting factor.Most 3D printer board manufacturers don’t use the right pin mapping of the chip. The chip is using software pwm to generate steps if the pin is not hardware pwm. I’m trying to use P2.0 to P2.5 for step generation with good results.
The step generation limitation could come from the SPI communication too slow maybe.
Please Log in or Create an account to join the conversation.
Hi,
well let's do it, what do you have so far and where can i add to it?
I've uploaded my non-PRU version.
github.com/mhelmarc/Jaqueza-NC
Same issue, I can't figure out yet.
When coming from e-stop on first run
it goes idle but it works the on the second press of e-stop.
My observation is:
On first run after pressing the e-stop button on Axis, only the header PRU_READ
is sent and no payload. The controller assumes that there's data so it set SPIdata to true.
So the main loop try to change the state to ST_RUNNING, but there's actually no data
and becomes a sequence of errors so it goes idle again.
Still trying to figure out how to fix it, but other than that it seems stable.
Please Log in or Create an account to join the conversation.
Hi Scott,
what makes this a non-PRU version?
Please Log in or Create an account to join the conversation.