machinekit/machinekit-cnc

CNC stack split out into a separate package

Machinekit

 █████╗ ██████╗  ██████╗██╗  ██╗██╗██╗   ██╗███████╗██████╗
██╔══██╗██╔══██╗██╔════╝██║  ██║██║██║   ██║██╔════╝██╔══██╗
███████║██████╔╝██║     ███████║██║██║   ██║█████╗  ██║  ██║
██╔══██║██╔══██╗██║     ██╔══██║██║╚██╗ ██╔╝██╔══╝  ██║  ██║
██║  ██║██║  ██║╚██████╗██║  ██║██║ ╚████╔╝ ███████╗██████╔╝
╚═╝  ╚═╝╚═╝  ╚═╝ ╚═════╝╚═╝  ╚═╝╚═╝  ╚═══╝  ╚══════╝╚═════╝

Important

This repository has been archived. This means that there will be no new development nor security updates and pull requests will not be accepted. The builder system was taken down.

The development continues in two separate repositories:

1. Machinekit-HAL: https://github.com/machinekit/machinekit-hal

2. Machinekit-CNC: https://github.com/machinekit/machinekit-cnc

Original, frozen .deb packages for Machinekit will be available in deb.machinekit.io repository for the foreseeable future.

---

Machinekit:

Manpages:

DISCLAIMER

THE AUTHORS OF THIS LIBRARY ACCEPT ABSOLUTELY NO LIABILITY FOR ANY HARM OR LOSS RESULTING FROM ITS USE. IT IS EXTREMELY UNWISE TO RELY ON SOFTWARE ALONE FOR SAFETY. Any machinery capable of harming persons must have provisions for completely removing power from all motors, etc, before persons enter any danger area. All machinery must be designed to comply with local and national safety codes, and the authors of this software can not, and do not, take any responsibility for such compliance.

What is Machinekit?

Machinekit is a platform for machine control applications.

Machinekit is portable across a wide range of hardware platforms and real-time environments, and delivers excellent performance at low cost. It is based on the HAL component architecture, an intuitive and easy to use circuit model that includes over 150 building blocks for digital logic, motion, control loops, signal processing, and hardware drivers. Machinekit supports local and networked UI options, including ubiquitous platforms like phones or tablets.

Getting Machinekit

The easiest way to get up-and-running is to install Debian Stretch and get the binary packages.

Please go to www.machinekit.io for this and all other information, including documentation.

History

