Closed GoogleCodeExporter closed 8 years ago
Note that after several false starts, this turns out to be more complicated
than it seemed at first. There are several math operations that are currently
performed at 2x the width of the step and duration parameters. This means that
that if we extended duration and steps to 4 bytes (which the C18 compiler
supports) we would need to do 64 bit (8 byte) math which C18 does not support.
I need to check to see if XC8 supports 64 bit math, and if so try to convert
the code base over to XC8 (which I have tried in the past, but was not trivial)
to see if that might be an easy way forward.
Original comment by brian.schmalz
on 26 Apr 2014 at 11:18
Original comment by brian.schmalz
on 26 Apr 2014 at 11:18
OK, so 4 byte long values was actually too much work. So I went with 3 bytes
values. As of version 2.2.5, the <duration> and <Axis1> and <Asix2> values can
be up to 3 bytes each now. (<duration> is unsigned, <Axis1> and <Axis2> are
signed.) That still gives a maximum of about 4.7 hours for one move, with up to
8388607 steps per move.
I've also implemented checks to make sure that you don't try to have a step
rate that's too slow in either axis. The slowest that the EBB can do is 0.76Hz.
This (and the check for > 25Khz) are not _exact_, as the math isn't easy unless
we add in floating point support, which I'd rather not do. But it gets the job
done.
Original comment by brian.schmalz
on 30 Apr 2014 at 6:58
Original issue reported on code.google.com by
brian.schmalz
on 9 May 2011 at 9:53