Hi

Configure output: http://dpaste.com/2HAGKHS
Error: http://dpaste.com/0EB8BRS

I'm having this error when compiling master branch 3e93bfa on ubuntu 16.04

i'm building a simulator with --with-realtime=uspace

Thx

Currently (as of 2.7.4 and master commit 69e87f9) the interpreter saves the parameter file in an unsafe way:

1. rename the current file with a backup extension
2. create a new replacement parameter file by opening it for writing
3. write out the parameters
4. close the file to save it

This is done in src/emc/rs274ngc/rs274ngc_pre.cc's Interp::save_parameters().

This has the danger that something can go wrong after 1 but before 4 (such as the operator removing power to the machine), resulting in corruption.

A safer alternative would be to copy the existing parameter file to a backup, write the new parameter file to a temporary file, then atomically renaming the temporary file to the real parameter file, replacing it.

Another alternative would be to look into a lightweight key/value store, perhaps in a separate process. This would have the benefit of not blocking Task if disk access is slow, which is currently a major source of userspace/non-realtime latency in linuxcnc.

This fix should be made in master, not in a stable/release branch.

We currently have instructions on how to build LinuxCNC in at least four different places:

• /README.md
• /docs/INSTALL
• http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Installing_LinuxCNC
• http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Installing_EMC2

Plus many distro-specific build instructions linked from the Installing_LinuxCNC page...

I believe it should be easy to distill these instructions down to a small recipe that works on all our supported platforms, because the buildbot does just that. The instructions should be in our asciidocs, so that they are tracked in git and automatically published on our website. The build instructions should be in the "Developer Information" section, right after "Contributing to LinuxCNC".

The top-level README should not duplicate the information, but should probably point to both the published docs online and to the asciidoc source document in the git working dir.

Here are the steps I follow to reproduce the issue:

1. Start StepConf, go through the configuration to the "X Axis Test" popup window.
2. Observe that Velocity is initialized to 1.0 in/s and Acceleration to 30 in/s^2.
3. Change the Velocity and Acceleration settings, then click the Cancel button.
4. Click the "Axis X/Test This Axis" button again.
5. Observe that Velocity and Acceleration have reset to 1 in/s and 30 in/s^2, forgetting the settings you set.

This is what I expected to happen:

The Velocity and Acceleration fields should remember what the user set them to.

Information about my hardware and software:

Debian Wheezy from the linuxcnc install iso, Linux 3.4-9-rtai-686-pae, linuxcnc-2.7.4 from www.linuxcnc.org.

Here are the steps I follow to reproduce the issue:

1. Create gcode program on remote computer
2. Drop gcode program into nc_files folder on CNC over network
3. Load gcode program in Gmoccapy to run the program,
   1. Open program in editor, and make any edit to program, then save.
   2. Go back to remote computer and try to access/open gcode program, Access Denied

This is what I expected to happen:

I should be able to open for viewing or copy the program back out of the CNC to save to remote computer for future use,

This is what happened instead:

Access is denied because the editor is for some reason changing the permissions to not allow anyone other than the CNC control to access that program.

It worked properly before this:

It works perfectly on my 3 Ubuntu machines, but on my 2 Wheezy machines, it does not work at all.

Information about my hardware and software:

• Using Debian Wheezy,
• Kernel version: Linux greenmill 4.1.13-rt15 #1 SMP PREEMPT RT Fri Dec 4 14:31:34 EST 2015 i686 GNU/Linux
• I am running ...
  • A binary version from linuxcnc.org (including buildbot.linuxcnc.org)
  • A binary I built myself
  • A binary version from some other source besides linuxcnc.org
• LinuxCNC version: 2.7.3-2.7.4
• User interface: Gmoccapy

2.7.3 and probably earlier versions.
Tested for 5i25 and "7i77x2 with one 7i77", XYZ, mm, default values where possible.
The generated config results in a following error.

We have asciidocs for the component here: http://linuxcnc.org/docs/2.7/html/hal/parallel-port.html

But it's convenient to have a manpage too, so we should add that.

There's currently a hal_parport manpage in section 3hal, describing the old API for accessing a parallel port from code in a component (used by ppmc, 7i43, 7i90, and pluto).

JT reports on IRC:

http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2016-05-05.html#15:06:29

