Fix for ramping acceleration bug#8
Closed
robEllenberg wants to merge 2840 commits into
Closed
Conversation
emc/rs274ngc: fix compile problem with newer boost version
3e96abf Merge pull request LinuxCNC#9 from strahlex/halrcomp-no-create a9c12fb for-proto: add no_create flag to Component submessage git-subtree-dir: src/machinetalk/proto git-subtree-split: 3e96abf
…g set this makes creating UI's matching the HAL config a bit easier
Machinetalk: Add paramter to HAL remote component bind to prevent component creation
This will make cython a build requirement. see also machinekit#318
BBB eqep driver
hal/cython: remove precompiled files
machinetalk/haltalk: enabled zeroconf announcement on loopback device
cpp stringification created an invalid descriptor when using parentheses
hal/drviers/7i90: unbreak loading of the driver
Also add an ini file field and allow user variance of arc tolerances within preset limits Default tolerance set to figure 2 * 0.001 * sqrt(2) for inch, and 2 * 0.01 * sqrt(2) for mm. This would mean that any valid arc where the endpoints and/or centerpoint got rounded or truncated to 0.001 inch or 0.01 mm precision would be accepted. This behavior is the root of the problem with some CAM generated code. Minimum tolerance capped at 1 micron and equivilent imperial. Signed-off-by: Mick Grant<arceye@mgware.co.uk>
Fix metric arc tolerence to same value as imperial
Signed-off-by: Charles Steinkuehler <charles@steinkuehler.net>
Added support for using BeagleBone P8/P9 header pin numbers instead of kernel GPIO numbers offset by 32 Signed-off-by: Charles Steinkuehler <charles@steinkuehler.net>
Signed-off-by: Charles Steinkuehler <charles@steinkuehler.net>
Allow exported hal names to use a configurable prefix. The default hal_pru_generic is long enough it causes names exported by the encoder to be truncated resulting in name colision which then prevents the module from loading. Signed-off-by: Charles Steinkuehler <charles@steinkuehler.net>
Signed-off-by: Charles Steinkuehler <charles@steinkuehler.net>
Pin name cleanup
haltalk: fixed no_create flag
Use `autoreconf` in `autogen.sh` and remove generated `aclocal.m4` so that autoconf will use system-installed m4 macros. Remove unneeded `m4_include` statements.
Replace NIH use of `pkg-config` with `PKG_CHECK_MODULES` for `libudev`, `libmodbus3`, `libusb`, `gtk+` and `glib`. Detect cross-compile version of `pkg-config`. Use detected `pkg-config` in Makefiles for protobuf.
Replace NIH `{tcl,tk}Config.sh` detection with m4 macros.
Because macros shipped with Wheezy are broken, bundle a version from
Ubuntu/tcl8.6 modified to work with 8.5 also, and tell `autoreconf` to
search the `src/m4` directory first.
This macro file may be removed when Debian Bug#777085 is resolved or
Wheezy becomes obsolete.
This workaround for an ancient Ubuntu bug is now obsolete.
These wouldn't normally be needed, except for the wacky `.rtapi_export` stuff used in RTAPI modules.
At configure time, detect the build-arch C compiler in the conventional `$(CC_FOR_BUILD)` variable, and pass `$(CROSS_COMPILING)`. In the Makefiles, give `TOOBJSDEPS` an optional second argument added to output filenames to distinguish from host-arch outputs, and add `CUSERSRCS_BUILD` rules paralleling `CUSERSRCS`.
Build the `pasm` tool twice: once in build-arch for use during build, and once in host-arch for inclusion in the `-dev` package.
Enable cross build
The included test case shows the wrong active G-Codes (for example, the work offset will always show G56, even though this is only active for the last 3rd of the program).
This commit implements state tags at all levels. State tags contain a snapshot of the interpreter state that rides along with a motion command. This way, we can easily determine what the interpreter state was at the time the motion was generated. This tag in principle can be extended arbitrarily, though the size should be kept to a minimum. Interp: generate state tags before calling a canon command that produces a motion. Right now this is done by manually creating a tag before it's needed. Canon: Keeps a local copy of the state tag, which is updated by a dedicated canon command. This tag is added to any outgoing motion, and it's Interp's responsibility to keep it up to date. Ideally, canon wouldn't have to deal with this at all, and the tag would be an argument to canon commands (or packed into an appropriate structure). Task/NML: State tags are included in the NML messages for motion commands. HOWEVER, "update" methods are NOT implemented, because motion messages are never actually transmitted via NML when Task / Motion are on the same machine. In this case, the NML message is just a holding tank for motion data, which is eventually copied into motion shared memory. Motion / TP: The state tag is included as an additional argument, but is otherwise unused currently. Pretty much all that happens here is that the tag is copied into the TC_STRUCT, and the currently executing segment's tag is copied into motion's status output. Status: If motion is running, it reports a state tag through EMC_TRAJ_STAT. Task unpacks this into the appropriate active_g/m_codes in emcStatus, so that UI's see the active state corresponding to the motion. If motion is not running, then the active state shown is copied directly from interp, as before.
Since G-Codes are represented internally as 10*N (N=0-99), one of these codes can fit in a 16 bit int, and save a few bytes. Since the line number needs to be a 32 bit int, this is broken out as a separate field.
I ended up here because clang warned about 'strncat(cmd, buf, sizeof(buf))' -- strncat is notoriously difficult to use. This usage is wrong, and related code must be prepared to deal with a non-NULL-terminated character array (which related code was not). Use C++ strings instead, until it becomes inconvenient to (the place where the string needs to be split at newlines) Signed-off-by: Jeff Epler <jepler@unpythonic.net>
The state tag changes show the "current" state according to motion. However, an early abort will cause the displayed modes to suddenly switch to the actual interpreter state. This could be confusing to a user, so we call a restore method on abort that pulls the latest state tag from motion and unpacks it into a usable state.
This reverts commit 4e9c4820faa3bd54cc1b9f93d5164adca45052ae.
Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
Add "State Tags" to motion segments
…ed vs. trapezoidal acceleration Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
Collaborator
|
PRs for linuxcnc are welcome, just please make sure they're based on some reasonable commit in our repo. |
Collaborator
Author
|
Sorry! That PR was meant to be for the machinekit repo (so I closed it -Rob On Mon, Feb 9, 2015 at 5:49 PM, Sebastian Kuzminsky <
|
hansu
added a commit
that referenced
this pull request
Oct 30, 2022
Move icon_theme related stuff in separate file
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
13 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I made a subtle mistake in the code that chooses whether to use trapezoidal or ramped acceleration, which can lead to strange behavior when using spindle-synced motion. The result was that short segments would sometimes be ramped up over a very long time (~20 seconds). This fix corrects the final velocity estimation so that this doesn't happen.