Direction setup - Used wrong or error in doc?

In docs ( linuxcnc.org/docs/html/config_stepconf.html ) it states that:
This is technically not correct.
If this is really how it is implemented in EMC2 then it is why it is causing step errors on my controller.
The correct use/description of a "setup time" is the time a signal has to be held before a trigger-signal is asserted.
Basically, for dir pin, it is the minimum time dir must remain stable before a step can occur or said in another way, the minimum time between dir change and step pulse rising flank. (Unless ofrcource step pulse is inverted, making it falling flank.)
This also means that if a dir change has not taken place, the only limit to when a new step can occur is the step space value.

The description of Direction hold is also thus wrong as a hold is always defined as the time a signal has to be held stable after a trigger-signal has been asserted. In this case the step is the trigger signal.

Can someone verify the actual implementation vs the doc and make sure it is correct?
If I set my parameters to the minimums of my hardware I loose steps. If I assume the timings are off by half a pulse and add to the timings it works fine.

Also, if someone could tell me if the hold time and setup times are calculated from rising flank (initial assertion) of the step It would help in understanding this.
(Following good documentation practice and general custom for hardware description it should be.)

Thanks!
It's clearly a logic flaw here, but not as I expected. The actual issue I was seeing seem to be related to timing jitter, however...
Looking at the handling at line 655-658 it seems to be in line with the docs, not the conventions of these names.

Here's a example:

(Nabbed from TI datasheet on DRV8811 and assumed to be fair use...)
The first thing one notices is that the hold time is related only to the time between last step pulse start and dir change. It is thus not an additive limit as in the code, but a question of which delay is larger, t-high or t-holdoff.
This only affects those running their drivers close to the limit as it will prevent emc2 from actually generating the shortest pulses specifically allowed by the user.

It seems the setup time is used correctly.

Based on this the docs should state that the dir pin is held during entire step pulse and the hold value is an option to add a extra hold.period after this.
The setup time also adds to the pulse it seems, although I am not sure I actually understand when a pulse is actually "over".

Hope the graph helps to illustrate my point.
I work with high frequency hardware (like memory and such) where this kind of distinction is very important.
The actual flank used as trigger is almost exclusively used as the timing reference for setup/delays and holdoffs.

setting any params to the minimum of hardware , is asking for trouble , due to timing inconsistancys in hardware and software outside of emc
control

True, but it was why I discovered it.
Also, why are we entering test information about realtime performance if emc2 is not utilizing it for safeguarding the timing?
It should not be users task to estimate his settings for safe operation of the hardware. This negates the point of even having the options.

Anyways, there is a discrepancy between how these values should be used (based on common definitions and recommended practice), and how they are infact used.

The benefit of my advice is a reduction in calculations.
There is no need to have the pulse time AND the hold-off time, when instead one just needs the bigger of the two.
The net result is less variables and calculations in a time-critical system.

I think you are assuming that all step drives measure the direction hold time from the leading edge of the step pulse, this is certainly _not_ true. The software step generator looks like it was written conservatively to accommodate any type of hardware, not just edge triggered devices that are triggered on the leading edge of the step pulse.

I do agree that the documentation could reflect the step generators timing more accurately.

I don't think the few nS taken by a few fixed point adds are significant.

I am not assuming. I am relying on standards and customs for good hardware design.
I'd like to see a controller with docs stating other type of timings though.

Any device using falling flank would be run by inverting the clock. No device uses the "on period" or "off period" as that is just sloppy design and timing can then not be reliably uphelt.
The reason why the standards are like this is simply to allow accurate definitions of the responsetimes for any drive/input. If the actual triggerpoint was a random place within a "on period" then it all falls apart.

Sure you are assuming, The writer of the stepgen software decided to be conservative and not assume that a leading edge of the step pulse was the timing reference. A trailing edge step is perfectly possible in a step drive, inverting the step pulse may not be possible because it would violate the off time specs. on and off time specs are often quite picky because Step drives try to get the most out of low cost OptoIsolators

Exactly!
Which is why one uses a single flank as a reference. The on and off times will always reliably specify the correct times.
The code in general utilizes this well, and it is only the actual timing references that obfuscate it.
I fail to see any situation where a single flank reference can not be used to accurately define the situation, whereas I don't see any situation where the current setup can in fact accurately define any.

Assuming "step time" is only the on-period of the pulse and step space is only the off-period, the "direction hold" will according to source be used to time the hold-off between a dir change and next step.
I will then have to assume that a new step starts with a on-period and that the off period is always just a minimum value. (Ether on or off will always have to be a minimum or a fixed frequency is defined.)
The "direction setup" is then defined as time between last step and a direction change. It does not specify if it is counted from start of on-period, or end of on-period. It can however not be based on the off-period as it can have infinite length.
The result is that it must be either rising or falling flank of the on-period. Thus, it would just reduce ambiguity if it was actually specified in the docs.

Again, I have never seen a controller that is not flank -based in it's timings as all rise and fall times are based on a flank starting the operation.

In my controllers case I can run 500 kHz step-rate maximum, with a on and off period of 1000 ns each as a minimum. Neither period have a maximum length.
Further, a important minimum setup time of 200 ns must be allowed between a dir-change and a step rising flank. This because the controller is rising-flank clocked.
Any controller with a inverted step input would trigger on falling flank, always. They can always be clocked by using inverted step pulse, meaning low is on. It will never violate any timing.
There is also a hold-time of 200ns to allow the dependant internal logic to propagate fully before the direction can be changed again. This is in essence a limit placed on the next step timer based on if a dir change has been done.
The decision to do a dir change can thus be done long before the scheduled next step, and if a change occurs, it can skew the step in time which is only natural since acelleration would need to begin slow anyways.
This appears to already be handled in the code, it is just the description that seems odd.

The limits entered by the user for minimum times should btw always be handled in such a way as to guarantee they are never breached. You may use longer delays ofcource, but a timer that fires too soon should and probably would never occur.
Therefore I really don't see the issue regarding timing and realtime/jitter. Since one period always has to be allowed infinite length, there will not be a issue regarding off-time for a inverted input either as it would be a on-time limit.

Oh and sorry, I see your ref now about short times,
I am used to my own microcontroller based cnc controller which does timing on the 100ns level, not 10000ns level.
With my current pc I see I can get a jitter of around 10000ns with my timings I then get a base period of 19000ns.

According to my scope I actually get pulses spaced from the dir-change at approx that value.
This is odd considering accelleration should never allow this, assuming double spacing should exist between slowest step in one dir, to first step in other dir. (Or velocity is doubled.)

I do actually see last step happen 38.2µs before dir-change, and then first step after change happens after another 19.1µs.
If those steps had both been in same direction that would have been a step frequency of 17452 Hz equating to a velocity of 818 mm/min (32"/min). Quite high considering my cnc max velocity is 1620 mm/min (63"/min) and accelleration curve should be present.

To notice this behaviour one has to set a very tight interval during motion-testing and leave running for a few seconds/minute. The interval then changes gradually and tightens into the minimum pulse based on system base period.

(Using a 2000ns on and off time minimum, with a 500 ns hold and setup gives me 3µs pulses which could, looking closer be a tad better shaped so I could increase timing a bit.
They are however nicely registered and I think they caused issues before being misshapened wiith shorter pulses.)