< JT-JA13> testing Dewey's homing branch based on JA and if I set my HOME_SEARCH_VEL = 0.1 and
my HOME_LATCH_VEL = 0.05 I get Home switch active before start of latch move
< JT-JA13> I remember Andy saying something once about needing more search velocity for certain
homing
< JT-JA13> So I tried HOME_SEARCH_VEL = 0.5 and HOME_SEARCH_VEL = 0.5 and it worked
< JT-JA13> I also tested in 2.7.4
< JT-JA13> just to make sure it was in both

This problem happens on Debian Jessie with the Axis GUI, master and 2.7.

Hit up-arrow to select a command from the MDI history and it populates the MDI-command text-input field with that command, but then you can't use right-arrow or left-arrow to move around the command string to edit it.

If you click in the text-input field you can edit the command like normal.

On Lucid with 2.7 it works as expected: up-arrow/down-arrow select a line from history, then left-arrow/right-arrow let you edit that command.

On Wheezy with master it behaves the same correct way as on lucid/2.7.

So it looks like some kind of jessie/tcl/tk/focus/hocus/pocus.

Micges reports on IRC:

http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2016-03-26.html#13:49:34

In Axis if you configure DISPLAY OPEN_FILE = "" to not load a default file and press the run button after homing you get a blank error pop up message.

LinuxCNC 2.7.4

This is visible in the "jepler/thermistor" branch (31fe16b). Inspection of the generated C code shows that no processing of command-line arguments is performed.

Here are the steps I follow to reproduce the issue:

1. Press Run from line
2. Enter line number you would like to start from, press enter
3. Error pops up
4. Select OK
5. Press "Cycle Start"
6. Machine starts at selected line

This is what I expected to happen:

Machine should start running at selected line

This is what happened instead:

An error pops up, the machine still runs at the selected line, it is just giving this fault when trying to perform the command, here is a screenshot of the fault

It worked properly before this:

After upgrading from 2.6.4 to 2.7.4

Information about my hardware and software:

• Linux Version: Ubuntu 10.04
• I am running ...
  • A binary version from linuxcnc.org (including buildbot.linuxcnc.org)
• LinuxCNC version : 2.7.4
• Interface: Gmoccapy

In master after the JA merge.

On a trivkins machine (a gantry), a misconfiguration resulted in an axis and its joint having different soft limits. The axis soft limit was outside the joint soft limit. I could jog into the joint soft limit, resulting in an error message:

    Exceeded POSITIVE soft limit (0.05000) on joint 2
    Hint: switch to joint mode to jog off soft limit

On other axes/joints the soft limits coincided (as they should) and the machine would smoothly decelerate to a halt at the limit, rather than run over it and error.

Probably both axis and joint soft limits should be honored, and whichever is more restrictive should control the machine's work envelope.

After the JA merge, we need to be able to calibrate both joints and axes, but Calibrate only lets you calibrate joints.

im actually looking for the robot arm files which i see this program can be used for but i do not see that specific folder maybe a little pointer please? im looking to control a arm that i made from scratch and diy servos i built as well which is what controls the arm, my arm arent being control manually but autonomous.

Skunkworks reports on IRC: http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2016-03-09.html

Here are the steps I follow to reproduce the issue:

1. Start with a pre-ja config with at least one [AXIS_n]LOCKING_INDEXER=1, auto-convert to a ja config with update_ini.
2. Note that the LOCKING_INDEXER setting got applied to the correct [JOINT_n] section.
3. Start linuxcnc with the converted config.
4. Linuxcnc does not create the requested joint.n.unlock and joint.n.is-unlocked HAL pins.

This is what I expected to happen:

The pins should be created.

This is what happened instead:

The pins were not created.

It worked properly before this:

Works in 2.7.4 (pre-ja), though in this version, Motion creates locking pins for all rotary axes, whether or not they asked for them in the ini.

In JA, Motion expects a new load-time argument of unlock_joints_mask, which is not created by update_ini. Motion only creates locking pins for the joints enabled in that mask.

Possible fixes would be to revert to the old system of creating locking pins for all rotary joints, or to ensure that unlock_joints_mask gets sent to Motion correctly at load time.

