Remora - Rpi Software Stepping Using External Microcontroller via SPI

I was going to hold off posting about this until I finished my router,
but it's not happening anytime soon. And I seemed to be just making
a good start and never finishes

Remora over ethernet!
streamable.com/9yu0a4
16th microstep on a TB6550 with a tiny motor.

Cncninja wrote:

Hey Scotta, could you look at the 4 axis mill files I posted I'm not having luck with it working I used the config app for the i/o and added the 4th to the existing but something seems to be missing.

Thank you

Hi, just having a look now. A few concerns though.

In you ini file:
1. [KINS] JOINTS = 4 and you have coordinates=XYZA, but the A axis has no joints associated
2. [AXIS_X] is defined twice. First with joint 0 and then with joint 3. Are you doing a 4 axis mill or a mill with dual X motors (4 joints) XXYZ? Your coordinates are XYZA. ie joint 0 -> x, joint 1 -> y, joint 2 -> z, joint 3 -> a

remora-xyz.hal:
Only joints 0 -> 2 are configured. You need to add your 4 joint.

You also seem to be missing a HAL file for your IO?

BR
Scott

mhel wrote:

I was going to hold off posting about this until I finished my router,
but it's not happening anytime soon. And I seemed to be just making
a good start and never finishes

Remora over ethernet!
streamable.com/9yu0a4
16th microstep on a TB6550 with a tiny motor.

Great work Rommel and thanks for sharing your efforts. Very inspirational. So much so I've got a W5500 ethernet module talking to and SKRv1.3 board. I need to dig into your code to see how you've implemented the comms routine now.

It seems to be some following error drift on "idle" motor in a x or y move though...? 

BTW, my STM32 based controller board (SKRv2) has arrived. Now the frustration of trying to get an Mbed based "hello world" program to load... I might have to blow away the bootloader first to at least confirm I've got the chip configuration correct before trying to add the complexity of a bootloader jump.

scotta wrote:

It seems to be some following error drift on "idle" motor in a x or y move though...? 

BTW, my STM32 based controller board (SKRv2) has arrived. Now the frustration of trying to get an Mbed based "hello world" program to load... I might have to blow away the bootloader first to at least confirm I've got the chip configuration correct before trying to add the complexity of a bootloader jump.

Thanks Scott, one is glad to reciprocate.

What do you think causes the drift,  large ferror?
I've been wondering about, why does the motor that's suppose to be idle
on a single axis move still has some motion on it. I'm kinda stuck actually.
Any idea what I should be looking out for?

Edit:
I was wrong about the single axis move, I just realize that the LinuxCNC splash is in italic...duh, viewing from the top.
That means you are talking about the rounding in corners on the video?
If so, that is fixed with tinkering with acceleration. I noticed that
the smaller value on acceleration causes the rounding.

I was wrong about the single axis move, I just realize that the LinuxCNC splash is in italic...duh, viewing from the top.
That means you are talking about the rounding in corners on the video?
If so, that is fixed with tinkering with acceleration. I noticed that
the smaller value on acceleration causes the rounding.

, you take care of the corner rounding with g61/g64 settings, im fairly sure hes talking about the x motor moving on what looks like y moves/vise versa (like with the letter E) but on closer inspection it looks like they are there are x and y moves supposed to happen as far as I can tell, and if the font is italic that would make sense somewhat

mhel wrote:

scotta wrote:

It seems to be some following error drift on "idle" motor in a x or y move though...? 

BTW, my STM32 based controller board (SKRv2) has arrived. Now the frustration of trying to get an Mbed based "hello world" program to load... I might have to blow away the bootloader first to at least confirm I've got the chip configuration correct before trying to add the complexity of a bootloader jump.

Thanks Scott, one is glad to reciprocate.

What do you think causes the drift,  large ferror?
I've been wondering about, why does the motor that's suppose to be idle
on a single axis move still has some motion on it. I'm kinda stuck actually.
Any idea what I should be looking out for?

Edit:
I was wrong about the single axis move, I just realize that the LinuxCNC splash is in italic...duh, viewing from the top.
That means you are talking about the rounding in corners on the video?
If so, that is fixed with tinkering with acceleration. I noticed that
the smaller value on acceleration causes the rounding.

Ahh, The italic font would explain it. Need to get an ST-LINK. I'm having no joy with the SKR2 board... frustrating.

Sorry guys I have you mixed up.
The text in the video is not italic but the text from the splash gcode of Axis is.
On the video there's a little movement on an idle axis on a single axis move but
i thought it was coming from acceleration because I can hear the motor whining
to a stop but it took time.
With the splash gcode "LinuxCNC" it was more pronounced and I was baffled
why, 'till I realized that the text is actually in italic.
So I guess there still is a problem with the single axis move.
BTW, the Y axis is along the readable text if it's not obvious from the video.

I got my stlink from a nucleo f446 ( which I somehow lost during a move )

mhel wrote:

Sorry guys I have you mixed up.
The text in the video is not italic but the text from the splash gcode of Axis is.
On the video there's a little movement on an idle axis on a single axis move but
i thought it was coming from acceleration because I can hear the motor whining
to a stop but it took time.
With the splash gcode "LinuxCNC" it was more pronounced and I was baffled
why, 'till I realized that the text is actually in italic.
So I guess there still is a problem with the single axis move.
BTW, the Y axis is along the readable text if it's not obvious from the video.

I got my stlink from a nucleo f446 ( which I somehow lost it during a move )

Hi Rommel, 

Try turning up the P gain on the LinuxCNC Remora component. This seems to fix it but does not explain the underlying error wind up. Any gurus here have any thoughts? Doug helped me iron out the original issues with the motion loop, similar to what the Mesa boards have due to the time delay between a read and write. Maybe we need more than and a P and FF1 control loop?

Thanks Scott,
That made a difference streamable.com/1u35vm

I was being conservative and made an increment of .25, I am at 3.0 gain and still nothing very noticeable is happening. I jacked it up to 5.0 and surely the effects becomes obvious. It's like it stiffens the axis. It probably requirem more tuning, but It's a progress

Setting the gain at 10.0 makes it even better, axis in motion really just stop no overshoot atleast as far as I can notice.
Now how would I know if I'm overdoing it?

looks like it's still coming to a slow wine
down stop