Advanced Search

thank you very much, I'll try it tomorrow, maybe the scale won't match because the input to the potentiometer is about 26vdc, but it's important that it works... maybe you can insert another potentiometer for jog override, i.e. jogging speed regulation, since this bosch wheel is not mpg, but the same potentiometer that they used, I assume, in the version with increments on the old controller, it's the same around 26vdc and could be attached  to analogin2?

Regarding Imperial vs Metric for accuracy.
Since Mr Johansson decide to use 25.4mm as the standard for 1 inch when producing his blocks, around the 1930's 16 countries started to use this as standard conversion, including the USA and UK. This was officially adopted world wide in the 1960s.
So basically an inch is defined as 25.4mm. Therefore it matters not whether one chooses metric or imperial to work with. As long as the machine is up to the task, ie in a state mechanically and to be pendantic tested and calibrated via a NIST certified testing facility you will get the required accuracy.
Another thing to consider whilst microstepping is great for smoothing movement it does not guarantee any linearality over a complete revolution. Another thing is the linearality of the lead screw it self, the stew itself may require mapping to help with commanded position and actual position reported by your scales.
Rolled ballscrews may not give the accuracy you are seeking.
So much to consider when aiming for um accuracy, without even thinking of thermal expansion of the cast iron vs lead screw material and all the boffin subjects.
But first port of call would be to assess the machine mechanically, check linearality and this should give you a baseline of what is realistic, then attempt progressive changes with much testing.
Your ideas do seem like a good starting point and only testing will confirm.

Thanks Tommy for picking up the slack in my less than ideal state of alertness.

One thing I would like the OP to confirm, is when using halcmd do you get proper comms with the board ? Just to confirm we aren't dealing with a hardware issue.

Once again I apologise for my lack of alertness.

I know that with the mesa 7c81 boards it is recommended to have a length of less than ~2.5" for the SPI cable length. So it just maybe the cable length is too long.
Dupont cables aren't ideal for SPI transmission at speed.
So ideas to try.
Ribbon cable with every second conductor a ground terminated at one end only, of course you will need a dedicated return ground. This may involved a custom bit of PCB at each end.
Shorter cable length for sure.
There's some other fixes I was going to suggest, but since the remora bards are "all in one" they would not apply.
But I guess a quality PSU, think Meanwell, might be worth considering.
My first port of call would be to reduce the SPI cable to the absolute minimum, preferably to under 2.5" max.
One thing of note is that I have the RPi5 can tolerate a longer SPI cable that the RPi4, the caveat being this is based on experience with a home made 7c81 clone.
I'm apologise if the references to the 7c81 is annoying, but it is entirely based on my experience with SPI as a communication medium. I honestly hope that some of the above suggestions will give you good for thought.

  I am sending you the corrected custom.hal file; I believe I had sent you one with some errors.

Hi all,I have a working Remora configuration running with Raspberry Pi (LinuxCNC 2.9), SKR 1.4 board (LPC1768), and SPI connection – but only using an old Remora component, because the recent ones do not support LPC1768 anymore (as Scott confirmed). The system works perfectly “on the bench” with just the boards and motors, but as soon as I connect it to my real machine, the SPI link becomes super unstable (“bad SPI payload / estop won’t reset” errors).Symptoms:

• Dupont wires or short IDC ribbon cable used for SPI (RPi CM4 → SKR1.4, <30cm).
• Works fine with just the controller and stepper drivers.
• The moment I connect “real loads” (motors, hotwire, power MOSFETs, or even touch the machine frame), SPI constantly fails.
• E-stop triggers, payload errors jump in LinuxCNC log.
• Even switching on the heater causes instant SPI dropouts.
• With ribbon cable it’s even worse (won’t leave estop).

What I tried:

• Multiple cables, power supplies, SD cards, re-flashing, common ground.
• SPI config is what works for old component – I can’t change SPI freq etc, I get “unknown command” if I try.
• System is totally stable on the bench, not with machine.

Limitations:

• New Remora components don't work – the SKR1.4/LPC1768 is legacy, so I must use the oldest one.
• This old Remora doesn’t let me change SPI speed, delay, etc.
• Hardware fix suggestions welcome, but software/firmware is stuck “as is” for now.

Has anyone solved this?

• Is it possible to get reliable SPI with legacy SKR1.4 + RPi, in a noisy CNC environment?
• Any proven hardware methods? (twisted pairs, shielded cable, ground, ferrites, extra pullups, RC on SPI lines…?)
• Is it possible to patch the Remora legacy component to allow lower SPI clock?
• Any old firmware/component version which allows SPI configuration and works with LPC1768?

Any advice would help – right now the setup works great “bare”, but physical machine (motors/heaters/vibrations) kills SPI instantly…Thanks!

Why would you be attempting to offer a LPT card in this instance ?

I tried what you suggested, it doesn’t work, it has erratic behavior. It performs poorly in 2.8, 2.94, and 2.97, it behaves erratically in all of them, I don’t understand what’s going on

Now it's morning time I'll have a look into this in a couple of hours.
Note to self, you're too old for late nights.

I don't have such a setup so it is very difficult to say.
But it sounds like the current position is lost, and when you go back to csp mode the current position is set to zero no matter how the spindle actually is rotated.
aDm1N had something about tracking position didn't he? Did you try that?

Thank you Hakan.

This was very helpful. With your cia402pv and the files from aDm1N, I managed to get the servo running with GCode Commands both for rotation and positioning.

Here are the things I had to change in the hal-file:
- net c-mode-request and2.3.in0 -> spindle-ok-for-c
- net spindle-speed-normal spindle.0.speed-out mux2.0.in0 -> spindle.0.speed-out-rps
- and of corse some names and scale values

Now to my problem:
As long as I only use G0 and G1, the servo positions correct (example: C0 is at 12 o'clock). Then I let it run with M3 S1000 and after a while I stop it using M5. Now the servo stops at its position. In my optinion it should move to 12 o'clock, if I use G0 C0. But nothing happens. If I type G0 C90, it moves 1/4 revolution. So it looks like if the stopping of the servo sets somehow the zero position? 

forum.linuxcnc.org/27-driver-boards/3889...7c81?start=20#195102

"out-inverter-1" should be: "pin-01-out-invert" (in the title)

Try setting pin-01-out-invert to 0 instead of 1.

Perhaps 1 is the default value.

Check all the HAL files in case the stuff in another file is messing stuff up.

video     That's what I did when I ran into the problem

Weird.

Try creating a new config with StepConf and look at the HAL file(s) it generates or look at the hal file(s) in an example config to make sure your syntax is correct.