Ever since commit f2551bb ("joints_axes9: joint jogging and axis gui updates"), i can not home the joints of my non-trivkins robot arm. I select the joint I want to home by clicking on it with the mouse, then hit the Home button on my keyboard, and Axis prints this:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1437, in __call__
    return self.func(*args)
  File "/home/seb/linuxcnc-dev/bin/axis", line 2471, in home_joint
    if s.homed[trajcoordinates.index(vars.ja_rbutton.get())]:
ValueError: substring not found

The code in question is the home_joint function:

    def home_joint(event=None):
        if not manual_ok(): return
        doHoming=True
        if s.homed[trajcoordinates.index(vars.ja_rbutton.get())]:
            doHoming=prompt_areyousure(_("Warning"),_("This joint is already homed, are you sure you want to re-home?"))
        if doHoming:
            ensure_mode(linuxcnc.MODE_MANUAL)
            go_home(trajcoordinates.index(vars.ja_rbutton.get()))

The problem is that the vars.ja_rbutton.get() function returns "0" when I have joint 0 selected and am in Free mode, but it's trying to match is with an axis name (like "X" or "Y") from the ini file.

Here are the steps I follow to reproduce the issue:

1. Run the G code below on Lathe.

G20 G64 G8 G18
M3 S400
G0 x.5 z.21
G1 x.490 z.2
/G4 P.01 ( need pause or G0 above for ver 2.7 TP)
G33 k.086 x.500 z-.550
G0 x.510
G0 z.21
m5
m2

1. If I have a G1 move leading into a G33 it makes a radius then 'Z' over accelerates then slows.
2. I can use G0 or put G4P.01 before G33 then OK. Only happens with spndl speed over 200~ rpm

This is what I expected to happen:

 feed to the G33 starting point then accel to K value.

This is what happened instead:

G1 moves toward G33 start point makes a radius then 'Z' over accelerates then slows.
After the over accel it slows to proper rate for the remainder of G33 move.

It worked properly before this:

In previous versions or with old (Pre 2.7) TP

Information about my hardware and software:

Machine 1: Using version 2.7.4 Ubuntu Lucid with new TP, Mesa 5i20 & servo card
Machine 2: Using version 2.7.4 Debian Wheezy with new TP, Mesa 5i25/7i77

• I am using this AXIS user interface (GUI)

Original report is of code that works in 2.7.4 but not in ja12.

I reproduced the same error message in master branch running interactively:

>>> import hal
>>> c = hal.component("bob")
>>> c.newparam("g", hal.HAL_FLOAT, hal.HAL_RW)
>>> c['g'] = 1.0
SystemError: null argument to internal routine

I strongly suspect this was introduced by 2b6c8ad ("halmodule: factor out to/from python functions") but I didn't test this theory yet.

Here are the steps I follow to reproduce the issue:

1. open stepconf
2. go forward to the X Axis page

This is what I expected to happen:

The numbers in the entry fields should be visible

This is what happened instead:

The numbers are invisible

It worked properly before this:

Merging pull request #71. The problem also exists at the tip of #33. I have worked around the problem by disabling axis_sanity_test in commit 44c5fb9 on our master branch.

Information about my hardware and software:

• Debian 8 amd64
• Kernel 4.4.6-1~bpo8+1
• I am running a binary I built myself, v2.8.0-pre1-1771-g928b7f2
• XFCE desktop environment with default ("xfce") theme

Currently (as of 2.7.4) the only way to change rtapi's logging message level is to change the source code and recompile. It would be better if it was easier, perhaps through the [EMC]DEBUG setting in the ini file or similar.

