hi *,

Am 26.02.19 um 18:25 schrieb Chris Radek:

> Have you considered the quadrature scheme, mode 2?  It has the same
> benefit of one edge per step, but does not have the drawbacks
> requiring consideration of setup and hold times (the dirsetup and
> dirhold parameters)
 this was exactly the hint I was searching for!

now it sends a packet with the quadratur-signal every
RT-tick. I hope so... ;-)

next day, I will check out, how stable the signal is.
what a can say now:

with the linux-tcpdump-timestamp it is not possible, to
read the correct packet-time, if the packets are running
in faster (or near) the RT-ticks.

with a stepgen.maxvel of 30 I get values, which seems to
be correct:


setp stepgen.0.maxvel 30
(distance between two  60byte packets)

Time      | last packet timediff
----------+----------------------------
55.713276 - 0.00005000
55.713350 - 0.00007400
55.713426 - 0.00007600
55.713475 - 0.00004900
55.713550 - 0.00007500
55.713625 - 0.00007500
55.713676 - 0.00005100
55.713750 - 0.00007400
55.713825 - 0.00007500


but a maxvel of 40 (which is the highest value
without an warning - see below) results in
impossible timestamps:
0.00000200sec == 2usec -

thats impossible -

setp stepgen.0.maxvel 40
(distance between two  60byte packets)

Time      | last packet timediff
----------+----------------------------
54.504630 - 0.00000200
54.504631 - 0.00000100
54.504632 - 0.00000100
54.504633 - 0.00000100
54.504635 - 0.00000200
54.504636 - 0.00000100
54.504637 - 0.00000100
54.504639 - 0.00000200
54.504640 - 0.00000100
54.504641 - 0.00000100
54.504643 - 0.00000200
54.504644 - 0.00000100
54.504645 - 0.00000100
54.504646 - 0.00000100
54.504647 - 0.00000100


STEPGEN: Channel 0: The requested maximum velocity of 45000 steps/sec is too 
high.


if I count the packets, I get 170848 packets in 10 seconds.
17000 pkt./sec ==> 0,000058824 sec./packet.

that sounds a little bit more realistic.

but it is less than the 40k packets, which should be possible
with a 25usec-thread.

why ?

regards
wicki










_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers

Reply via email to