Smart Pin Pulse Mode - Lags

Comments

• evanh Posts: 17,196

  2026-04-26 05:10 edited 2026-04-26 16:20

  Yes, a buffered command for pulse modes would solve it. No, none of the pulse modes have such buffering. I imagine Chip would gladly add command buffering in hindsight.

  Yes, a fresh pulse count, written to Y, is only actioned at beginning of next "base period" cycle. Metronomic base period cycles begin cycling at rising DIR control.

  PS: Base period value, in X[15:0], is reread upon each period cycle.

  I've re-edited a few times now for clarity.
• Christof Eb. Posts: 1,567

  2026-04-27 07:52

  So I tried to find out more.
  In this test I have set the ct1 time to 17cycles for each pulse group of 16 cycles. So there should always be a time lag of one cycle before the next group: As you can see, it is not!
  

  This is very strange, as the smart pin mode is reset and newly set each time:

  PRIMI(startPulses) { // ( x y pin -- ) starts smart mode pulses
          int pin= TOS; _drop();
          int y = TOS; _drop();
          int x= TOS; _drop();
          _pinclear(pin);
          _pinstart(pin,P_OE | P_PULSE, x, y); 
  }
  

  compiles to (pr0 is Top Of Stack, pr4 is stack pointer):

  04b50                 | __startPulses
  04b50     E0 D7 02 F6 |     mov arg01, pr0
  04b54     04 C8 87 F1 |     sub pr4, #4
  04b58     E4 C1 03 FB |     rdlong  pr0, pr4
  04b5c     E0 DD 02 F6 |     mov arg04, pr0
  04b60     04 C8 87 F1 |     sub pr4, #4
  04b64     E4 C1 03 FB |     rdlong  pr0, pr4
  04b68     E0 DB 02 F6 |     mov arg03, pr0
  04b6c     04 C8 87 F1 |     sub pr4, #4
  04b70     E4 C1 03 FB |     rdlong  pr0, pr4
  04b74     50 D6 62 FD |     fltl    arg01
  04b78     6B 01 08 FC |     wrpin   #0, arg01
  04b7c     40 D6 62 FD |     dirl    arg01
  04b80     6B 91 08 FC |     wrpin   #72, arg01
  04b84     6B DB 12 FC |     wxpin   arg03, arg01
  04b88     6B DD 22 FC |     wypin   arg04, arg01
  04b8c     41 D6 62 FD |     dirh    arg01
  04b90                 | __startPulses_ret
  04b90     2D 00 64 FD |     ret
  

  For me this looks like a silicone bug, as neither dirl nor wrpin #0 does realign the timing????
  Is such behaviour known?
  I am aware, that a short time lag after a pulse group can not be avoided, as we have no double buffering. But here we have sometimes a lag that is much longer.
  Is there a workaround?
  Cheers Christof
• ManAtWork Posts: 2,344

  2026-04-27 08:36 edited 2026-04-27 08:36

  There is an OBEX ebject for step/dir signal generation. There, I use NCO instead of pulse mode. I don't know why a fixed pulse-high time is used in so many pulse generators. IMHO it's much better to use 50/50 duty cycle. This way you can get rid of all the problems.

  • No need to decide what pulse width to set
  • works with all motor drivers, pulse width is high for low frequency and self-adapts if higher frequencies are required
  • direction signal setup time also self-adapts if you always change direction in the middle of the low-pulse phase
• Christof Eb. Posts: 1,567

  2026-04-27 14:53

  Ha! Finally found a workaround.
  The Transition Mode also does not reset it's base period counter, whatever you do. But it signals the IN signal directly after the last transition. So you can wait until IN is low and then setup newly during the time the output is low for the next group.

  
• Christof Eb. Posts: 1,567

  2026-04-27 15:23

  @ManAtWork said:
  There is an OBEX ebject for step/dir signal generation. There, I use NCO instead of pulse mode. I don't know why a fixed pulse-high time is used in so many pulse generators. IMHO it's much better to use 50/50 duty cycle. This way you can get rid of all the problems.

  • No need to decide what pulse width to set
  • works with all motor drivers, pulse width is high for low frequency and self-adapts if higher frequencies are required
  • direction signal setup time also self-adapts if you always change direction in the middle of the low-pulse phase

  Hi Nicolas, thank you very much. I have studied your driver. As far as I understand there is a loop running at 800 cycles.
  My method does at the moment only handle one axis at a time. On the plus side the Transitions Mode buys time to do the whole movement including ramp up and down within the same cog. Even in Forth. Seems to work up to 100kHz microstep frequency.
  Cheers Christof