The button help---->about in tkemc show a error: (cant read "env(EMC2VERSION)": no such variable

Reportedly, in 2.6 hm2 sserial would survive transmission errors; in 2.7, it does not recover from even a single transmission error. I'll be looking into this once I am able to set up a test system with sserial.

Tested in 2.6.11 and master-ish with configs/sim/axis:

1. Start AXIS. Power on. Home all. Clear G54, G92 offsets via menu
2. MDI: G54
3. MDI: G0 G53 X0 Y0
4. MDI: G92 X1 / G10 L2 P1 R45 / G0 G53 X0 Y0

Expected behavior: no motion at step 4, because the machine was already at G53 X0 Y0 after step 3
Actual behavior: motion to machine coordinates (.2929, -.7071)

Our install docs are not sufficiently clear about how you can run sim/uspace debs on vanilla kernels for simulating your gcode programs, but that's a useful and valuable way to run linuxcnc.

modbus.h from <=3.0.x:

void modbus_set_response_timeout(modbus_t *ctx, const struct timeval *timeout);
void modbus_set_byte_timeout(modbus_t *ctx, const struct timeval *timeout);

while >= modbus 3.1.0 has:

MODBUS_API int modbus_set_response_timeout(modbus_t *ctx, uint32_t to_sec, uint32_t to_usec);
MODBUS_API int modbus_set_byte_timeout(modbus_t *ctx, uint32_t to_sec, uint32_t to_usec);

This gives this these compilation errors in mb2hal.c:

hal/user_comps/mb2hal/mb2hal.c: In function ‘get_tx_connection’:
hal/user_comps/mb2hal/mb2hal.c:362:55: warning: passing argument 2 of ‘modbus_set_response_timeout’ makes integer from pointer without a cast [-Wint-conversion]
     modbus_set_response_timeout(this_mb_link->modbus, &timeout);
                                                       ^
In file included from hal/user_comps/mb2hal/mb2hal.h:18:0,
                 from hal/user_comps/mb2hal/mb2hal.c:27:
/usr/include/modbus/modbus.h:188:16: note: expected ‘uint32_t {aka unsigned int}’ but argument is of type ‘struct timeval *’
 MODBUS_API int modbus_set_response_timeout(modbus_t *ctx, uint32_t to_sec, uint32_t to_usec);
                ^
hal/user_comps/mb2hal/mb2hal.c:362:5: error: too few arguments to function ‘modbus_set_response_timeout’
     modbus_set_response_timeout(this_mb_link->modbus, &timeout);
     ^
In file included from hal/user_comps/mb2hal/mb2hal.h:18:0,
                 from hal/user_comps/mb2hal/mb2hal.c:27:
/usr/include/modbus/modbus.h:188:16: note: declared here
 MODBUS_API int modbus_set_response_timeout(modbus_t *ctx, uint32_t to_sec, uint32_t to_usec);
                ^
hal/user_comps/mb2hal/mb2hal.c:369:51: warning: passing argument 2 of ‘modbus_set_byte_timeout’ makes integer from pointer without a cast [-Wint-conversion]
     modbus_set_byte_timeout(this_mb_link->modbus, &timeout);
                                                   ^
In file included from hal/user_comps/mb2hal/mb2hal.h:18:0,
                 from hal/user_comps/mb2hal/mb2hal.c:27:
/usr/include/modbus/modbus.h:191:16: note: expected ‘uint32_t {aka unsigned int}’ but argument is of type ‘struct timeval *’
 MODBUS_API int modbus_set_byte_timeout(modbus_t *ctx, uint32_t to_sec, uint32_t to_usec);
                ^
hal/user_comps/mb2hal/mb2hal.c:369:5: error: too few arguments to function ‘modbus_set_byte_timeout’
     modbus_set_byte_timeout(this_mb_link->modbus, &timeout);
     ^
In file included from hal/user_comps/mb2hal/mb2hal.h:18:0,
                 from hal/user_comps/mb2hal/mb2hal.c:27:
/usr/include/modbus/modbus.h:191:16: note: declared here
 MODBUS_API int modbus_set_byte_timeout(modbus_t *ctx, uint32_t to_sec, uint32_t to_usec);
                ^
make: *** [Makefile:207: objects/hal/user_comps/mb2hal/mb2hal.o] Error 1

While working on uspace-plus, I caused a bunch of failures on the buildbot (kernel 4.1 RT-PREEMPT, 2 CPUs) which I later reproduced on bare metal with kernel 4.4 RT-PREEMPT. It would come up at least 1 out of 1000 runs of the 'flipflop.0' test. With debugging messages, it appears the hang is inside preempt_cancel(), and that CPU0 (the one not running realtime code) begins to use 100% CPU.

I bisected it to (the moral equivalent of) this commit, the purpose of which is to clean up all tasks and destroy the App object before exiting rtapi_app. I think I can just drop this change from the uspace-plus series and leave the problem for another day, but we really should do this cleanup at exit!

0001-uspace-stop-threads-and-then-destroy-the-RtapiApp-at.patch.txt

I'm testing with joints_axes11 (0199e98). I'm using Axis with a 4-joint, 3-axis gantrykins config (J1 and J3 are my gantry).

Start LinuxCNC, home, switch to World mode. The DRO shows 4 "homed" icons (like the number of joints?) instead of 3 (like the number of axes).

Ever since commit f2551bb ("joints_axes9: joint jogging and axis gui updates") in joints_axes9, the keyboard can no longer select joints and axes in the Manual Control (F3) tab.

I'm testing with joints_axes11 (0199e98). I'm using Axis with a 4-joint, 3-axis gantrykins config (J1 and J3 are my gantry).

Start LinuxCNC, home, switch to World mode.

Use the keyboard to jog one axis (continuous), then push a key for jogging another axis. The first jogging axis stops jogging (which is wrong, it should continue to jog).

Then when you release the first axis' jog key, the second (jogging) axis stutters but continues to jog.

It does not seem to matter which axes you jog, they all behave like this.

Here are the steps I follow to reproduce the issue:

Sim Axis.

1. Move Y axis 5 inches away from positive soft limit. Zero
2. X axis should be somewhere in the middle of travel an zeroed
3. G0X10Y0
4. g2x10i10f300

This is what I expected to happen:

A linear movement checks to see of the end point is outside of the soft limits. Some similar check should happen for arcs.

This is what happened instead:

The machine moves towards the soft limit - hits the soft limit then de-accelerates. On our Matsuura - the over travel is far enough to hit the over travel limit switches in this situation. (the above example- the axsis moves past the soft limit by .393"

It worked properly before this:

This is 2.7.4 - I don't think this has ever worked.

It would be nice if Axis Touch-off had the currently active coordinate system selected by default, instead of always G54.

basically, if you start threads and then interactively addf read-request, you get a segfault. I think this is because read-request continually queues things and runs off the end of a statically-allocated buffer. I didn't diagnose it further.

dgarr notices that in master branch since ad06db2, the reload function is broken because linuxcnc says "interp_error: A file is already open". This boils down to executing the following sequence, whether in 2.7 or master:

>>> import linuxcnc
>>> c = linuxcnc.command()
>>> c.state(linuxcnc.STATE_ESTOP_RESET)
>>> c.state(linuxcnc.STATE_ON)
>>> c.home(-1)
>>> c.mode(linuxcnc.MODE_AUTO)
>>> c.program_open("/home/jepler/src/linuxcnc/share/axis/images/axis.ngc")
>>> c.program_open("/home/jepler/src/linuxcnc/share/axis/images/axis.ngc")
emc/task/emctask.cc 389: interp_error: A file is already open
A file is already open
can't open /home/jepler/src/linuxcnc/share/axis/images/axis.ngc

Options include allowing this sequence in task, or performing some other request in between, such as c.abort() explicitly in axis.py or implicitly in the linuxcnc module.

In master after the JA merge, on a gantry machine. A misconfiguration put the soft limit of the Z axis and the soft limit of the joint of the Z axis in different places. Running in to the joint soft limit triggered a crazy Abort loop in Task:

    Exceeded POSITIVE soft limit (0.05000) on joint 2
    NML_INTERP_LIST(0x82f8398)::append(nml_msg_ptr{size=12,type=EMC_TASK_PLAN_SYNCH}) : list_size=1, line_number=0
    NML_INTERP_LIST(0x82f8398)::append(nml_msg_ptr{size=88,type=EMC_TRAJ_SET_G5X}) : list_size=1, line_number=0
    NML_INTERP_LIST(0x82f8398)::append(nml_msg_ptr{size=20,type=EMC_TRAJ_SET_ROTATION}) : list_size=2, line_number=0
    NML_INTERP_LIST(0x82f8398)::append(nml_msg_ptr{size=24,type=EMC_TRAJ_SET_SPINDLESYNC}) : list_size=3, line_number=0
    NML_INTERP_LIST(0x82f8398)::append(nml_msg_ptr{size=12,type=EMC_SPINDLE_OFF}) : list_size=4, line_number=0
    NML_INTERP_LIST(0x82f8398)::append(nml_msg_ptr{size=12,type=EMC_TASK_PLAN_SYNCH}) : list_size=5, line_number=0
    NML_INTERP_LIST(0x82f8398)::get(): {size=88, type=EMC_TRAJ_SET_G5X}, list_size=4
    emcTaskPlanLevel() returned 0
    Hint: switch to joint mode to jog off soft limit
    NML_INTERP_LIST(0x82f8398)::append(nml_msg_ptr{size=12,type=EMC_TASK_PLAN_SYNCH}) : list_size=5, line_number=0
    NML_INTERP_LIST(0x82f8398)::append(nml_msg_ptr{size=88,type=EMC_TRAJ_SET_G5X}) : list_size=1, line_number=0
    NML_INTERP_LIST(0x82f8398)::append(nml_msg_ptr{size=20,type=EMC_TRAJ_SET_ROTATION}) : list_size=2, line_number=0
    NML_INTERP_LIST(0x82f8398)::append(nml_msg_ptr{size=24,type=EMC_TRAJ_SET_SPINDLESYNC}) : list_size=3, line_number=0
    NML_INTERP_LIST(0x82f8398)::append(nml_msg_ptr{size=12,type=EMC_SPINDLE_OFF}) : list_size=4, line_number=0
    NML_INTERP_LIST(0x82f8398)::append(nml_msg_ptr{size=12,type=EMC_TASK_PLAN_SYNCH}) : list_size=5, line_number=0
    NML_INTERP_LIST(0x82f8398)::get(): {size=88, type=EMC_TRAJ_SET_G5X}, list_size=4
    emcTaskPlanLevel() returned 0
    NML_INTERP_LIST(0x82f8398)::append(nml_msg_ptr{size=12,type=EMC_TASK_PLAN_SYNCH}) : list_size=5, line_number=0
    NML_INTERP_LIST(0x82f8398)::append(nml_msg_ptr{size=88,type=EMC_TRAJ_SET_G5X}) : list_size=1, line_number=0
    NML_INTERP_LIST(0x82f8398)::append(nml_msg_ptr{size=20,type=EMC_TRAJ_SET_ROTATION}) : list_size=2, line_number=0
    NML_INTERP_LIST(0x82f8398)::append(nml_msg_ptr{size=24,type=EMC_TRAJ_SET_SPINDLESYNC}) : list_size=3, line_number=0
    NML_INTERP_LIST(0x82f8398)::append(nml_msg_ptr{size=12,type=EMC_SPINDLE_OFF}) : list_size=4, line_number=0
    NML_INTERP_LIST(0x82f8398)::append(nml_msg_ptr{size=12,type=EMC_TASK_PLAN_SYNCH}) : list_size=5, line_number=0
    NML_INTERP_LIST(0x82f8398)::get(): {size=88, type=EMC_TRAJ_SET_G5X}, list_size=4
    emcTaskPlanLevel() returned 0

It never made any progress and I had to quit LinuxCNC to make it stop.

In another misconfiguration we hit the limit switch before the soft limit. In that situation it Aborted just once or twice, then chilled out.

In master after the JA merge, on a gantry machine with trivkins and Axis. Set [EMC]DEBUG=0x7fffffff. Start Axis, F1, F2, Ctrl-Home, then just sit there idle. Task issues these commands, many every second:

Issuing EMC_TRAJ_SET_TELEOP_ENABLE --    (  +230,+16,  +111,    +1,)
Issuing EMC_TRAJ_SET_TELEOP_ENABLE --    (  +230,+16,  +112,    +1,)
Issuing EMC_TRAJ_SET_TELEOP_ENABLE --    (  +230,+16,  +113,    +1,)
Issuing EMC_TRAJ_SET_TELEOP_ENABLE --    (  +230,+16,  +114,    +1,)
Issuing EMC_TRAJ_SET_TELEOP_ENABLE --    (  +230,+16,  +115,    +1,)
Issuing EMC_TRAJ_SET_TELEOP_ENABLE --    (  +230,+16,  +116,    +1,)
Issuing EMC_TRAJ_SET_TELEOP_ENABLE --    (  +230,+16,  +117,    +1,)

Ignore this issue.

Here are the steps I follow to reproduce the issue:

Start the machine and home

This is what I expected to happen:

Switch to world mode like hexapod-sim config does.

This is what happened instead:

After homing the machine remains in joint mode. Otherwise everything seems to work.

Information about my hardware and software:

Six axis genhexkins machine with analog servos.

• I am using joints_axes13 from git on a standard Debian ISO
• I am using AXIS
• I am using MESA 7i77 & 5i25

Are there any plans to release - or is there a test version somewhere - of the LinuxCNC ISO with Jessie rather than Wheezy?

When max velocity and/or rapid velocity is limited with sliders in Axis, Shift + Arrow keys still go full speed. In MDI mode both limits work for G0.
Tested in LinuxCNC 2.7.4

The interpreter currently (as of master 37e6fc4) only verifies that the endpoints of arcs are within the axis soft limits. The curve of the arc may extend outside the soft limits, as long as it returns to within the soft limits before ending.

You can verify this behavior by running sim/axis/axis (which has a -X limit of -10), F1, F2, Home All, G0 X-9, F100, G2 Y6 J3.

The arc is accepted, and travels outside the axis soft limits (though also see issue #96).

The extents of the arc are easy to determine and validate against the axis soft limits. Coordinate system rotation may require extra care.

PCW reports on IRC:
http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2016-03-26.html#14:01:56

This is more of a gcode question than an issue, but can someone please help?

Looking at the spiral example: https://github.com/LinuxCNC/linuxcnc/blob/master/nc_files/spiral.ngc

1:
g91 g1 @-.0025 ^4.5
What do the @ and ^ symbols mean?

2:
The example starts from outside working in.
How do I start from center working outwards?

Any pointers would be very helpful - many thanks.

continue part of #100

Error: http://dpaste.com/0GED3Z0

lineardeltakins.cc fails to build on ubuntu 16.04

Here are the steps I follow to reproduce the issue:

1.On a servo machine with encoder feedback - after machine is up / homed
2.Toggle machine back off
3.Physically move axis
5.Toggle machine back on
6.You instantly get a following air for that axis and machine powers back off.
7.Currently no way to fix this state

On sim
1.Power up and home
2.Open halcmd
3.unlink joint.0.motor-pos.fb
4.setp joint.0.motor-pos-fb 5
5.Toggle machine back on.
6.At this point - fb should equal commanded.. It doesn't and you get a following error.

This is what I expected to happen:

The machine should turn on and the fb should equal cmd position

This is what happened instead:

Following error

It worked properly before this:

If you do the exact same sequence in 2.7 - when you toggle power on - the machine turns on as expected.

Old isos are in /iso, new isos are in /.
Probably move the new ones to /iso and place symlinks in / pointing at the real locations.

I'm testing with joints_axes11 (0199e98). I'm using Axis with a 4-joint, 3-axis gantrykins config (J1 and J3 are my gantry).

Start LinuxCNC, home, switch to World mode. Trigger an Estop with F1. Switch to Joint mode. Come out of Estop (F1) and turn the machine on (F2), and it automatically switches to World mode, surprising this operator.

It's debatable what the right behavior here is. In my config, all 4 joints stay homed after entering estop, so it's not unreasonable to switch to World mode when turning the machine on. On the other hand, I did explicitly tell it to go to Joint mode, so it switching to World mode is showing more initiative than i'm used to in my CNC machines.

I think I want the machine to automatically switch from Joint to World mode immediately after successfully homing (this is reasonable now that we have world-mode incremental jogging), and then not change the mode unless I command it, but I welcome debate on this.

Here are the steps I follow to reproduce the issue:

1.Start hexapod-sim config
2.Home (the machine goes to world mode, axis X radiobutton is selested by default in manual control tab).
3.Press Ctrl-Space to clean pop up messages

This is what I expected to happen:

Clean pop up messages, if any.

This is what happened instead:

Messages disapper but axis selection is also lost, no axis radiobutton is active.

It worked properly before this:

Works correct in 2.7.4

Information about my hardware and software:

• I am using Debian from ISO in VirtualBox
• I am running a binary I built myself
• I am using master LinuxCNC from git, just updated
• I am using AXIS

Here are the steps I follow to reproduce the issue:

1.Start hexapod-sim config
2.Home
3.Press $

This is what I expected to happen:

Switch to joint mode

This is what happened instead:

$ doesn't switch the mode from the first attempt

It worked properly before this:

Works correct in 2.7.4

Information about my hardware and software:

• I am using Debian from ISO in VirtualBox
• I am running a binary I built myself
• I am using master LinuxCNC from git, just updated
• I am using AXIS