The open-source Machinekit project forked from the open-source LinuxCNC project (http://www.linuxcnc.org) in 2014. At the present time, identifiers such as 'linuxcnc' and 'emc' (the antecedent of linuxcnc) still occur in various places. These occurrences are diminishing with time as the Machinekit codebase and Machinekit documentation evolve.

machinekit-cnc's Issues

tkemc 4th axis manual jog [ ] keyboard cannot be used?

Why the machinekit UI tkemc 4th axis manual jog [ ] keyboard cannot be used?

we need a regression test framework which actually works. runtests has to go.

Issue by mhaberler
Sun Jun 15 06:57:00 2014
Originally opened as machinekit/machinekit#220

---

I'm loosing patience with this utterly naive approach to 'testing' which we inherited - this is the singlemost biggest time waster. This has to go.

The current suite of 'tests' is so full of race conditions and using naive programs and scripts that in many cases the failure of a runtest is basically meaningless - it usuallly just shows the author has not considered timing of parallel activities and how they can be properly interlocked.

Milestone proposal: deprecate runtests.

For each 'failure' found, rewrite the test with the new cython bindings once we have them, make sure the test actually says something, and disable the old one.

joints-axes branch not yet merged

Issue by mhaberler
Wed Jan 14 23:56:29 2015
Originally opened as machinekit/machinekit#438

---

current code (mostly motion and jogging-related upper layers) has some fundamental confusion about axes versus joints. Cleaning this up is an important prerequisite for supporting non-trivial kinematics better, and also to clean up dark corners like jogging.

There has been work ongoing for several years mostly by Michal Geskiewicz to remedy this, it's in branches termed 'joints-axes' or 'jaX' both in git.linuxcnc.org and my own machinekit fork on github (possibly others too). The code is mostly in place, but bits and pieces are missing.

Of the options - have those branches linger around on end, or go for an accelerated merge with a likely bumpy period thereafter, I think the second option is the better (and motivation for fixes will be higher).

A likely base branch could be this: https://github.com/mhaberler/machinekit/tree/ja6-candidate-1 which rebases the git.linuxcnc.org ja6 branch onto machinekit while keeping the jog-while-paused feature working

Canon lacks general transform capability

Issue by einstine909
Thu Dec 3 16:43:48 2015
Originally opened as machinekit/machinekit#816

---

Cannon currently cannot apply transforms to the requested moves. @mhaberler suggested a python plugin interface here similar to the gcode remapping facility. Previous discussion on this issue was here: https://groups.google.com/forum/#!topic/machinekit/mhfg2pzXZbk

A machinekit configuration cannot be launched via machinekit-client if there is an underscore in the path to the ini-file.

Issue by everclear72216
Sat Jan 6 14:55:58 2018
Originally opened as machinekit/machinekit#1347

---

Reproduction:

• copy a known working configuration to a directory that contains an underscore somewhere in its path
• create a mklauncher configuration (launcher.ini and launcher.py) that launches the newly created configuration
• start mklauncher with the new configuration
• start machinekit-client on the remote host and select to launch the advertised configuration

Observation:

• the client will show that the sever is launching the configuration an after a few seconds it will show "returned with exit code 1"

Expectation:

• It just works

disentangling the trajectory planner API

Issue by mhaberler
Wed Feb 4 08:27:24 2015
Originally opened as machinekit/machinekit#476

---

The emc/tp code needs access to some config and status items. This is currently done by referencing the emcmot_config_t, emcmot_status_t and emcmot_joint_t structures directly. This is undesirable as it creates a data structure dependency, and makes decoupling harder.

The idea is to replace those references by callbacks which go through a struct passed down from using code; the tp would get/set values as needed through these callbacks. If a callback is NULL for a readonly value, a default value could be used instead.

These are the items referenced:

num_dio, num_aio - setup time, read-only - pass as parameters once

emcmot_config_t (all read-only):
maxFeedScale double
arcBlendGapCycles double
arcBlendOptDepth int
arcBlendEnable int
arcBlendRampFreq double
arcBlendFallbackEnable int

Plan: make those get_* callbacks to fetch values as needed
Q1: do we need for changing these values on the fly? (like making them a pin/config item?)
Q2: if callbacks not set, what would be sensible default values?

emcmot_status_t

read-only - plan: make those getter callbacks:
net_feed_scale
spindleRevs
spindle.direction
enables_new
spindle_is_atspeed
spindleSpeedIn
Q: any sensible default values for the above?

read-write - make those getter/setter callback pairs; I guess these are must-have callbacks:
spindleSync
current_vel
dtg
spindle_index_enable
spindleSync

write-only - make those setters, ignoring them if NULL callbacks
requested_vel
distance_to_go
spindle.speed
enables_queued

velocity and acceleration bounds from emcmot_joint_t:
these look like config-time fixed (or does it make sense have those changeable on the fly?)
tpGetMachineAccelBounds(PmCartesian * const acc_bound)
tpGetMachineVelBounds(PmCartesian * const vel_bound)

the alternative to a table of getters/setters would be to provide pointers to the raw data (wherever that lives) decoupled from the actual structures; while simpler, we dont get change notification in the using code - the callback scheme would allow tacking an action onto any change

another method would be to move these items into the tp instance data, and provide getters/setters for the using code

what is preferrable: callbacks, data reference or make it instance data?

it's also conceivable to use a combination; e.g an using-code accessor for say current_vel, requested_vel etc; and callbacks for spindle* values which change rarely.

Error during copy process

8 comments left off - recopied

motion: can we kill free and teleop modes, yielding a modeless planner?

Issue by mhaberler
Sat Dec 6 22:31:20 2014
Originally opened as machinekit/machinekit#396

---

I am considering how to remove teleop mode from motion, and possibly free mode; the insane mode switching with all its abortive behavior is a major stumbling block driving motion from more than input source, for instance a more sane jogging architecture but also other applications

for the below it's instructive to read https://github.com/araisrobo/linuxcnc/blob/master/src/emc/motion/teleop-notes

one question I have is on forward kinematics, see https://github.com/araisrobo/linuxcnc/blob/master/src/emc/motion/teleop-notes#L61

First, note also that ALL kinematics currently in the code base yield KINEMATICS_BOTH (i.e. both forward and reverse kins available), which in effect makes teleop and coord mode identical

(1) is it actually conceivable that for ANY machine, you can NOT come up with an unambiguous forward kins? I have a hard time imagining any such scenario - isnt it that given joint positions, one can always compute the cartesian position of the end effector? (I would rather want to)

if the answer to this question is 'no', then teleop mode is a red herring and can be safely dropped (wouldnt be the first fish of this kind, size and age on the angle)

while we are on the subject of removing modes, a second question - on removing free mode; the only use for free mode I see is for homing

Right now the only type of move one can feed the coord mode planner is a cartesian pose, i.e. kins applied, all axes specified, and in homed state

Now assume what is currently coord mode had a new command which specified a move endpoint in joint positions (i.e. which joint(s) affected and how much): this would in effect be a joint move (one or several joints), BUT using the coord mode planner. IOW: no more need for the 'free mode planner', and 'free mode'.

To home with such a modeless planner, one would have to allow such joint moves if unhomed or homed, but not allow axes (coord) moves if unhomed (it would also trivially enable jogging a gantry kins: just specify both joint endpoints)

(2) what am I overlooking? (or is this whale #2 on the angle ;-?)

Joint following error on larger file

Hi there! I most certainly don't know this is the right place for it, if it isn't, I apologize in advance.
I am running machinekit remote, mkwrapper as DISPLAY, along with cetus interface as remote interface, on a BeagleBone Green, rt-preempt on a 4.4 kernel, most recent (as of 10/2/2018) apt-get available machinekit release, latest machinekit client release.
I am having issue with joint following errors.
It happens if I go any further on a given long ngc file. If I reduce a lot the feed rate (from 1800 mm/min to 600 mm/m), it doesn't happen.
Tried varying servo thread period and reducing stepgen period, without success.
If I execute the exact same a remote X session over ssh and the axis front end, I get no problems.
Is there a way for me to debug this issue any further?
Thanks!
Paulo Sherring.

Maximum number of tools

Issue by machinekoder
Mon Jul 11 13:41:43 2016
Originally opened as machinekit/machinekit#989

---

The maximum number of tools is currently hard coded and limited to 56 (see https://github.com/machinekit/machinekit/blob/master/src/emc/nml_intf/emctool.h#L23). Would it make any problems to raise the number of supported tools to 100?

Configuration & distributed setups: INI files wont get us there

Issue by mhaberler
Fri Apr 4 21:05:06 2014
Originally opened as machinekit/machinekit#104

---

currently LinuxCNC classic uses INI files for configuration information. This assumes a common filesystem and will generally not work a distributed setup.

Related problems are: persistent values (store on exit, reload on startup), and live tunable persistent parameters.

I've written up some thoughts here: https://github.com/mhaberler/asciidoc-sandbox/wiki/Config-Service

problem: the current INI file method wont work downstream - find or build a suitable successor.

Convert setup.sh to .bbio files

Issue by machinekoder
Fri Nov 3 08:20:27 2017
Originally opened as machinekit/machinekit#1310

---

Description

Early configurations used custom setup.sh bash scripts to configure pin muxing on the BBB. In the meantime, the BB universal IO has been introduced.

Unfortunately, the device tree overlay format has changed since the 3.8 kernel generation and all setup.sh files need to be modified. However, I sugged converting them to .bbio files so we don't face this problem again in the future.

In most cases, this is pretty much a copy and paste job and therefore great for beginners.

Example BBIO file:
https://github.com/machinekit/machinekit/blob/master/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS/CRAMPS.bbio

Example setup.sh: https://github.com/machinekit/machinekit/blob/master/configs/ARM/BeagleBone/Probotix/setup.sh

There is also a graphical BBIOConfig editor

Task

Find and convert setup.sh files in https://github.com/machinekit/machinekit/tree/master/configs/ARM/BeagleBone

No environment variables in INI files

Issue by machinekoder
Sat Jan 10 11:53:21 2015
Originally opened as machinekit/machinekit#425

---

The linuxcnc script does not support environment variables. However, environment variables are useful to make portable configurations. With the upcoming 3D printing related remaps it may be necessary to reference the ngc file path using environment variables.

Need for per joint homing behaviour

Issue by luminize
Fri Jan 15 09:34:03 2016
Originally opened as machinekit/machinekit#862

---

We need to have a component which can take care of homing a joint from a very minimal HAL setup.

machinekit/machinekit#689 (comment)
machinekit/machinekit#689 (comment)
machinekit/machinekit#689 (comment)

we need a regression test framework which actually works. runtests has to go.

Issue by mhaberler
Sun Jun 15 06:57:00 2014
Originally opened as machinekit/machinekit#220

---

I'm loosing patience with this utterly naive approach to 'testing' which we inherited - this is the singlemost biggest time waster. This has to go.

The current suite of 'tests' is so full of race conditions and using naive programs and scripts that in many cases the failure of a runtest is basically meaningless - it usuallly just shows the author has not considered timing of parallel activities and how they can be properly interlocked.

Milestone proposal: deprecate runtests.

For each 'failure' found, rewrite the test with the new cython bindings once we have them, make sure the test actually says something, and disable the old one.

ArcEye/update-iocontrol-set-current-tool 0 allowed #1448

In the way you says after a failure ATC need to correct herself, so ATC need to move without user asking ?can be dangerous.

Your first modified files allows to ask 0, in the GUI send T0M6 make a clean reset i have some trouble to understand.

In the whole iocontrol nothing other make some check of this type, this is the job for other side of iocontrol, so this i the ATC or other who deal with it.

As my understanding ioncontrol is a open user/component interface i think this release with the check of the toolnumber is not in the way of general purpose.

more flexible EmcPose representation

Issue by mhaberler
Mon Apr 21 23:27:56 2014
Originally opened as machinekit/machinekit#151

---

Currently the internal representation of axis positions looks like so:

typedef struct {
    double x, y, z;     /* this.x, etc. */
} PmCartesian;
typedef struct EmcPose {
    PmCartesian tran;
    double a, b, c;
    double u, v, w;
} EmcPose;

This has no provision for NULL axis values (not 0.0 but value not present).

There is no indication if the values apply to joints, or axis (pre/post kinematics, joint representation really just being a special identity kins).

Also, this is rather irregular - the benefit of the PmCartesian substructure is unclear, and the discrete-scalar representation makes iteration over axis values awkward.

While I'm not suggesting to replace this fundamental type everywhere right away, there are work items which permit experimentation with a better representaion, like preview drivers.

A future representation IMO should fulfill these requirements:

• axis are held in a sparse-array like representation
• a kinematics type indicator should be present
• a good match on protobuf fundamental types is desirable

problem: define a more flexible representation for axis values.

Design error: command serials may collide

Issue by mhaberler
Fri Apr 11 17:10:32 2014
Originally opened as machinekit/machinekit#114

---

Commands passed via NML typically have integer serial number for tracking status (received, being acted upon, completed, errored).

There is a fundamental design error: serial numbers are assigned on the originating side of a command. As soon as more than one command originator is active, this creates the danger of collisions, as NML has no identifier for an originator which could be used to make a submission ID unique (using a tuple (submitter, serial)).

An example for a hack around this issue is here: https://github.com/machinekit/machinekit/blob/master/src/emc/usr_intf/emcrsh.cc#L2842

problem: specify and implement a serial scheme which guarantees uniqueness.

Tool table pocket has no meaning without RANDOM_TOOLCHANGER

Issue by machinekoder
Wed Mar 29 18:24:57 2017
Originally opened as machinekit/machinekit#1195

---

Citing from the docs:

Note that unless you set the `[EMCIO] RANDOM_TOOLCHANGER=1` parameter,
tool and pocket number are identical, and the pocket number from the
tool table is ignored. This is currently a restriction.

This makes the pocket value and especially the prep_pocket value of iocontrol pretty useless for real-life applications.

It should not be hard to fix this problem. However, I wonder if something is already depending on this behavior?

Build is littered with compiler warnings

Issue by zultron
Fri Apr 6 23:20:12 2018
Originally opened as machinekit/machinekit#1368

---

The build is littered with compiler warnings. When compiling my updates, this makes it really hard to tell if I've introduced a new warning. #327 had them all fixed a couple of years back, but that was never merged, and it's unclear how many of those patches still address outstanding warnings, or how many would even apply.

copied in error

No way to handle tool change with python interface?

I am working on a python API that allows me to control machinekit with a webUI.
When a program promps a tool change there seems to be now way for me to handle this.

I can check if the tool change menu is popped up with pocket_prepped but there seems to be no way to accept this prompt via the python interface.

Maybe I missed something but i checked the documentation multiple times. If you have any suggestions please let me know.

Motion has no real IO pins

Issue by machinekoder
Tue Jan 20 07:29:58 2015
Originally opened as machinekit/machinekit#451

---

The motion component exposes input as well as output pins to HAL. However, the component has no real IO pins supported by HAL. For some applications it is necessary to use IO pins instead of output pins as they do not force a certain value upon a signal.

For example:

This diagram shows a mechanism to set a signal from GCode as well as from a remote component. It also stores the values on change in some sort of storage (could be the config-service). The in2io component "converts" a output pin of the motion component to a IO pi. When the trigger is triggered the IO value gets updated. This whole in2io component would be reduntant if motion would support io pins natively.

Possible solutions:

Solution 1: Make all output pins of the motion component IO pins. They would ignore value changed when connected to signals, but update the signal when their value changes.
Should be compatible with current configurations. However, IO pins for the outputs may look wrong.

Solution 2: Add additional IO pins to the motion component.
Does not break compatibility with existing configurations. Biggest implementation overhead. Would require new GCode for setting and reading the pins

Solution 3: Combine the input and ouput pins of motion to single IO pins.
Incompatible with existing configurations. Input and output pins are not necessarily related

Solution 4: Add additional IO pins for all output pins.
Will not break compatibility. However, adds additional redundant pins to motion.

copied in error

G64 Strange Behavior

Issue by dkhughes
Tue Mar 27 23:07:03 2018
Originally opened as machinekit/machinekit#1363

---

Hello,

I guess the trajectory planner was modified a little time ago? I'm seeing some very strange behavior with path blending and emcAbort.

I've attached the program showing the problem.

Dragon170928-11_toolpath1_Machine Relief 1_End Mill 1_4 Inch Roughing.txt

The units are in inches. If you set blending to 0.001" via G64 P0.001, then issue a stop command (emcTrajAbort), the machine moves to a different position instead of stopping. For my config, this position is actually into the part (it moves -X, -Y, -Z in a three axis Cartesian config). For settings of G64 P0.003 or greater, the interp immediately stops when the command is received.
Anyone else noticing odd behavior? Or could someone see if they can duplicate the issue?

Thanks,
Devin

hostmot2-firmware* missing

Issue by luminize
Wed Dec 30 22:34:12 2015
Originally opened as machinekit/machinekit#850

---

during recent install of my mesa 5i20 card I could not install hostmot2-firmware* packages.
Manually copying as root the .BIT files downloaded from the mesa site to /lib/firmware/hm2/{yourcard here}/{bitfile}.BIT solved this.
Looks like these packages were lost during the CI work #791

UUID in machinekit.ini is always the same

Issue by machinekoder
Fri Mar 13 13:00:36 2015
Originally opened as machinekit/machinekit#531

---

The Machinekit Debian packages feature a default machinekit.ini file. There is an UUID values in this configuration file that is relevant to identify different Machinekit instances on the network. This UUID should be autogenerated after package install to ensure a different identification for every machine.

Interpreter API: rearchitecting required

Issue by mhaberler
Sun Apr 6 19:21:03 2014
Originally opened as machinekit/machinekit#106

---

The way the G-code interpreter is integrated into task is seriously convoluted and suggests reconsideration.

This document describes the status and issues: https://github.com/mhaberler/asciidoc-sandbox/wiki/Interpreter-control-flow-explained

A prelimimary requirements draft is here: https://github.com/mhaberler/asciidoc-sandbox/wiki/Interpreter-API-requirements

The removal of NML does require a revision of task, interpreter and the task/motion interfaces anyway, so it makes sense to redesign this API.

This is a high-priority item because it needs to be addressed before the task/motion/interpreter complex can be switch away from NML.

version=git not installed at configure time

Issue by cdsteinkuehler
Sun Jul 6 01:14:52 2014
Originally opened as machinekit/machinekit#236

---

I am using the BeagleBone packages on a fresh install of the current latest BeagleBone Debian image (bone-debian-7.4-2014-04-23-2gb.img.xz), and I am having issues getting things running. While reviewing the logs, I notice the following every time I attempt to launch LinuxCNC:

Jul 6 01:09:03 beaglebone msgd:0: MSGD:0 mlock(global) failed: 12 'Cannot allocate memory'
Jul 6 01:09:03 beaglebone msgd:0: startup instance=inst0 pid=6003 flavor=xenomai rtlevel=1 usrlevel=1 halsize=512000 shm=Posix gcc=4.6.3 version=git not installed at configure time
Jul 6 01:09:03 beaglebone msgd:0: configured: Jul 1 2014 12:27:54 sha=git not installed or executable
Jul 6 01:09:03 beaglebone msgd:0: built: Jul 1 2014 12:29:13 sha=git not installed or executable

I am working on the "cannot allocate memory" issue, but it looks like the version= and sha= are a goof in the way packages are getting built.

copied in error

DUPLICATE SEE #8

automated build of protobuf documentation missing

Issue by mhaberler
Thu Jun 16 06:41:49 2016
Originally opened as machinekit/machinekit#970

---

this is an anchor issue for integrating the machinekit protobuf docs into the website

it's a sub-project of machinekit/machinekit#924 which is getting a tad long, so let's focus related work here

my overall idea is:

• the protobuf definitions are all important and need to be documented - ideally the same way like all the rest, 'Edit this page' link inlcuded on a per-proto-file basis
• there is a neat tool - protoc-gen-docs - which aids in generating docs from proto files - see input example and resulting output
• protoc-gen-docs is already part of the jekyll website build container and running on jenkins.machinekit.io

So to integrate the protobuf docs build into the website I guess we need to:

• add the protobuf repo into the machinekit-docs repo as a subtree (just as with mk/mk - no magic, explained here)
• add a Makefile step which runs protoc-gen-docs on the proto files, generating asciidoc; that is in place already and just needs to be integrated, and proper place for the output found
• adapt the Mustache template to output proper asciidoc - this file needs translating from markdown to asciidoc syntax ; the current output formats do not include asciidoc yet
• think through how 'Edit this proto file' links can be massaged into the output
• link the protobuf docs page in a warm place (likely near manual pages)

The build process then would be like so:

• update the protobuf git subtree
• run the protobuf-docs make target which does the protoc-gen-docs job
• run the website build

I will take care of the jenkins work to achieve that, but a sharing work with the template work would be great

Machinetalk integration testing required

Issue by machinekoder
Mon Jul 11 20:17:17 2016
Originally opened as machinekit/machinekit#992

---

E.g. by using pymachinetalk

Cannot switch to world mode after jogging homed joints.

Issue by sliptonic
Tue Mar 17 23:35:35 2015
Originally opened as machinekit/machinekit#534

---

Version: debian package 0.1.1073-1da.bbot.pr533.gitac38116~1wheezy.

Steps to reproduce:
Start MK, select the sim/axis/vismach/scara sample configuration.
Hit 'home all'
Select joint 0 and jog it a little bit.
Select view/world mode.

You'll get a message that all joints must be homed before switching to teleop mode even though all joints are already homed. The view menu indicates that it is in world mode, but the preview still shows joint names and not cartesian axis names (XYZ) Re-homing has no effect.

Same procedure but do not jog axis. Switching to world mode works correctly. User can switch back forth between the modes as long as joint is not jogged in joint mode.

Cutter Comp and motion digital outputs yields unexpected behavior

Issue by dkhughes
Wed Sep 7 19:25:39 2016
Originally opened as machinekit/machinekit#1055

---

Other issues address the problem of the tp tripping over non motion commands, which are related, but, specifically, I want this issue to be an anchor for working out why motion digital outputs act "differently" when cutter comp is turned on. Currently in the source there is a guard that disallows auxiliary output when cutter comp is enabled, but I feel like that is a bit of a kludge considering coolant io and spindle io work properly.

For instance, when cutter comp is enabled, spindle control commands function identically to when cutter comp is disabled - which is to say as expected in a naive mindset. If you ask the spindle to be on or off, it obliges. A functional example of (what I consider to be) expected behavior:

G17 G20 G90 G40 G54

S100. (GIVE A NONZERO SPINDLE SPEED TO ALLOW SPINDLE-ON)
G91 G1 G41.1D0.05X0.25 F100. (FORCE CUTTER COMP)

#<count>=0.0

o100 do
M3
G04 P0.5
M5
G04 P0.5
#<count> = [#<count> + 1.];
o100 while[#<count> LT 100.]

G40 G1 X-0.25 F100.

M02

The above produces the spindle-on output toggling as expected with a 1Hz period. Aux DO do not mimic this behavior, and remain in a locked state when cutter comp is turned on. Here is the equivalent example of above but modified to use a digital output instead of the spindle:

G17 G20 G90 G40 G54

G91 G1 G41.1D0.05X0.25 F100. (FORCE CUTTER COMP)

#<count>=0.0

o100 do
M64 P1
G04 P0.5
M65 P1
G04 P0.5
#<count> = [#<count> + 1.];
o100 while[#<count> LT 100.]

G40 G1 X-0.25 F100.

M02

This example does not produce the expected bit toggling from the face value of the nc code. Turning cutter comp off, the following example does produce the expected bit toggling:

G17 G20 G90 G40 G54

#<count>=0.0

o100 do
M64 P1
G04 P0.5
M65 P1
G04 P0.5
#<count> = [#<count> + 1.];
o100 while[#<count> LT 100.]

M02

I would like to make digital output handling when cutter comp is turned on match the other two cases, as I can think of plenty of use cases where this type of digital io + cutter compensation are beneficial.

Coding style and static analysis

Issue by machinekoder
Tue Dec 2 10:10:02 2014
Originally opened as machinekit/machinekit#391

---

We should enforce a specific coding style for every language in the project. This can e.g. be done by using astyle. My code editor (Kate) always shows mixed indentations (tabs and spaces) everywhere. This makes the code unreadable on some platforms and is possible error source.

Furthermore every piece of code that is commit should be checked with suitable static code analysis tool. For C and C++ cppcheck and clang might be suitable. For Python pep8 is the way to go. This ensures that common error will not make its way into the project.

Split user interfaces from the Machinekit core packages

Issue by machinekoder
Mon Nov 3 09:24:09 2014
Originally opened as machinekit/machinekit#357

---

Most user interfaces have lots of package requirements. At the moment the Machinekit packages do not fetch all of these requirements which is good an bad. Good because it saves storage space if you do not use these user interfaces and bad if you want to use these user interfaces. It would be a good idea to split the user interfaces in different packages.

Possible bug in interpreter with rotary axis find_ends

Issue by dkhughes
Fri Dec 29 22:45:44 2017
Originally opened as machinekit/machinekit#1339

---

This is kind of an edge case thing, but I found it digging through the interpreter files.

When the rs274 interpreter calculates the end point for a non-wrapped rotary axis in a G53 move, it does not include a tool offset value. For every other case, including the wrapped rotary condition, the tool offset is included.

A tool offset A, B, or C value seems strange, but if this type of tool offset is supported then I think the nonwrapped rotary case should be updated to include the angular tool offsets as well. Or, the wrapping case should be updated to ignore the angular tool offsets and be consistent.

Any thoughts? Does anyone know if this behavior is by design and what reason there would be for the disparity?

Here is a link to the code in question:

https://github.com/machinekit/machinekit/blob/master/src/emc/rs274ngc/interp_find.cc#L196

Jerk-limited movement?

Seems like it is impossible to limit the motor jerk in machinekit at the moment. What would be the easiest way to hack it in?

out of memory/large files results in stopped LinuxCNC

Issue by luminize
Mon May 19 06:42:37 2014
Originally opened as machinekit/machinekit#193

---

In these two thread is some discussion about LinuxCNC stopping unexpectedly, having the hot-end still hot. The exiting LinuxCNC without switching off this, zeroing the PWM or having a watchdog is another think. This bug is about preventing the out of memory occurring. I volunteered to code this, but I need some guidance in finding the beginning of the path of crumbled :)

https://groups.google.com/forum/#!topic/machinekit/rkCVRKg2-GQ
https://groups.google.com/forum/#!topic/machinekit/A3UvHqbQvN4

API's missing

Issue by mhaberler
Wed Apr 2 19:56:40 2014
Originally opened as machinekit/machinekit#99

---

API's should cover programmatic access to core functionality, optionally remote

The core component interfaces currently are:

• HAL library: local, C++ and Python - no remote access
• halrmt: deprecated, unsuitable for programmatic access, poor code
• linuxcncrsh: a telnet interface, unsuitable for programmatic access, poor code
• schedrmt: based on linuxcncrsh, supposed to be an improvement over same, completely undocumented, no known uses, poor code
• the linuxcnc Python module: local access only, covers only a small subset of NML messages
• raw NML bindings: C++ only, limited remote access (no known uses ATM), very restrictive formats and use
• Web UI: there is a start with emcweb, with all the downsides of NML behind it.

Axis UI interfaces: axis-remote: specific to Axis and tkinter. Not a general API.
Others: none known

Problem: programmatic/remote access to LinuxCNC is currently utterly inadaequate.

halshow not working - how long has it been broken?

Whilst testing the combined machinekit-hal & machinekit-cnc I found that the 'Machine Configuration' menu item in Axis did not work because tcl/hal.so was missing.

Added code to build it, but it is not right yet (another issue).

However when testing machinekit, under Buster, Stretch and Jessie, I found that 'Machine Configuration' does not work there either.
It throws an error thus

Error in startup script: couldn't load file "/usr/lib/tcltk/linuxcnc/hal.so":
 /usr/lib/tcltk/linuxcnc/hal.so: undefined symbol: tclStubsPtr
    while executing
"load $::linuxcnc::TCL_LIB_DIR/hal.so"
    (procedure "hal" line 2)
    invoked from within
"hal list $node"
    (procedure "listHAL" line 5)
    invoked from within
"listHAL"
    (procedure "refreshHAL" line 12)
    invoked from within
"refreshHAL"
    (file "/usr/lib/tcltk/linuxcnc/bin/halshow.tcl" line 578)

It is not something I have used for ages, as I have a Qt program which does a better job (IMHO)

Does anyone know when this died?

TypeError: get_interpreter() returned NULL

Hi!

I am trying to build my own machinekit under a plain stretch based debian image.

I am struggling issues with getting the following error:

  File "/home/machinekit/src/machinekit/bin/axis", line 3215, in <module>
    o = MyOpengl(widgets.preview_frame, width=400, height=300, double=1, depth=1)
  File "/home/machinekit/src/machinekit/bin/axis", line 373, in __init__
    Opengl.__init__(self, *args, **kw)
  File "/home/machinekit/src/machinekit/lib/python/rs274/OpenGLTk.py", line 164, in __init__
    apply(RawOpengl.__init__, (self, master, cnf), kw)
  File "/home/machinekit/src/machinekit/lib/python/rs274/OpenGLTk.py", line 112, in __init__
    Togl.__init__(self, master, cnf, **kw)
  File "/home/machinekit/src/machinekit/lib/python/rs274/OpenGLTk.py", line 37, in __init__
    _togl.install(master.tk)
TypeError: get_interpreter() returned NULL
Exception AttributeError: "MyOpengl instance has no attribute '_dlists'" in <bound method MyOpengl.__del__ of <__main__.MyOpengl instance at 0xb4b11f08>> ignored
Shutting down and cleaning up Machinekit...

I traced it back to the file src/emc/usr_intf/axis/extensions/_toglmodule.c.
This diff adds some more debug info (might be good to have it in the master branch as well):

index 6c872b5fe..2a591566b 100644
--- a/src/emc/usr_intf/axis/extensions/_toglmodule.c
+++ b/src/emc/usr_intf/axis/extensions/_toglmodule.c
@@ -22,8 +22,12 @@ static Tcl_Interp *get_interpreter(PyObject *tkapp) {
     PyObject *interpaddrobj = PyObject_CallMethod(tkapp, "interpaddr", NULL);
     if(interpaddrobj == NULL) { return NULL; }
     interpaddr = PyInt_AsLong(interpaddrobj);
+    if (PyErr_Occurred()){ 
+        PyErr_PrintEx(0);
+       return NULL;
+    }
     Py_DECREF(interpaddrobj);
-    if(interpaddr == -1) { return NULL; }
+    if((interpaddr == -1) && PyErr_Occurred()) { return NULL; }
     return (Tcl_Interp*)interpaddr;
 }

The change with the checking of == -1 is necessary as the PyInt_AsLong documentation says just checking for -1 is not correct.
Anyway, that is not my issue.... Running this modified code gives me this error reason:
OverflowError: Python int too large to convert to C long

Really strange... I have no idea of the internals of PyInt_AsLong but as I was curious and I tried to replace it by:
interpaddr = PyInt_AsUnsignedLongLongMask(interpaddrobj);
With this fix axis starts up just fine and it looks like all is working as expected.
I am sure this is not the correct way of doing it.
Maybe a python guru can point me in the right direction?

Simon

information when machinekit fails is wrong/inadequate

Issue by luminize
Wed Apr 4 06:53:44 2018
Originally opened as machinekit/machinekit#1366

---

When something fails the following is shown:

See /var/log/linuxcnc.log for more information.
Shutting down and cleaning up Machinekit...
Cleanup done
Machinekit terminated with an error.  You can find more information in the log:
   /home/machinekit/linuxcnc_debug.txt
and
   /home/machinekit/linuxcnc_print.txt
as well as in the output of the shell command 'dmesg' and in the terminal

Personally I think this is wrong info and should contain better instructions, like something as "start with export DEBUG=5" and "look at /var/log/linuxcnc.log before posting". Maybe some basic instructions in helping people narrowing down.

I don't remember ever finding anything in linuxcnc_debux.txt or linuxcnc_print.txt

Opinions?

Strange behaviour with HOME_SEARCH_VEL direction

Issue by gorf25
Thu Apr 30 00:46:35 2015
Originally opened as machinekit/machinekit#601

---

Bas De Bruijn asked me to open a new issue and to refer to this
google groups posting

lineardetla calibration
i have not been able to calibrate the printer

the link to group

https://groups.google.com/forum/#!topic/machinekit/MRTmRa3saX0

thanks gary

Switch ARM configurations to velocity-mode

Issue by cdsteinkuehler
Tue Apr 15 18:45:33 2014
Originally opened as machinekit/machinekit#131

---

Switch to velocity-mode for PRU step/dir generation with HAL based PID loop to allow dead-band adjustment and eliminate "hunting" on the direction output.

scripts/{get-git-sha,check-build-vs-configure-sha} missing

The build complains:

make[1]: ../scripts/get-git-sha: Command not found
make[1]: ../scripts/check-build-vs-configure-sha: Command not found

Should these scripts be copied over from machinekit-hal?

referencing LCNC issues in commits from a machinekit fork will add wrong relations

Issue by luminize
Sun Feb 11 12:28:12 2018
Originally opened as machinekit/machinekit#1355

---

referencing linuxcnc issues in commits (hashtag + number) on a machinekit fork links back to machinekit organisation repos issues while these numbers definitely don't match.
for example like here:
machinekit/machinekit#134 (reference)

GCode preview speed/data size/quality too slow

Issue by machinekoder
Wed Apr 16 10:03:08 2014
Originally opened as machinekit/machinekit#134

---

The speed of the currency available GCode previews is insufficient for files generated by tools like Slic3r for 3D printing. A small object can result in a very big GCode file (80.000+ lines) due to layer height of 50 microns or smaller. This results in a very slow preview loading process and unclear preview output (many line resulting in a big white blob).

Even when deactivating the preview the interpreter seems to somehow process the GCode file for preview. The slow preview window may also cause slow exution performance due to the lack of powerful graphics hardware on most embedded platforms.

M67 commands works only for outputs 0-31

Issue by machinekoder
Thu Jan 29 13:46:25 2015
Originally opened as machinekit/machinekit#467

---

When executing the M67 command I found that it only works for outputs 0-31. The M68 command however works fine.

Interp::read_real_number is very inefficient

Issue by powool
Sun Jun 14 13:25:16 2015
Originally opened as machinekit/machinekit#685

---

src/emc/rs274ngc/interp_read.cc Interp::read_real_number() is very inefficient: it takes about 10X as long as it should.

C++ string stream libraries are very slow, and this method additionally causes needless new/delete as it is shuffling the string around.

I don't have a good build environment, otherwise I'd offer a pull request, but here's my standalone test file of two functions that I believe do the same thing. This needs to be verified with someone comfortable in running regression tests.

To test, compile the below code and run like this:

./float 1 3.1415926
./float 2 3.1415926

The second float function uses strtod() with no additional memcpy, new, delete or anything, and shows as being about 9X as fast on my beaglebone black.

In benchmarking before and after gcode load times, the difference is much less - since I did this a month ago, I don't remember exactly how much - I think on the order of 10%.

There are many instances of strspn() being used - any that are called for every character of the input gcode also need to be re-written, especially ones such as at /src/emc/rs274ngc/interp_remap.cc near line 403, although from looking at the context, I doubt it gets called much in my use case (3D printing).

#include <iostream>
#include <stdlib.h>
#include <string.h>
#include <string>
#include <sstream>

int read_real_number1(const char *line, //!< string: line of RS274/NGC code being processed
    int *counter,       //!< pointer to a counter for position on the line
    double *double_ptr) //!< pointer to double to be read
{
    const char *start;
    size_t after;

    start = line + *counter;

    after = strspn(start, "+-");
    after = strspn(start+after, "0123456789.") + after;

    std::string st(start, start+after);
    std::stringstream s(st);
    double val;
    if(!(s >> val))
    {
        std::cout << "bad number format (conversion failed) parsing '" << line << "'\n";
        return 1;
    }
    if(s.get() != std::char_traits<char>::eof())
    {
        std::cout << "bad number format (conversion failed) parsing '" << line << "'\n";
        return 1;
    }

    *double_ptr = val;
    *counter = start + after - line;
    //fprintf(stderr, "got %f   rest of line=%s\n", val, line+*counter);
    return 0;
}

int read_real_number2(const char *line, //!< string: line of RS274/NGC code being processed
    int *counter,       //!< pointer to a counter for position on the line
    double *double_ptr) //!< pointer to double to be read
{
    const char *start;
    size_t after;

    double result = 0;
    char *endptr;
    result = strtod(line + *counter, &endptr);

    if(endptr == NULL)
    {
        std::cout << "bad number format (conversion failed) parsing '" << line << "'\n";
        return 1;
    }

    *counter += (endptr - (line + *counter));

    *double_ptr = result;

    return 0;
}

int main(int argc, const char **argv)
{
    if(argc != 3)
    {
        std::cout << "usage: " << argv[0] << " [1|2] <number>\n";
        exit(1);
    }

    double number = 0;
    int counter = 0;
    int result;
    int i;
    for(i = 0; i < 500000 ; i++)
    {
        number = 0;
        counter = 0;

        if(argv[1][0]=='1')
            result = read_real_number1(argv[2], &counter, &number);
        else
            result = read_real_number2(argv[2], &counter, &number);
    }

    std::cout << "result = " << result << ", counter = " << counter << ", number = " << number << "\n";;

    exit(0);
}