In the past, the apt resolver automatically uninstalled the gpl3
readline (libreadline-dev, libreadline6-dev) as needed to satisfy
the dependencies of linuxcnc-build-deps. At some point around
2017-02-10, this changed on travis-ci.org and instead it preferred
to remove linuxcnc-build-deps and leave a bunch of deps (such as
libudev-dev, the first one configure hit) in a non-usable state.
Work around this by manually removing the packages that seem to be
causing the problems.
Signed-off-by: Jeff Epler <jepler@unpythonic.net>
Expand error message to show bogus variance value.
Using a mis-configured (non-realtime?) kernel resulted
in error message that occurs for unrealistic negative variance
calculation.
Signed-off-by: Dewey Garrett <dgarrett@panix.com>
Travis CI is not the equal of buildbot (it can't run RT kernels and
can only test building on Ubuntu with amd64) but adopting it *in
addition to* buildbot would let us do things like automatically
build-test pull requests on github without developer interference
(i.e., by pushing a temporary branch to glo)
Closes#137.
Signed-off-by: Jeff Epler <jepler@unpythonic.net>
Provide the LinuxCNC version number in the new, rebranded environment
variable name (LINUXCNCVERSION), while still keeping the old un-rebranded
variable (EMC2VERSION) around until 2.7+1.
Signed-off-by: Sebastian Kuzminsky <seb@highlab.com>
RTAI 5 (which has not been released yet) introduces changes (possibly
unintentional) to the API. This commit updates rtapi to use the
current API.
Signed-off-by: Sebastian Kuzminsky <seb@highlab.com>
The rtai_shm module went away before our Hardy RTAI, so this check has
been broken for years. rtai_sched now provides the shm device file.
Signed-off-by: Sebastian Kuzminsky <seb@highlab.com>
The rtai_shm module went away sometime before our Hardy RTAI, so stop
looking for it. The rtai_sched module creates the shm device file now.
Signed-off-by: Sebastian Kuzminsky <seb@highlab.com>
This is intended to fix a race that causes occasional test failures in
the buildbot, such as this one:
http://buildbot.linuxcnc.org/buildbot-admin/builders/1502.rip-jessie-amd64/builds/161
Note that runtests ran the test called "edge/falling", which passed,
and then ran the next test, "edge/rising-starting-high", which failed,
complaining "halrun: Realtime already running."
Some background:
* Both tests are of the "test.hal" type, which get run by halrun.
* halrun first runs "realtime status" and quits if the status is True,
as it was in this failure.
* If the realtime status is False, as it normally is, halrun runs
"realtime start", then "halcmd test.hal", then "halcmd stop",
"halcmd unload all", and finally "realtime stop".
* On uspace, "realtime status" checks for the existence of a running
"rtapi_app" process.
* On uspace, "realtime stop" runs "rtapi_app exit".
The theory of this failure is this:
The "edge/falling" test finished, its halrun ran "realtime stop" which
ran "rtapi_app exit" which caused any and all rtapi_app processes to
kill themselves. But init (or whoever was the parent of rtapi_app)
had not yet gotten around to reaping the dead process, so it was still
around, in Zombie state. The "edge/rising-starting-high" test started
up, and its halrun ran "realtime status", which now returned True because
it saw the zombie rtapi_app, and the test failed.
I can replicate this failure 100% of the time by stopping init (who's the
father of the "master" rtapi_app) using "sudo gdb /sbin/init -p 1" before
the "edge/falling" test finishes, causing rtapi_app to remain a zombie.
This current commit was proposed by Jeff Epler. It does not address the
underlying race, but gives init 5 additional seconds to reap the zombie
before giving up, thus making the failure much less likely.
I have a lovely solution to the underlying race, but unfortunately
there's not enough room in this commit message to write it down.
Signed-off-by: Sebastian Kuzminsky <seb@highlab.com>
Debian Jessie uses RTAI 5.0, which requires some tweaks to LinuxCNC to
work right.
This branch of LinuxCNC does not have those tweaks, so this commit teaches
the platform-is-supported script not to try to build this branch under
Jessie/RTAI on the buildbot.
Signed-off-by: Sebastian Kuzminsky <seb@highlab.com>
also for rip-environment.in
Provide an environmental variable for guis so that expected
gcode libraries can be found without in-gui methods.
Note, the naming legacy is very different for RIP and DEB
DEB: /usr/share/linuxcnc/ncfiles/
RIP the_git_top/nc_files/
^^^^^^^^
Signed-off-by: Dewey Garrett <dgarrett@panix.com>
linuxcnc.in was updated to remove EMC2VERSION and add LINUXCNCVERSION
and rip-environment.in needs to have LINUXCNCVERSION for scripts
that might test for it (to help determine rip or deb for instance)
note: retaining EMC2VERSION here to ensure compatibilty with any
forlorn apps that might use it.
Signed-off-by: Dewey Garrett <dgarrett@panix.com>
This is intended to fix a race that causes occasional test failures in
the buildbot, such as this one:
http://buildbot.linuxcnc.org/buildbot-admin/builders/1502.rip-jessie-amd64/builds/161
Note that runtests ran the test called "edge/falling", which passed,
and then ran the next test, "edge/rising-starting-high", which failed,
complaining "halrun: Realtime already running."
Some background:
* Both tests are of the "test.hal" type, which get run by halrun.
* halrun first runs "realtime status" and quits if the status is True,
as it was in this failure.
* If the realtime status is False, as it normally is, halrun runs
"realtime start", then "halcmd test.hal", then "halcmd stop",
"halcmd unload all", and finally "realtime stop".
* On uspace, "realtime status" checks for the existence of a running
"rtapi_app" process.
* On uspace, "realtime stop" runs "rtapi_app exit".
The theory of this failure is this:
The "edge/falling" test finished, its halrun ran "realtime stop" which
ran "rtapi_app exit" which caused any and all rtapi_app processes to
kill themselves. But init (or whoever was the parent of rtapi_app)
had not yet gotten around to reaping the dead process, so it was still
around, in Zombie state. The "edge/rising-starting-high" test started
up, and its halrun ran "realtime status", which now returned True because
it saw the zombie rtapi_app, and the test failed.
I can replicate this failure 100% of the time by stopping init (who's the
father of the "master" rtapi_app) using "sudo gdb /sbin/init -p 1" before
the "edge/falling" test finishes, causing rtapi_app to remain a zombie.
This current commit was proposed by Jeff Epler. It does not address the
underlying race, but gives init 5 additional seconds to reap the zombie
before giving up, thus making the failure much less likely.
I have a lovely solution to the underlying race, but unfortunately
there's not enough room in this commit message to write it down.
Signed-off-by: Sebastian Kuzminsky <seb@highlab.com>
Git can tell you what the root dir of the repo is, so the scripts don't
need to force the user to cd there first.
Signed-off-by: Sebastian Kuzminsky <seb@highlab.com>
All our supported platforms have tcl/tk 8.5. However, on Debian
Jessie the default is 8.6. Specifying a specific wish version in
the #!-line leads to a lintian error when Tcl 8.5 isn't going to be
installed anyway.
Signed-off-by: Jeff Epler <jepler@unpythonic.net>
The package require statement already mandates 8.5 (or greater)
so specifying wish8.5 is not necessary.
Newer distros provide 8.6
Signed-off-by: Dewey Garrett <dgarrett@panix.com>
for consistency with proc used for emccalib.tcl et al:
lib/hallib/hal_procs_lib.tcl:find_file_in_path
minor: improve format of "Found file" prints
Signed-off-by: Dewey Garrett <dgarrett@panix.com>
Specify with ini setting:
[XHC_HB04_CONFIG]mpg_accels = a1 a2 a3 a4
If an item is not specified, uses [AXIS_N]MAX_ACCELERATION.
Method uses ini hal pins: ini.N.max_acceleration connected by
an [APPLICATIONS]APP = xhc-hb04-accels
Signed-off-by: Dewey Garrett <dgarrett@panix.com>
+ use %.3g to handle large numbers better
+ improve is_int test for values in e format
+ eliminate redundant Update button (use Restart)
+ clear all displays at restart
Signed-off-by: Dewey Garrett <dgarrett@panix.com>
For use when both external controls and displays are
provided in demonstration configs.
When custom external displays and controls are required,
use the moveoff component with a custom gui.
Signed-off-by: Dewey Garrett <dgarrett@panix.com>
1) record waypoints always
2) allow backtrack-enable pin to change from state when
offset enabling stargs
3) provide checkbutton in moveoff_gui (if no. of axes > 1)
Note: this new behavior also enforces waypoint limit
even when backtrack-enabled not used
Signed-off-by: Dewey Garrett <dgarrett@panix.com>
a thread named 'motion-controller' is not expected to be there for all
users, viz. hal-only apps like latency-histogram
Signed-off-by: Dewey Garrett <dgarrett@panix.com>
when providing controls (when move-enable not connected)
also:
add to comments in moveoff_external.hal
set external_backtrack_en==0 for fixed offset
Signed-off-by: Dewey Garrett <dgarrett@panix.com>
on loadrt detection for multiple near-simultaneous startups
also:
guard for delf messages on exit
update help text for pintypes supported
Signed-off-by: Dewey Garrett <dgarrett@panix.com>
Also:
When a bin had only one count, it was not
showing when using y axis logscale -- so alter
bin value from 1 to 1.1 to appear as a pip
above the yaxis 1E0 line.
Rearrange documenting lines for better fit with --nobase
Suggested by Peter Wallace
Thanks to jepler for rtapi_math64 with rtapi_div_u64
Signed-off-by: Dewey Garrett <dgarrett@panix.com>
Uses a single external_enable toggle switch
(simulated with sim_pin for this demo)
Also: support this usecase with availability of new option:
-no_cancel_autoresume
Signed-off-by: Dewey Garrett <dgarrett@panix.com>
The original one-time check for a *.resume-inhibit pin
necessitated a startup delay in order for a gui (axisui)
to create the pin.
This commit checks for the pin dynamically to remove need
for using an ini item for [APPLICATIONS]DELAY=
Signed-off-by: Dewey Garrett <dgarrett@panix.com>
until hal is started.
And make default [APPLICATIONS]DELAY=0
Most existing [APPLICATION]APP= examples only need a delay for
creation of hal pins -- this commit elimates need for a delay in
these cases.
A delay _is_ needed when an [APPLICATION]APP= depends
on [HAL]POSTGUI_HALFILE connections or other gui preliminaries
such as the pins created by the touchy gui.
Signed-off-by: Dewey Garrett <dgarrett@panix.com>
improve gave_msg handling
add warning pin
for hal pin notice of:
apply-offsets deasserted while offsets-applied
occurs if program stopped or resumed while offsets active
hookup_moveoff.tcl
typo
moveoff.halshow
show resume pins too
Signed-off-by: Dewey Garrett <dgarrett@panix.com>
linuxcnc.in: a haltcl file can make use of args
haltcl.in: set argv [lindex $argv 1 end] was always wrong,
lrange was intent
Signed-off-by: Dewey Garrett <dgarrett@panix.com>
