This means there's no need to filter out the skeletons from the manpage
list in the docs/src/Submakefile any more.
Signed-off-by: Sebastian Kuzminsky <seb@highlab.com>
.. for uspace systems with /dev/spidev. This is mildly tested on odroid
u3 with a 7i43 custom firmware and with a real 7i90.
Note that on many systems out there, including odroid, /dev/spidev is lousy
for realtime performance. Some kernel-side changes, available at
https://github.com/jepler/odroid-linux.git in branch odroid-3.8.13-rt
give good performance on my odroid u3 system.
Signed-off-by: Jeff Epler <jepler@unpythonic.net>
This removes mention of the pet_watchdog function from all docs, and
updates some out-of-date information about the watchdog.
But we still export the pet_watchdog function to HAL, for now. It does
nothing but complain about its own obsolescence, watchdog-petting happens
in hm2's write function now. We should remove pet_watchdog before 2.7.
Signed-off-by: Sebastian Kuzminsky <seb@highlab.com>
* Don't require specification of MAC address at all. Instead,
request the hardware address from the attached hostmot2 ethernet
board. (of all the ways to get the MAC address automatically,
this seemed like the best one. Alternate ways involved parsing
/proc/net/arp; or using SIOCGARP which requires correctly filling
in the interface name that the hostmot2 card is connected to, and
also still requires sending a packet to the board)
* When SIOCSARP (set arp entry) fails, report it; this will happen if
you did not "sudo make setuid".
* When an ARP entry was successfully pinned in init_net, delete it
in close_net with SIOCDARP.
This is almost entirely a copy of the 7i43 driver, with a few tiny tweaks.
Should be integrated with the 7i43 driver so they share more code,
but that can happen in the master branch later.
The hm2 driver exports pins called "hm2_BLAH.X.encoder.YY.rawcounts",
but the manpage incorrectly called them ".rawcount". Fix the manpage
to match the existing pin name.
The recent addition of support for table mode to the Hostmot2 stepgen had an unfortunate
and unintended consequence. Some of the existing bitfiles did have wide stepgens included
but this was masked by the driver. Users that have configured these stepgen pins as GPIO
are likely to find that important parts of their machines no longer work.
This patch adds an extra parameter to the hm2 modparams so that system builders
have to actively choose to use the wide stepgens.
Signed-off-by: andy pugh <andy@bodgesoc.org>
ver. 1.0.2
- solved a spindle button issue and included a check so it
is no possible to exceed the limits of the spindle with
override values. i.e. a spindle has a max of 6000 rpm and
the user enters S 5500 M3 now he can increase the spindle
override, but it will be limited by 109 %, because otherwise
he would ask the spindle to run faster than allowed.
This only works for firmwares that offer that facility for more than 2 pins
(which I do not think is any of the ones in the wild)
Signed-off-by: Andy Pugh <andy@bodgesoc.org>
If no format length was specified then the formatting would break for any value with a zero in its representation.
Signed-off-by: Andy Pugh <andy@bodgesoc.org>
Fix some bugs in the lcd component
Signed-off-by: Andy Pugh <andy@bodgesoc.org>
Update the manpage to show that the ioaddr and ioaddr_hi arguments
(and the others) all take arrays, not single scalars.
Thanks to Peter Wallace for the bug report.
when motion creates the base and servo thread,
the base thread doesn't support floating point.
When using brushless DC motors, it is desireable
to run the bldc component faster than the servo
thread, but it needs FP. Added an module parameter
to motion that tells it to create a floating point
capable base thread. Default behavior is the same
as before, so change is transparent.
We run mandb to index all our manpages. mandb complains about every
non-manpage file it finds in the man directory tree. This includes our
.gitignore files.
This commit collects all the .gitignore info into the .gitignore file
in docs/man, just outside of where mandb starts paying attention and
complaining.
The kernel API call used by matrix_kb may not be realtime-safe. It is not easy to tell
but at least one call that jepler found looks suspicious. This commit removes any attempt
to create keystroke events from the component.
There may be a userspace component to do the job in time.
by default (motion.ferror-mode == 0), ferror is computed based on the
last commanded position, which is problematic with velocity-mode drives
if motion.ferror-mode == 1, ferror is calculated based on the new commanded
position, and following error checks are postponed until after the new
commanded position is calculated.
see also: http://www.linuxcnc.org/index.php/english/forum/search?q=servo+tuning+advice&childforums=1
This one goes up to quadruple clicks. I find it useful for overloading
the functionality of the hard buttons on the control panel of my mill.
For example, in my config, multi-clicks on the Z+ jog button are detected
and routed to halui, where they trigger MDI commands:
Double-clicking runs "quill up".
Triple-clicking runs my "present work" subroutine: quill up and
bring the table to the front and center for operator access.
Quadruple-clicking runs my "stow" subroutine: quill up and bring
the table to the back and center for out-of-the way storage at
the end of the night.
A debounce component may be advisable between the input signal and the
multiclick component.
Before this commit, the watchdog used to run all the time, starting when
the llio driver was loaded. Since it can take a while between loading
the driver and running pet_watchdog() the first time, the watchdog needed
a stupidly long timeout (1 second by default).
This commit changes the watchdog to be asleep when the llio driver loads,
and be woken up the first time you access the board by calling any of the
hm2 read(), write(), or pet_watchdog() functions in HAL. Once you wake
the watchdog up you need to keep petting it (by calling pet_watchdog())
or it will bite, just like before.
This lets us decrease the default watchdog timeout to something much
shorter, just a few times the expected servo period. I chose 5 ms
as the default, but just like before you can change it by setting the
watchdog.timeout_ns parameter any time you want.
Thanks to Jeff Epler for suggesting this improvement.
0: rotate clockwise or counterclockwise for smallest angular movement
1: always rotate clockwise
2: always rotate counterclockwise
Adapt interpretation of the ORIEN_SPINDLE second parameter.
Add range check in interp_check.cc
Adapt regression test output.
Adapt docs.
The 1034gecko.ini file was accidentally added in both 2.4 and master.
The version in the 2.4 branch then got modified by subsequent commits,
but the version in master didn't. The 2.4 branch was merged into 2.5,
and this commit merges 2.5 into master, causing a conflict with the
1034gecko.ini. I resolved the conflict by consulting with the author,
Matt Shaver, and the current setup is what he wants (for now, more
commits coming, i think).
Conflicts:
configs/smithy/1034gecko.ini
One problem frequently identified with pid is that the D term is
excessively noisy due to quantization (particularly of feedback position).
Introduce command-deriv and feedback-deriv pins. These can be connected
to some (hopefully superior) source of the derivative. For example, a
system with an analog tach signal in hal could use that value for
feedback-deriv. It also becomes easier to test different derivative
computation functions, such as explicit smoothing of the D term or
the five-point method mentioned on wikipedia
http://en.wikipedia.org/wiki/Numerical_differentiation#Higher_order_methods
Zero, one, or both of the -deriv pins may be connected. When a -deriv
pin is not connected, the related value input is computed by the
traditional two-point difference method. This means that when neither
pin is connected the behavior is the same as before (except for rounding
differences).
The watchdog component can monitor several inputs for "heartbeats", with
independent tiemouts per input. This may be used in connjunction with
e.g. charge-pump to provide a heartbeat to the outside world.
This commit fixes SF#2985881 "stepgen bug in hostmot2".
This commit changes the hm2 stepgen.enable behavior. When .enable is
true it behaves like before, but now when .enable is False it behaves
like this instead:
No steps are generated (if the stepgen was moving at the time enable
went false it stops immediately, without obeying the maxaccel limit).
.velocity-fb goes immediately to 0.
This makes it so that when .enable later becomes true again, no abrupt
motion takes place.
[This is a combination of the following two commits from master:
da68626 Don't change hm2 stepgen position when .enable is low
1f75173 Fix hm2 stepgen.enable=0 behavior
-- jepler]
This commit makes the hm2 stepgen *not* change its .counts and
.position-fb pins when .enable is low.
When emc2 disables a stepgen (for example when the user hits E-stop,
or when the joint ferrors), it copies the joint's position-fb to its
position-cmd, to avoid abrupt motion when the joint is enabled again.
Therefore my previous commit, which made the stepgen count and position-fb
track the position-cmd from emc2, was redundant and potentially risky.
Thanks to Jeff Epler for setting me straight on this.
This commit fixes SF#2985881 "stepgen bug in hostmot2".
This commit changes the hm2 stepgen.enable behavior. When .enable is
true it behaves like before, but now when .enable is False it behaves
like this instead:
No steps are generated (if the stepgen was moving at the time enable
went false it stops immediately, without obeying the maxaccel limit).
.position-fb starts tracking .position-cmd, and .counts changes to
match (even though no motion is taking place).
.velocity-fb goes immediately to 0.
This makes it so that when .enable later becomes true again, no abrupt
motion takes place.
Slavko Kocjancic wanted a custom step type for his homemade stepper
driver. This adds a (single) customizable step waveform. These
waveforms have the same limitations as the existing ones: up to 5 output
phases, and up to 10 steps per cycle.
revolutions per second is more sensible, because it lets the scale
(e.g., of a stepgen being used in velocity mode) be 1 = 1 revolution,
rather than 1 = 1/60 revolution
* made encoder velocity timeout a hal parameter
* removed the stepgen.velocity-cmd pin
* made stepgen.velocity-fb show requested (not estimated) speed
* update manpage and TODO file to reflect reality
* misc minor cleanups & updates
Only configs that monkey with the GPIOs are affected (that's you, cradek);
all other configs will work without change.
Before this, GPIOs had names like "hm2_5i22.0.gpio.P5.095", with
the connector name and the IO number. Now, GPIOs have names like
"hm2_5i22.0.gpio.095" (ie, without the connector name, with just the
IO number).
The mapping between IO number and (connector and pin-on-that-connector)
is shown at driver load-time (even without messing with the debug level!),
and it's also printed in Mesa's Anything I/O board manuals.
