Remora - Rpi Software Stepping Using External Microcontroller via SPI

muvideo wrote:

Hello
I'd like to use Remora as a pru for a bridgeport style milling machine.
I'm using a r-pi4 2gb and a btt skr 1.4
Motors are closed loop steppers, with a simple step+dir style command,
for pru and linuxcnc they appear as open-loop.
Before trying Remora I tried the basic hardware with marlin 2 on the skr and is working ok.
Now with remora I have 2 problems:

1- home switches:
I'd like to logically invert the signal coming from remora, but the option "Invert" for digital pin seem to have no effect.
I solved this using a "not" in hal but, anyway since it is in remora config I'd like to know if I'm making some mistake

2- what is step generator maximum step rate?
I'm having problems at rates higher than approx 18000-20000 steps per second.
I have 8000step per mm on Z axis, and the driver is happy up to about 140-150mm/min,
at higher speeds remora feedback start to lag behind the command significantly.
Is this normal? Maybe I'm doing somehing wrong, since marlin on the same hw
is able to go happily up to 1800mm/min (also if the machine is not happy to go that fast image missing /media/kunena/emoticons/dizzy.png

Hi, 

Thanks for trying Remora. 

1. There was a miss alignment  between the documentation and the Json config.txt parsing. I've pushed an update to the repo to correct this bug. DigitalPin invert now working with "True" vs "1". I've tested and working now so you can simplify your HAL once updated.

2. The Base Thread, which the step generator runs in, runs by default at 40khz. For a step on and off this takes two cycles so the fastest theoretically is 20khz. Below is a trace of both threads. There is some idle cpu time, but how fast do we need to go. On a typical 3D printer setup this is > 200mm sec.

At these higher speeds your setup needs to be done well to avoid following errors. ie stepgen acceleration set appropriately , joint velocity > max velocity so that the joint can actually make up any following error. Marlin and other firmwares don't monitor the actual step generation and just push out pulses. Remora does, so the configuration needs to be such to allow the control loop to do its job.  

Aaroncnc wrote:

I have started adding hal code clips into the remora docs.
remora-docs.readthedocs.io/en/latest/software/hal-examples.html

If you guys have any interesting or unique code in your hal if you could copy paste it here i can easily add it.
Would be nice if you could give it s short write up so a user can just copy paste the code and have a basic idea of why.

Thanks for contributing to the documentation. I need to pull my finger out and get the 3D printer stuff documented.

mhel wrote:

I hit a few snags.
1. My neighbour doesn't understand my obsession with this
2. I think I killed my X axis driver.

I finally made a crappy vid  Aircut  ( streamable.com/5yszzq )
Warning it's headache inducing, bandwidth consuming.
I think it's not bad for a bent X axis leadscrew with a .5" pitch, atleast I think I have the scale correct.
In any case it's just a proof that the controller works,  pretty stable too.

Oh and this jscut.org/ is a good start for a newbie it imports svg from inkscape .

@Scott  I bump the PRU_BASEFREQ to 200kHz just to see what happens, the video is the result.
But after re-run for a couple of times the x axis driver is dead.  I just realized that there's no configurable option to
change the step pulse width. The TB6600 I'm using apparently has a minimum pulse of 5 uSec probably more.

Hi Rommel, 

A typical base thread takes about 8us to execute. I settled on the 40khz frequency as most common drivers pulse width requirements are satisfied without needing any additional step parameters. The thread frequency could be pushed up some but the 200khz you have set could not be possible to meet and the thread interrupt would be ignored. I've had no need to push the frequency up as possible speed ~200mm/sec for a 3D printer setup is more than adequate.

BR
Scott

Thanks Scott, I'm just tinkering with settings just to see what breaks.
I'm back to playing with tiny motors for now, not very satisfactory
but it'll help keep moving with my little project.

BTW, I played with Mbed, not newbie friendly, I tried to make a blinky with mbed-cli but could never get pass the "keyerror", the porting instruction doesn't even mention how to generate the PinName header, but found out thru some post.
I'll try again next time need to read more.

 

Thank you Scott for your thorough reply, and many thanks also for this project.

• inversion: I still didnt update the firmware with the new content but tried to use 1 instead of "True" and indeed the inversion works correctly. 
• Steprate: ok so the maximum theoretical steprate Is coeherent with my experience, that's ok since I understand that your main target is 3D printers, the ability to use your project with a mill also very interesting. I lowered the steps per mm in the drivers configuration and lowered the maximum speeds and now the system is behaving Better. I still have to tinker with linuxcnc settings as I still have some overshoot problems.
• Feature request: it would be nice to be able to access board sd card trough USB as a generic disk storage. That would simplify initial configuration testings, for example for headless setups like mine, since I'm using vnc and the sd is not very accessible. The file would be accessibile directly trough os.
• Doc typo?: Is the period parameter in pwm component written as "Period" ? Since in the documentation Is reported as "Perioid". Maybe its a typo.

thanks!
Fabio

Sorry about the incorrect documentation.
I forgot that it was set as a bool value and not true false.

Thanks scott for updating the code.
i will have to update the config gen as i got it correct there and it sets a 1 and 0.

any misspelling is also my fault. my next update should fix them. should be able to get to it monday.