Advanced Search

You can use parallel port joint ini values, though you may be able to increase
the velocity and possible acceleration values due to the increased steprate
and step smoothness from the hardware step generator.

I do agree that pncconf should show the physical pin numbers in addition
to the stepgen/pwmgen/ etc numbers to avoid confusion.

Hi all,

[Introduction, skip this if you're in a hurry]

I have some experience with the TMC5160 and FluidNC, but I had issues trying to run them at higher velocities, at around 200mm/sec and with 1000mm/s² acceleration. The axis were noisy during ramp up/down; I have the feeling that it is related to the grbl step generation, as they run way smoother with the internal ramp generator. It is probably related to the fact that the velocity is updated at ~20khz in the TMC, and "only" at 100Hz by default in FluidNC.

I also tried, with my very limited coding knowledge, to run them in full SPI mode with FluidNC. It was let's say "sort of moving", but I didn't find a way to make it reliable. One of the problem I encountered was that the internal clock has quite a big tolerance (+-3%) and it became hard to synchronize the axis as they weren't always exactly where they were suppose to be. Coding of some kind of feedback to compensate was too challenging for me.

Then I looked for other solution and I came across Linuxcnc and decided to give it a try.

[End of the introduction]

I started a couple of days ago, and I'm learning and progressing slowly. My configuration is a PI400, connected directly to the TMC via SPI. Just one for now, but the plan is to "daisy-chain" as much as needed, remembering that more drives means more cable, meaning slower SPI speed and longer read/write time. To get an idea, 5 drives serial connected would need 2x5x40bits for reading (reading needs 2 cycle) and 2x5x40bits for writing (1 for direction, 1 for speed), so @2MHz SPI speed that would be at least 0.4ms just for the communication. I have no experience with LCNC and don't know if the servo thread can still be configured at 1ms with this. I guess I'll find out later.

For the code, as I already wrote, I'm more a copy/paster than a coder. And it works perfectly in this case, as nearly all I need have been done before. I use following projects as reference:

-Remora-spi: uses LCNC data to send velocity command to a slave device over SPI. Sounds like a perfect match!
-TMC libraries: there is the Trinamic-library written in C and the TMCStepper library in cpp which is more complete. I'm picking information in the second to adjust the first one.
-FluidNC: the source code is a good example about how and what to configure in the drives, with also a good basis for the daisy-chain code. I already spent hours on this, that's why I'm using it, but you can also take a 3D printer firmware, as most of them support TMC drives.

So far I'm just able to move 1 axis back and forth, without any feedback; just a joint vel-cmd sent to the drive. It works as expected, meaning with a position error of 1 or 2%. Next step will be to close the loop with a position PID (position feedback is the step count in the TMC drive). Then I'll have to test with 2 drives, add error management, determine the variable that will be in the INI file and finally clean up the mess code. It will probably take me months to have something usable, but as far as I can see, this topic is not the most active on the forum, so I don't have much pressure!

Here are a few question that maybe someone can help me to answer:

1. The Remora component includes a PID-Loop, but there is also a PID component in LCNC; which option makes more sense: integrate one in the comp or use the standard one?
2. The TMC have a poor on-board reference clock with accuracy of +-3% according to datasheet. Would it be a good idea to calculate the speed based on two readings and thread time and make a velocity correction with the data? I have the feeling that without it the position loop will unnecessary oscillate all the time, as the commanded velocity is always off. I'd see something like a "permanent" correction of the internal clock; by permanent I think about something like an auto adjusting FF0 variable that initialize at 1 when LCNC is started and the corrects itself if the velocity error is bigger than, let's say 0.1% or so.
3. In full SPI mode, the Step/Dir inputs become REFL/REFR. I didn't make any search so far, but can someone tell me how hard it would be to use the TMC capability to latch a position on REFL/REFR input to home an axis? I guess it will require a custom Home comp? And could this new comp call a function in my TMC5160 comp, for example a read_Xlatch() that would write the latched position in a HAL variable? Everything is so new to me and there is so much to learn...

Thanks in advance!

Now facing an error when starting this config in LinuxCNC - any idea ?

Error:
Print file information:
RUN_IN_PLACE=no
LINUXCNC_DIR=
LINUXCNC_BIN_DIR=/usr/bin
LINUXCNC_TCL_DIR=/usr/lib/tcltk/linuxcnc
LINUXCNC_SCRIPT_DIR=
LINUXCNC_RTLIB_DIR=/usr/lib/linuxcnc/modules
LINUXCNC_CONFIG_DIR=
LINUXCNC_LANG_DIR=/usr/lib/tcltk/linuxcnc/msgs
INIVAR=inivar
HALCMD=halcmd
LINUXCNC_EMCSH=/usr/bin/wish8.6
LINUXCNC - 2.9.3
Machine configuration directory is '/home/hwe/linuxcnc/configs/by_interface.mesa.hm2-stepper'
Machine configuration file is '7i92M_hwe.ini'
INIFILE=/home/hwe/linuxcnc/configs/by_interface.mesa.hm2-stepper/7i92M_hwe.ini
VERSION=1.1
PARAMETER_FILE=hm2-stepper.var
TPMOD=
HOMEMOD=
TASK=milltask
HALUI=
DISPLAY=axis
COORDINATES=X Y Z
KINEMATICS=trivkins
Starting LinuxCNC...
Starting LinuxCNC server program: linuxcncsvr
Loading Real Time OS, RTAPI, and HAL_LIB modules
Starting LinuxCNC IO program: io
libnml/buffer/shmem.cc 320: Shared memory buffers toolCmd and toolCmd may conflict. (key=1004(0x3EC))
libnml/buffer/shmem.cc 320: Shared memory buffers toolSts and toolSts may conflict. (key=1005(0x3ED))
libnml/buffer/shmem.cc 320: Shared memory buffers emcError and emcError may conflict. (key=1003(0x3EB))
linuxcnc TPMOD=tpmod HOMEMOD=homemod EMCMOT=motmod
Found file(REL): ./hm2-stepper.hal
Shutting down and cleaning up LinuxCNC...
hm2: loading Mesa HostMot2 driver version 0.15
hm2_7i90: loading HostMot2 Mesa 7i90 driver version 0.3
hm2: unloading
Removing HAL_LIB, RTAPI, and Real Time OS modules
Removing NML shared memory segments

Debug file information:
Note: Using POSIX realtime
Linux parallel port 0 not found
hm2_7i90: rtapi_app_main: No such file or directory (-2)
./hm2-stepper.hal:38: waitpid failed /usr/bin/rtapi_app hm2_7i90
./hm2-stepper.hal:38: /usr/bin/rtapi_app exited without becoming ready
./hm2-stepper.hal:38: insmod for hm2_7i90 failed, returned -1
6020
Stopping realtime threads
Unloading hal components
Note: Using POSIX realtime

I do have another question.
I found old parallel-port config files and want to extract the stepper scales and parameters for the 3 axis.

For which parameters do I have to search in this old config files ?
Is it in the *.ini or in the *.hal file ?

I find this:
[AXIS_0]
TYPE = LINEAR
HOME = 0.0
MAX_VELOCITY = 20.0
MAX_ACCELERATION = 30.0
STEPGEN_MAXACCEL = 37.5
SCALE = 228.571428571
FERROR = 1
MIN_FERROR = .25
MIN_LIMIT = -500.0
MAX_LIMIT = 500.0
HOME_OFFSET = 0.0

[AXIS_1]
TYPE = LINEAR
HOME = 0.0
MAX_VELOCITY = 20.0
MAX_ACCELERATION = 10.0
STEPGEN_MAXACCEL = 12.5
SCALE = 228.571428571
FERROR = 1
MIN_FERROR = .25
MIN_LIMIT = -500.0
MAX_LIMIT = 500.0
HOME_OFFSET = 0.0

[AXIS_2]
TYPE = LINEAR
HOME = 0.0
MAX_VELOCITY = 20.0
MAX_ACCELERATION = 10.0
STEPGEN_MAXACCEL = 12.5
SCALE = 355.555555556
FERROR = 1
MIN_FERROR = .25
MIN_LIMIT = -100.0
MAX_LIMIT = 100.0
HOME_OFFSET = 0.0