In the original formulation, a use like
RTAPI_MP_ARRAY_INT(arr, 3*FOO, "array of three times foo items");
gave a weird error on uspace only when arr= was actually
specified on the loadrt commandline. This is because the 'num'
value was communited to rtapi_app as a string rather than an
integer, so the string "3*FOO" was received where a string like
"24" was expected, resulting in an error.
Happily we have good test coverage for comp's use of
RTAPI_MP_ARRAY via tests/module_loading/or2* so even though this
was encountered and reported in the non-runtested hal_ppmc driver,
we can have confidence about the solution.
Close#242.
Signed-off-by: Jeff Epler <jepler@unpythonic.net>
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>
This reverts commit d82230b167.
Requested via IRC after discussion of what triple-quoted strings
mean in halcompile.
Signed-off-by: Jeff Epler <jepler@unpythonic.net>
This Status variable should track the number of queued MDI commands
in Task, but it's been broken since inception. I removed the buggy
management of it (rather than fix it) in 2.5. This commit fixes it
finally, about 4 years later.
Signed-off-by: Sebastian Kuzminsky <seb@highlab.com>
This test verifies that stat->task.queuedMDIcommands (aka
stat.queued_mdi_command in python-land) grows as we add MDI commands to
Task's MDI queue and shrinks as Task executes them.
This test currently fails because queuedMDIcommands is always 0. I fix
Task in the following commit to set it correctly.
Signed-off-by: Sebastian Kuzminsky <seb@highlab.com>
This commit fixes#228, reported by Anton Midyukov. Adapted for 2.7
from Jeff Epler's commit f87c0244.
On Debian Stretch on i686, building 2.7 results in rtlibs link-time
failures like this:
Compiling realtime objects/hal/components/clarke2.c
Linking ../rtlib/clarke2.so
`__x86.get_pc_thunk.dx' referenced in section `.text' of objects/clarke2.tmp: defined in discarded section `.text.__x86.get_pc_thunk.dx[__x86.get_pc_thunk.dx]' of objects/clarke2.tmp
collect2: error: ld returned 1 exit status
make: *** [../rtlib/clarke2.so] Error 1
Looks related to this bug on the GCC bugzilla:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59842
Signed-off-by: Sebastian Kuzminsky <seb@highlab.com>
step timing was incorrectly mapped on to word variables.
step timing variables could not be selected to watch or evaluate.
Signed-off-by: Chris Morley <chrisinnanaimo@hotmail.com>
ver. 1.5.7
- new hal pin gmoccapy.ignore-limits so that this function can be
handled from hardware switch
Ask by some users, done because of a wish of Timothy Snowden
Signed-off-by: Norbert Schechner <nieson@web.de>
Sometimes users attempt to use xhc-hb04.tcl with prior
HALFILE hal connections (typically halui pins) that are
required for use of xhc-hb04.tcl.
Formerly, such connections were reported to stdout
and prevented LinuxCNC startup with xhc-hb04.tcl.
Now, such connections are reported to both stdout and a
popup -- but startup is allowed to continued with
a concomitant loss of functionality
Often, users may be able to correct by reordering HALFILEs
and/or using the signal names created by xhc-hb04.tcl
For more complicated configurations, users may loadusr
the xhc-hb04 userspace driver directly and forego use of
xhc-hb04.tcl.
Signed-off-by: Dewey Garrett <dgarrett@panix.com>
ver. 1.5.6.10
- if no MARCO was found in INI getiniinfo returned a NONE, leading to an
exception in gmoccapy, corrected that.
Signed-off-by: Norbert Schechner <nieson@web.de>
ver. 1.5.6.9
- if no MACROS where given, or the paths where not correct, the Keyboard button
in MDI mode was not any more in the most right position, leading to wrong
order in horizontal hal button handling
Signed-off-by: Norbert Schechner <nieson@web.de>
Conflicts:
src/emc/usr_intf/gmoccapy/gmoccapy.py
src/emc/usr_intf/gmoccapy/release_notes.txt
added the solution of G96 bug also to 2.7 release
Signed-off-by: Norbert Schechner <nieson@web.de>
ver. 1.5.6.2.3
- bug in handling a subroutine call from MDI, containing
G96 code. Thanks to Hakan for reporting this.
Signed-off-by: Norbert Schechner <nieson@web.de>
