servo-thread cycle strob
- arabel1a
- Offline
- New Member
-
Less
More
- Posts: 10
- Thank you received: 4
16 Sep 2022 17:59 #252093
by arabel1a
servo-thread cycle strob was created by arabel1a
Hi there !
I'm implementing sercos 2 protocol to linuxcnc. In brief: i made a (stm32 microcontroller + altera fpga) device for capturing and sending sercos messages to drives via optic fiber. It has strong realtime inside using hardware timers interrupt. The reason is that sercos transmission crashes on delay of ~10mks, and linuxcnc does not provide such latency. My device is connected to linuxcnc over raw ethernet ( i use common pci eth card in promisc. mode on PC side). Due to different realtimes, i had to use USERSPACE hal component to provide feedback to emc and commands to sercos.
Now it works fine, except one problem: sometimes axis starts jittering for no reason. It's not frequently, about one time for several seconds every several minutes. Jitter never happens when axis doesn't move. Jitter about +-20% of speed. I'm sure, that drives are configured correctly, I'm sure that there is no mechanical or electrical problems. If i replace real feedback from drives with simulated, jitter dissappears. After capturing come logs i've become almost sure that problem is so:
1. Due to different realtime clocks and non-realtime component, linuxcnc reads feedback from current cycle or from previous from time to time.
2. If emc get feedback from prevous cycle, it's speed setpoint is bigger, than you need irl.
3. Finally, when emc reads next cycle, if it reads position from CURRENT cycle (not prevous one), it finds that you need much less speed, than it really is. Command also is lower. This effect is repeated and amplified, and jitter happens.
I see two ways to solve this.
1. Make a basethread component that make a shift between linuxncn and sercos cycles equal to 1/2 of a cycle. Ethernet and userspace delays are less than cycle/4, so it looks good (if i'm right with reasons of problem). However, to implement this i need a strobe from servo-thread when it's cycle started. My questions are:
* Am i right, that base-thread and servo-thread are syncronized? I mean, is it true that servo-thread of 2ms cycle consists of exactly 40 base-thread of 50mks cycles. ?
* Inside one thread, is it true that modules get their pins at the start of a cycle and they don't see if it changes in this cycle?
* is there this strobe in basic components ? I didn't found that..
2. Syncronize linuxcnc's clock using my device's clock. I dont believe that this is real, but i shoud ask if there is an oppotunity to do that.
Sorry for my awful english : )
I'd be very thankfull for any advices.
I'm implementing sercos 2 protocol to linuxcnc. In brief: i made a (stm32 microcontroller + altera fpga) device for capturing and sending sercos messages to drives via optic fiber. It has strong realtime inside using hardware timers interrupt. The reason is that sercos transmission crashes on delay of ~10mks, and linuxcnc does not provide such latency. My device is connected to linuxcnc over raw ethernet ( i use common pci eth card in promisc. mode on PC side). Due to different realtimes, i had to use USERSPACE hal component to provide feedback to emc and commands to sercos.
Now it works fine, except one problem: sometimes axis starts jittering for no reason. It's not frequently, about one time for several seconds every several minutes. Jitter never happens when axis doesn't move. Jitter about +-20% of speed. I'm sure, that drives are configured correctly, I'm sure that there is no mechanical or electrical problems. If i replace real feedback from drives with simulated, jitter dissappears. After capturing come logs i've become almost sure that problem is so:
1. Due to different realtime clocks and non-realtime component, linuxcnc reads feedback from current cycle or from previous from time to time.
2. If emc get feedback from prevous cycle, it's speed setpoint is bigger, than you need irl.
3. Finally, when emc reads next cycle, if it reads position from CURRENT cycle (not prevous one), it finds that you need much less speed, than it really is. Command also is lower. This effect is repeated and amplified, and jitter happens.
I see two ways to solve this.
1. Make a basethread component that make a shift between linuxncn and sercos cycles equal to 1/2 of a cycle. Ethernet and userspace delays are less than cycle/4, so it looks good (if i'm right with reasons of problem). However, to implement this i need a strobe from servo-thread when it's cycle started. My questions are:
* Am i right, that base-thread and servo-thread are syncronized? I mean, is it true that servo-thread of 2ms cycle consists of exactly 40 base-thread of 50mks cycles. ?
* Inside one thread, is it true that modules get their pins at the start of a cycle and they don't see if it changes in this cycle?
* is there this strobe in basic components ? I didn't found that..
2. Syncronize linuxcnc's clock using my device's clock. I dont believe that this is real, but i shoud ask if there is an oppotunity to do that.
Sorry for my awful english : )
I'd be very thankfull for any advices.
The following user(s) said Thank You: tommylight
Please Log in or Create an account to join the conversation.
- andypugh
-
- Offline
- Moderator
-
Less
More
- Posts: 23170
- Thank you received: 4860
20 Sep 2022 11:41 #252391
by andypugh
Replied by andypugh on topic servo-thread cycle strob
I think that you should switch to a realtime HAL component. I don't think that there is any unsurmountable problem running a true hardware realtime device from a LinuxCNC realtime thread, most of the supported hardware interfaces do exactly that.
The trick is to use the read - process - write approach in the HAL realtime thread:
1) Read current status from the external hardware.
2) Calculate what the external hardware needs to be doing for the next servo cycle
3) Send appropriate commands.
And example of this is inside the software stepgen component, where the slow-thread function considers how many steps have _actually_ been sent to calculate the required step rate for the next servo cycle.
I wonder if it would be useful to have the STM32 run the Mesa Smart Serial protocol? This would potentially free up the ethernet port and allow easier integration of other types of hardware. Code already exists for smart-serial on STM32, it is the preferred interface for the STMBL servo drive:
github.com/rene-dev/stmbl/blob/master/src/comps/sserial.c
Yes, you are correct to believe that the slower threads are multiples of the faster threads: github.com/LinuxCNC/linuxcnc/blob/master/src/hal/hal.h#L705
The trick is to use the read - process - write approach in the HAL realtime thread:
1) Read current status from the external hardware.
2) Calculate what the external hardware needs to be doing for the next servo cycle
3) Send appropriate commands.
And example of this is inside the software stepgen component, where the slow-thread function considers how many steps have _actually_ been sent to calculate the required step rate for the next servo cycle.
I wonder if it would be useful to have the STM32 run the Mesa Smart Serial protocol? This would potentially free up the ethernet port and allow easier integration of other types of hardware. Code already exists for smart-serial on STM32, it is the preferred interface for the STMBL servo drive:
github.com/rene-dev/stmbl/blob/master/src/comps/sserial.c
Yes, you are correct to believe that the slower threads are multiples of the faster threads: github.com/LinuxCNC/linuxcnc/blob/master/src/hal/hal.h#L705
The following user(s) said Thank You: arabel1a
Please Log in or Create an account to join the conversation.
Time to create page: 0.123 seconds