Advanced Search

Still an issue during start of my config.
I assume my 7i92M has the IP "192.168.1.121" bacause I can ping it.
I configured the laptop ETH-port to "192.168.1.1" with netmask "255.255.255.0", but I receive this:

Found file(REL): ./HWE_LinuxCNC.hal
Shutting down and cleaning up LinuxCNC...
Running HAL shutdown script
hm2: loading Mesa HostMot2 driver version 0.15
hm2_eth: loading Mesa AnyIO HostMot2 ethernet driver version 0.2
hm2_eth: ERROR: Could not retrieve hardware address (MAC) of 192.168.121: Resource temporarily unavailable
hm2: unloading
Removing HAL_LIB, RTAPI, and Real Time OS modules
Removing NML shared memory segments

Debug file information:
Note: Using POSIX realtime
hm2_eth: rtapi_app_main: Resource temporarily unavailable (-11)
./HWE_LinuxCNC.hal:10: waitpid failed /usr/bin/rtapi_app hm2_eth
./HWE_LinuxCNC.hal:10: /usr/bin/rtapi_app exited without becoming ready
./HWE_LinuxCNC.hal:10: insmod for hm2_eth failed, returned -1
7985
Stopping realtime threads
Unloading hal components
Note: Using POSIX realtime


Any idea ?

ERROR FOUND:  Typo in IP !
 

A, crap - yes wrong file ...

hm2_7i90: loading HostMot2 Mesa 7i90 driver version 0.3

Look's like you selected 7i90HD instead of 7I92 in pncconf

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
 

Hi, you cannot use ST-Link utility to flash the RT1052. You will need to use pyOCD with an ST-link (probably need to flash the CMSIS-DAP firmware).

github.com/scottalford75/Remora-RT1052/tree/main/CMSIS-DAP

in that case you would want to utilize a different subroutine, there are several good ones out there, if you liked the one from qtdragon you can see if it was a subroutine, or check with the router guys, they use some good methods that would be more akin to your requirements

I did as you recommended, but in the PnPconfig under the "P2" configuration tab I can select for Pin0: "X-Achse StepGen"  assuming this is creates the stepper pulses - but how can I select the "DIR" function for Pin14 ???

Do I need to set "Anzahl der Schrittmotoren" (number of stepper motors)  to 0 as well ? 
Since I am using L297 drivers.

[Edit:]  OMG, no I understand the pinout display when selecting 3 stepper motors in the config.  This is really not easy to read, when selecting the stepper: the "0" covers 2 pins (IO0 and IO1) with ( I  assume since it is not explicitly given) the IO0-pin connected to X-Dir (when selecting X-axis) and IO1-pin connected to X-Step.

I took a while until I understood it.




 

The default 7I92 firmware is 7i92_7i76x2D.bit, and that matches your pinout

You should be able to to use pncconf with "7i92-Internal Data" and
"7i76x2 with one 7i76"  Then disable the sserial ports and encoder
(If you don't use one) and unused stepgens to regain control of
their GPIO pins
 

The network drivers are not real time so delays can ocurr when syncing with a real time thread. Telling the network drivers to use the same core as the Linuxcnc real time core (3 in this case) using CPU affinity, is a well established work around for this by those in the RT community but relatively new to Linuxcnc.

Also don't forget to disable energy efficient Ethernet.

Hi,
I had the setup running before I reinstalled my laptop with the latest LinuxCNC version - stupid me didn't backup the "ini" file for LinuxCNC and I need help to recreate it.

I do have a 7i92M (IP 10.10.10.10) and use a self-made stepper driver board at the P2 connector, with the following connections:
Parallelport-Pin / IO-7i92M / Function:
1 / IO-0 / X-DIR
14 / IO-1 / X-Step
2 / IO-2 / Y-DIR
13 / IO-3 / Y-Step
3 / IO-4 / Z-Dir
16 / IO-5 / Z-Step     

I ran LinuxCNC-PnPConfig, but did not find any proper board/setup, that allows me to select this particular connection/config.

I remember previously it was straightforward to configure the individual pins for a 7i92M board - now I am struggling.
I am not sure which firmware is on the 7i92M board - but I assume it is the default, since I did not change it.

Any help is appreciated !
Thx

[Edit:] I found my previous discussion on the same topic in this forum from 3 years ago, but it does not help me much, since I cannot select and assign DIR/Step signals to 7i92M pins:   forum.linuxcnc.org/39-pncconf/43847-7i92...and-pncconf?start=10

 

Building Linuxcnc on any hardware platforen is not difficult. I did a video of how to do it.


The  hard bit is to build  the PREEMPT_RT real time kernel as generally, there are no pre-built Debs for it. Using the 6.1.12 kernel and above will avoid the need to apply the RT patch to kernel source. This might help.

In my experience pushing open loop steppers to extremes, they only loose steps when they get hot which can take some time when operating. At this point your drives may be unable to compensate for position based on the encoder feedback due to lack of torque.
There are many variable to consider if this happens,